This is our first SSIS package created on xx.xx.xx.77 for pull data from xx.xx.xx.56 server and load on share path (server ip xx.xx.xx.130) as an Excel file. That path is accessible from both servers.
SQL Server Agent is configured with NT Service\SQLAgent$instance in xx.xx.xx.77 server.
So we got Error1.
Error1:
Msg: The application-specific permission settings do not grant Local
Activation permission for the COM Server application with CLSID
{FDC3723D-1588-4BA3-92D4-42C430735D7D} and APPID
{83B33982-693D-4824-B42E-7196AE61BB05} to the user NT
SERVICE\SQLAgent$instance SID
(S-1-5-80-3789775531-3388834719-430539279-2094781381-3838682281) from
address LocalHost (Using LRPC) running in the application container
Unavailable SID (Unavailable). This security permission can be
modified using the Component Services administrative tool.
Log Type: Windows NT Log Source: System Source:
Microsoft-Windows-DistributedCOM Categroy: (0) Event: 10016 User:
NT SERVICE\SQLAgent$instance Computer:
After Google search we go with Proxy user. Now we facing issue (Error2) in scheduling that package on xx.xx.xx.77 server using proxy user.
Error2:
The job failed. The Job was invoked by
User. The last step to run was step 1 ()
FYI: Although same Proxy user has been created on xx.xx.xx.55 server, same error persist while run job on 77 server.
Reference Links:
Give access to virtual account. But we cant do this due to our privileges is not enough.
Proxy Creation
We refer more SO Q&A and Google results for SSIS package creation. No one helps. Because our scenario includes two servers. So we need helping hand.
Edit 1:
We did this after Error1.
"Launch & Activation Permission" -> click Edit -> Add in the account NT Service\SQLAgent$instance-> Name Not Found error. Ref: below image. Same error for, add "Service Account" in Object Type on below dialogue box.
Then we change location from Domain.com to Server Name in Location as follows:
Now, NT Service\SQLAgent$instance name is found. Then we check "Local Launch & Local Activation". Ref:
After restart the Service, we got same error. Thats' we go with Proxy User.
Reference link for Deploy the SSIS package.
EDIT 2
We move the SSIS project to another xx.xx.xx.231 server, where SQL Service Agent is configured with Domain user like backupuser#domain.com. Now the job is run successfully on scheduled time.
FYI: Another reason of the error is the destination file is may be opened by another user. Here, file is in shard location. When run the job on xx.xx.xx.231 server, we got same error again. After some cross checking, we found that Excel file is opened by our Team met.
Thanks to All,
Pugal
You might need to provide permission using the below instruction.
Click Start -> Run -> Type -> dcomcnfg, expand Component Services -> Computers -> My Computer -> DCOM Config.
Click View -> Detail -> Now you will get Application Name and Application ID in right side.
Scroll down and find the application ID " " -> Right Click -> Properties and select the Security tab.
Click Customize under "Launch & Activation Permission" -> click Edit -> Add in the account NT AUTHORITY\SYSTEM and set local launch and local activation.
Restart the application Service linked to this Application ID or restart the server and monitor
Related
What I am trying to do:
We have a Task Scheduler that kicks off an EXE, which in the course of its runtime, will connect to SQL Server.
So that would be:
taskServer.myDomain triggers the Task Scheduler action
taskServer.myDomain exe runs locally
taskServer.myDomain initiates a connection to sqlServer.myDomain
The scheduled task is associated with a service account (svc_user) that is set to run with highest privilege, run whether the user is logged in or not, and store credentials for access to non-local resources.
The actual behavior
What we are seeing is the Task Scheduler is indeed running as svc_user. It triggers the EXE as expected, and the EXE is also running as svc_user. When the EXE initiates a connection to SQL Server, it errors on authentication.
Looking at the Event Viewer we can see the failure trying to initialize the connection to SQL
Exception Info: System.Data.SqlClient.SqlException
at System.Data.SqlClient.SqlInternalConnectionTds..ctor(System.Data.ProviderBase.DbConnectionPoolIdentity, System.Data.SqlClient.SqlConnectionString, System.Data.SqlClient.SqlCredential, System.Object, System.String, System.Security.SecureString, Boolean, System.Data.SqlClient.SqlConnectionString, System.Data.SqlClient.SessionData, System.Data.ProviderBase.DbConnectionPool, System.String, Boolean, System.Data.SqlClient.SqlAuthenticationProviderManager)
And then looking at the SQL Server logs we can see the root of the issue
Logon,Unknown,Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. Reason: Could not find a login matching the name provided.
The connection initialized by the EXE to SQL Server is trying to authenticate as ANONYMOUS LOGON.
What I have tried
Background
This issue popped up when our IT team started deploying a GPO lockdown in our environments. So in order to get to this point, we first had to add some GPO exceptions to allow the svc_user to:
log on locally
log on as batch job
Progress?
This is where we started being able to capture the ANONYMOUS LOGON error in SQL Server. From there we tried a handful of other GPO exceptions including
Allow Credential Save
Enable computer and user accounts to be trusted for delegation
The actual issue?
So it would appear that this is a double hop delegation issue. Which eventually led me here and then via the answer, here and here.
So I tried adding GPO policies to allow delegating fresh credentials using the WSMAN/* protocol + wildcard.
Two issues with this:
the Fresh credentials refer to prompted credentials while the EXE is running as a service during off-hours and inheriting the credentials from the TaskScheduler
the WSMAN protocol appears to be used for remote PowerShell sessions (via the original question in the serverfault post) and not SQL Service connections.
So, I added the protocol MSSQLSvc/* to the enabled delegation and tried all permutations of Fresh, Saved and Default delegation. (This was all done in Local Computer Policy -> Computer Configuration -> Administrative Templates -> system -> Credentials Delegation)
Where it gets weird
We have another server, otherServer.myDomain, which we setup with the same TaskSchedule. It is setup with the same GPO memberships, but seems to be able to successfully connect to SQL Server. AFAIK, the servers are identical as far as setup and configuration.
The Present
I have done a bit more digging into anywhere I could think that might offer clues as to how I can feed the credentials through or where they might be falling through. Including watching the traffic between the taskServer and the sqlServer as well as otherServer and sqlServer.
I was able to see NTLM challenges coming from the sqlServer to the taskServer/otherServer.
In the case of taskServer, the NTLM response only has a workstationString=taskServer
On otherServer, the NTLM response has workstationString=otherServer, domainString=myDomain, and userString=svc_user.
Question
What is the disconnect between hop 1 (task scheduler to EXE) and hop 2 (EXE to SQL on sqlServer)? And why does this behavior not match between taskServer and otherServer?
So I finally have an update/solution for this post.
The crux of the issue was a missing SPN. The short answer:
Add an SPN for sqlServer associated with the service account SQL services are running as (not the svc_user)
example: SetSPN -S MSSQLSvc/sqlServer.myDomain myDomain\svc_sql_user
Add another SPN like above but w/ the sql service port
example: SetSPN -S MSSQLSvc/sqlServer.myDomain:1433 myDomain\svc_sql_user
Set the SQL service user account to allow delegation like so
I'm facing a strange behavior of SQL Server Agent when executing SSIS packages.
I have a job that includes many steps (mainly SSIS packages). Some steps fail mostly every day even the configuration is the same for all the steps.
I tried to delete/create the job, delete/create the SQL Server Agent Proxy but with no sucess.
I can't find any difference between the steps that fail and the ones that succeed.
This is the error returned by SQL Server Agent :
The package failed to load due to error 0xC0011008 "Error loading from XML. No further detailed error information can be specified for this problem because no Events object was passed where detailed error information
SQL Server version : 2014
SSIS version : 2014
EDIT :
In the Event Log I found an Information Message from User Profile Service that says :
Windows detected your registry file is still in use by other applications or services. The file will be unloaded now. The applications or services that hold your registry file may not function properly afterwards
Process 5924 (\Device\HarddiskVolume2\Program Files\Microsoft SQL Server\120\DTS\Binn\DTExec.exe) has opened key \REGISTRY\USER\S-X-X-XX-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXX\Control Panel\International
Process 5924 (\Device\HarddiskVolume2\Program Files\Microsoft SQL Server\120\DTS\Binn\DTExec.exe) has opened key \REGISTRY\USER\S-X-X-XX-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXX\Software\Microsoft\Windows\CurrentVersion
The SID corresponds to the Proxy User used to execute the SQL Job steps. And the timestamp corresponds is the same when the error occures in SQL Agent.
I think this is what causes the steps to fail.
Could we prevent Windows unloading this registry ?
The error was indeed caused by the fact that the User Profile Service forces the unloading of the Registry.
The solution that worked for me was to change the policy setting Do not forcefully unload the user registry at user logoff from "Not Configured" to Enabled.
Start the Local Group Policy Editor (gpedit.msc)
Go to Computer Configuration > Administrative Templates > System > User Profiles
Set "Do not forcefully unload the user registry at user logoff" to Enabled
Run gpupdate command.
Details can be found here : https://support.microsoft.com/en-us/help/2287297/a-com-application-may-stop-working-on-windows-server-2008-when-a-user
The generic problem is as listed here SQL Maintenance Cleanup Task Working but Not Deleting but no solutions applicable. Environment: Windows Server 2012R2, AD DS (with policies of course), RDSH/TS Licensing, 1C-server. The primary problem is SQL Server generating insane amount of events per backup plan run, recording a pair of 18456+17052 errors per file to delete. Errors are as follows:
17052: [Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed for user 'DOMAIN\mssql_srv'
18456: Reason: Could not find a login matching the name provided. [CLIENT: 192.168.x.x] (matches localhost)
Given that each pair of errors appears once per file to delete (there are about 6000 files already!), the algorithm looks like this:
First, backup plan task runs xp_delete_file, it enumerates all the files in target folder;
Second, each file is deleted by creating a separate connection to machine with service's credentials;
Each connection fails due to whatever restrictions default DC policy applies, generating the pair of events. Of course the file remains in place.
The workaround is of course assign file delete task to a local script run as system, for example, but the very reason of why does SQL server fail to delete a file remains unknown. Permissions have been checked and verified that both SQL Server Agent and SQL Server service accounts have full control to the folder.
It turned out that this "login missing" is not a Windows login, but rather SQL "login" which was not present for the service account. So I needed to create a "DOMAIN\mssql_srv" login in SSMS, give it "public" access rights and voila, files started to get deleted properly. The reason is explained in comment:
If it's T-SQL step and job owner is member of sysadmin server role, the step is executed under service account.
How to host ASPNET CORE APP with IdentityServer4 in IIS. The app is running fine from localhost but not as a web application setup in IIS.
For Example,
http://localhost:5000/connect/token is working but http://example.com/myauthapp/connect/token is not reachable - returning 500 - internal server error when tried from a console app using identity model or via postman. I am able to login to the app using web browser but not thru a console app or postman.
Further Troubleshoot and I find the below.
An unhandled exception has occurred: IDX10638: Cannot created the SignatureProvider, 'key.HasPrivateKey' is false, cannot create signatures. Key: Microsoft.IdentityModel.Tokens.RsaSecurityKey.
System.InvalidOperationException: IDX10638: Cannot created the SignatureProvider, 'key.HasPrivateKey' is false, cannot create signatures. Key: Microsoft.IdentityModel.Tokens.RsaSecurityKey.
at Microsoft.IdentityModel.Tokens.AsymmetricSignatureProvider..ctor(SecurityKey key, String algorithm, Boolean willCreateSignatures)
at Microsoft.IdentityModel.Tokens.CryptoProviderFactory.CreateSignatureProvider(SecurityKey key, String algorithm, Boolean willCreateSignatures)
at System.IdentityModel.Tokens.Jwt.JwtSecurityTokenHandler.CreateEncodedSignature(String input, SigningCredentials signingCredentials)
at System.IdentityModel.Tokens.Jwt.JwtSecurityTokenHandler.WriteToken(SecurityToken token)
at IdentityServer4.Services.DefaultTokenCreationService.CreateJwtAsync(JwtSecurityToken jwt)
at IdentityServer4.Services.DefaultTokenCreationService.<CreateTokenAsync>d__3.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
How can I solve this issue?
As Arun noted in his comment, the certificate has to be installed on the server.
1 . To test this on localhost first, make sure you are using "AddSigningCredential" not "AddTemporarySigningCredential".
services.AddIdentityServer()
.AddSigningCredential(new X509Certificate2(Path.Combine(_environment.ContentRootPath, "certs", "IdentityServer4Auth.pfx")));
//.AddTemporarySigningCredential()
;
Create the certificate in your project (create certs folder), running this in visual studio command:
"C:\Program Files (x86)\Windows Kits\8.1\bin\x64\makecert" -n
"CN=IdentityServer4Auth" -a sha256 -sv IdentityServer4Auth.pvk -r
IdentityServer4Auth.cer -b 01/01/2017 -e 01/01/2025
"C:\Program Files (x86)\Windows Kits\8.1\bin\x64\pvk2pfx" -pvk IdentityServer4Auth.pvk
-spc IdentityServer4Auth.cer -pfx IdentityServer4Auth.pfx
Test on localhost
If successful, deploy to iis server , install the certificate on the server by double clicking on it, and test.
Make sure the application pool "load user profile" is set to true :
Go to IIS Manager
Go to the application pool instance
Click advanced settings
Under Process model, set Load User Profile to true
Restart IIS
If this fails with a 500, like with me (and there is no logs to help you out), try this. To fix this recreate the certificate on the server the same way as in step 2 in the certs folder . double click the cert to install.
You might have to install the developer kit if you dont have visual studio installed:
https://developer.microsoft.com/en-us/windows/downloads/windows-8-1-sdk
A little background first, on why it is working on your Local Development computer and not running under IIS on a QA or Production Environment. If you are using Temporary Signing Credential when adding the service Identity Server 4 like so,
services.AddIdentityServer().AddTemporarySigningCredential();
Then you have to make sure the "User" that the "Process" is running as has a Private Key available for ID4 to create a Temporary Certificate. This is why the error message is
SignatureProvider, 'key.HasPrivateKey' is false, cannot create
signatures. Key: Microsoft.IdentityModel.Tokens.RsaSecurityKey.
In the case of Windows, this private key is generated by Windows automatically and can be found at the folder %APPDATA%\Microsoft\Crypto\RSA of the User or C:\Users\Username\AppData\Roaming\Microsoft\Crypto\RSA. The reason why this Private Key is missing is perhaps because the User that your Process is running as has never logged onto that Computer.
The likely SOLUTION in that case is to log in once as the User that will be running the Process on that Server. It is quite common for the Private Key directory to be missing if your Application Pool within IIS runs as a "non-service" user with very High Privileges and that user has never interactively logged onto the Server itself. This also explains why "localhost" works on your development computer, while running on a Production or QA Server may not.
More information on how and where Windows creates the Private Key for a User can be found here in this link Microsoft Key Storage and Retrieval. Also, it is recommended as mentioned by David Smit to explicitly specify a Private Key file, instead of using Temporary Signing Credentials. That is the cleaner solution if you are allowed to make code changes.
services.AddIdentityServer()
.AddSigningCredential(new X509Certificate2("C:\Certs\IdentityServer4PrivateKeyFile.pfx")));
I run the same script as an application account under IIS, and as a Scheduled task, and i get very different results.
From IIS (as a web page), i can read e.g. field properties, and run very simple queries like
SELECT * FROM SYSTEMINFO
So connection to database is there.
Anything more "advanced", gives get all sorts of errors:
SELECT SYSTEMINFOID FROM SYSTEMINFO
or
SELECT COUNT(*) FROM SYSTEMINFO
or
INSERT INTO SYSTEMINFO ( SYSTEMINFOID ) VALUES (1)
typically gives "[Microsoft][ODBC Microsoft Access Driver] Unknown (SQL-42000)" or "[Microsoft][ODBC Microsoft Access Driver] Overflow (SQL-42000)" which means "missing access or syntax error" according to some ms error message overviews (Quite broad group of errors...)
If the application account is member of Administrators, all works fine (but not a good solution), any other memberships (user, power user, backup operator) gives the same error. (need to reboot server for such changes to take effect, so debugging is time consuming.)
User has local policies to "Replace a process token", and "Adjust memory quotas" granted (as well as run as batch + service).
Environment looks the same (except that in IIS web environment is added), and i can see in task manager that the scripts are run as the application account.
connection string is
DBI:ODBC:driver=Microsoft Access Driver (*.mdb);DBQ=C:\folder\Demo.mdb;
running CGI, Perl 5.18, DBI,
on IIS 8.5 Win2012 std, appliction pool uses the application account,with load user profile, and Impersonate user as True
Setting up the same on Win 2008 R2 works fine.
Connection to e.g. a local ms sql express database gives SSL errors, even if SSL is not in use, and using a sql account for authentication.
Spent four days on looking at all odd combinations, any suggestions for settings I may have overlooked?
(summary: when running as application account, not being an administrator under iis 8.5 the script is running, connection to database works, but anything more than trivial queries results in odd errors. )
Finally found a solution:
in IIS 8.5, for a service account to work, the same user (as pool user) must be set as Application Pass-trough authentication.
Creating an application under the Web Site,
Selecting Basic Settings for this Application, assigning it to a separate pool run by the service account was not enought.
In addtion, the "Pass-throught autentication" must be set as the same user, by selecting the "Connect as..."-button.