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.
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'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.
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.
I have hunted high and low for a fix to this, but everything is saying the same - a permissions error. The error given in the replication monitor clearly states it, but I can't see what I have got wrong.
The set-up (sorry for all the red lines in the screenshots - doing my best to disguise stuff ;) ):
Publisher and distributor are on SQL Server 2012 (11.0.3128)
Subscriber is a remote SQL Server 2008 (10.50.2550) - using a pull subscription
Windows user called SQL_Replication_Dev http://screencast.com/t/mz7ZX3fCW. This user exists on both servers with the same password
Login for SQL_Replication_Dev user created in both SQL Servers http://screencast.com/t/pGmnYQTZJm
The SQL_Replication_Dev user is mapped to the publishing DB and the distribution DB on the publisher and the subscriber DB on the subscriber. In all instances, has the db_owner role assigned http://screencast.com/t/2uVfHbkf4Q
The publication is using a network share and not the default folder http://screencast.com/t/OgnUcfBWlz
The SQL_Replication_Dev user has Full Control to the share http://screencast.com/t/d5s1ZZiW
The SQL_Replication_Dev user has Full Control to the underlying folder http://screencast.com/t/T6zJaku2Cob
The SQL_Replication_Dev user is on the Public Access List (PAL) for the publication http://screencast.com/t/BQ7EEh4vfc
Both the snapshot agent and the log reader agent are set as the SQL_Replication_Dev user http://screencast.com/t/iCpytv8yjL
The subscription distribution agent is set to use the SQL_Replication_Dev user and impersonate http://screencast.com/t/onD82Zd1gU0B
The subscription creates successfully and fires the publication snapshot agent to successfully create a snapshot in the folder share.
When looking at the replication monitor on the publisher, I then see the OS error 53 (http://screencast.com/t/4ORyBkQUYVRg) with the detail of The network path was not found. The path and file exist and are accessible to the SQL_Replication_Dev user (I tested this by logging into the server and navigating to the file via the share - is that good enough?).
Any ideas?
It looks like I did have everything configured correctly and I ended up creating a VPN connection between the publisher and subscriber. I could then set the Alternate Path in the subscriber properties to \\local_ip_address_of_publisher\ReplicationDev.
As the VPN connection was only needed for the initial snapshot I could then disconnect the VPN.
In the future, should I need to pass another snapshot, I can re-connect the VPN and make sure the Alternate Path in the subscriber properties are set to use the new local ip address of the publisher.
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' />