Sql-server – Should I worry about failed login attempts on SQL Server

OK, there are several things that it could be but I'm not sure if we can determine which from here. These include the following:

1. AD propagation issues
2. AD caching "stickiness" on the target SQL Server
3. Domain Trust issues (particularly if the target server is in a different domain)
4. Windows Group membership/visibility issues
5. UAC blocking users access to certain groups needed for the new server
6. Kerberos issues (very common)
7. Etc...

And yes, dropping and re-adding the Users does seem to fix it in some of these cases, even though this should in theory never be needed because the SIDs should always match for Windows Users in transferred databases. It may be that the target SQL server simply lacks the same necessary server-level principal definitions as the original servers (and this as a side-effect creates explicit ones), or it may be that the act of adding the Login/user causes SQL Server to forcibly rerun the query and reload it's AD information for that user.

In any event, the real problem tends to be that dropping a user is a potentially disruptive and destructive act. It may work, but it may also cause some bad side-effects. Nonetheless, if you want to try that, then the best procs I know of for that are from Ted Krueger and they are located here: http://blogs.lessthandot.com/index.php/DataMgmt/DBAdmin/fixing-orphaned-database-users.

Other (possible) solutions that you could employ include:

• Automated procedure that does not drop the User, but does add and associate a server-level Windows Login for it.
• Create a Windows AD group for access to the database, add all of the users to that, and then add that to the SQL Server as a Login and Database as a User. (this is the recommended approach for managing large-scale access anyway).
• ...

You cannot actually login to SQL Server with any domain account. You can either pass a SQL Login with its password, or you can logon using "Windows Authentication". What the latter means is that the account that is executing the windows executable is passed to SQL Server to authenticate.

That means you just need to execute the app using a local machine account and add that account as a windows login to SQL Server.

If the application on the other hand is running on a domain computer and you just pointed it to use SQL Server on your machine, you are out of luck. However, if you were able to change the connection string to point to your machine, you should be able to just add a SQL Login to that same connection string.