I've got a SQL agent job, the first step is of type: Operating System (CmdExec), it's running as a Proxy which I created.
The command: \\ShareDrive\Program.exe
I have given the user of my Proxy rights on the ShareDrive folder share, but when I start the job I am always getting the following error:
Executed as user: ProxyUser. The process could not be created for step
1 of job 0xDA12CDA08820804EB95F551C1B2936E0 (reason: Access is
denied). The step failed.
I have tried setting the folder security to allow EVERYONE access, in this instance the job runs fine with no access issues, but poses a security risk.
Any assistance would be appreciated
You are accessing a share, there are two levels of security:
for the physical folder
for the share
The most restrictive permissions of the two is in effect.
Make sure that the windows account of the ProxyUser has proper permissions on both levels.
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
My backup job in Maintenance Plans has an error (Please check error encountered below) which already 3 days straight.
Job configured as follows:
(Step 1): Backup the DBs to a shared folder of Server A
(Step 2): If Step 1 Success, It will copy the backups from Server A to the shared folder of Server B.
As per error from event viewer the error stopped at Step 1. I still don't know where the error came from but as per checking the backup created in Server A are all complete which is weird.
Here are my isolation:
The shared folder of Server A and Server B are accessible (tried also the account of SQL services job as a user in windows)
Here is the error found in event viewer:
1. BackupIoRequest::ReportIoError: read failure on backup device '\\\Server_A\Shared Folder\Database.bak'. Operating system error 64(The specified network name is no longer available.)."
2. "Package "Backup Databases Directly to Server_A Shared Folder" failed."
3. "SQL Server Scheduled Job 'Backup Databases Directly to Server_A Shared Folder.Subplan_1' (0xD20650B4C8A10F41A130C734D053DB63) - Status: Failed - Invoked on: 2019-08-24 00:00:00 - Message: The job failed. The Job was invoked by Schedule 89 (Backup Databases Directly to Server_A Shared Folder.Subplan_1). The last step to run was step 1 (Subplan_1).
As per error from event viewer the error stopped at Step 1. I still don't know where the error came from
Usually, when you checking it form SQL Agent history, expand the job and select step 1 so that we can see what causing the that error, information must be printed in message section (bottom):
"BackupIoRequest::ReportIoError: read failure on backup device '\Server_A\Shared Folder\Database.bak'. Operating system error 64(The specified network name is no longer available.)
In this case, there must be something wrong with path (wrong spelled), or the SQL Server service account (not only SQL Agent service account) doesn't have permissions on the shared folder.
When you say SERVER-A and SERVER-B can access shared folder, you might have verified logging in at the server with particular user, so that logged-in user got the permissions on the shared folder, as long as same user is service account user of SQL Server then we can assume, SQL Server really have access to shared folder.
Hope, fixing permission issues would resolve the error caused.
However, do you have any issues to directly create a backup on SERVER-B shared folder as i feel like we are doing unnecessary additional step.
P.s: I personally, recommend to use custom script for maintenance tasks, especially for backups. My answer at DBA.SE might helpful in your case for better backup strategy
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.
Getting the below error while trying to configure the backup source and destination are in different domain.
Executing the query "BACKUP LOG [project_management] TO DISK = N'\\nee..." failed with the following error:
"Cannot open backup device '\\qwerty.xyz.xyzinteractive.com\backup4\Teddy\TLogs\project_management_backup_2016_05_28_020039_7840447.trn'. Operating system error 1326(The user name or password is incorrect.). BACKUP LOG is terminating abnormally.".
Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
It is usually recommended that a backup is done local and then moved. Here is a link that I think is related to the topic. Are you using a service account that has appropriate privileges on both domains?
http://www.sqlservercentral.com/Forums/Topic842263-357-1.aspx
Make sure that the account that's running the MSSQLSERVER service for your instance has access to the network share.
If you're running on a domain and the instance is running as the computer's SYSTEM account, then you'll want to grant access to the computer account instead of a user.
If you're not on a domain or are saving the file across domains that aren't trusted and the instance is running as the computer's SYSTEM account... well, then the easiest way to do it is to change the account to a real service account.
Executing SqlScript at the remote DB causes an error:
Failed to connect to SQL database. (-2147467259 myDB1)
The SqlScript is the following:
<sql:SqlString
Id='UpdateSomething1'
SqlDb='myDB1'
ExecuteOnInstall='yes'
User='SQLUser'
ContinueOnError='no'
ExecuteOnReinstall='no'
ExecuteOnUninstall='no'
Sequence='26'
SQL='[SqlString]'/>
where the Db is:
<sql:SqlDatabase
Id='myDB1'
Database='myDB1'
Server='[DATABASE_SERVER]'
CreateOnInstall='yes'
DropOnInstall='no'
DropOnUninstall='no'
ContinueOnError='no'/>
and the user is:
<util:User
Id="SQLUser"
Name="myUserName1"
Password="password1"/>
The problem does not occur with the local DB.
We extracted more specific error message from the IP traffic (the actual error that the remote MSSQL server throws):
Can not open database "myDb1"
requested by the login. The login
failed. {remote machine name} Login
failed for user {user name}
Thank you for any help and information.
Max
I would need more information to be sure but here are some general observations I've had over the years.
In MSI, you typically run deferred custom actions with no impersonation so that they run as Administrator to support managed/elevated installs where the invoking user doesn't have admin either because they really don't or because UAC hasn't elevated their process.
In InstallShield, and I'm sure WiX is similar, this typically causes a problem for remote database connections. If you have a dialog in the UI sequence to test the connection it will succeed ( when expected to ) because the interactive user has permissions to that database/instance. And if installing locally it will succeed because SYSTEM (typically) has permissions the database/instance. But when installing to a remote instance it will frequently fail because SYSTEM can't authenticate against SQL on the remote machine. Your mileage will improve if using sql authentication ( e.g. SA ).
Personally I have some practices that I follow. If I'm creating a single tier system, I restrict the database to (local). If I'm creating a 2 tier system, I create two installers: one for my database layer which I restrict to (local) and one for my application layer which I then reuse the sqllogin dialog to verify connectivity and write the values out to a web.config or app.config. This allows me to loosely couple the layers and service them independently of each other.
I hope this helps to understand the types of issues that can be encountered. I don't know your exact problem without seeing your environement.
The WiX custom actions are just using standard OLEDB commands to connect to the remote server. If the credentials work locally but not remotely then I'd start by ensuring the credentials are correct. There isn't anything different in the WiX custom actions between local and remote servers.
Looking at your database element I would say that you have not added the User attribute to the sql:SqlDatabase so it is creating the database impersonating the current user.
Try:
<sql:SqlDatabase
Id='myDB1'
Database='myDB1'
Server='[DATABASE_SERVER]'
User='SQLUser'
CreateOnInstall='yes'
DropOnInstall='no'
DropOnUninstall='no'
ContinueOnError='no' />