May 30, 2013 at 10:04 am
We have a production environment that we have used to clone into our lab environment for testing. We are using Vcloud Director to host this virtual environment. In production all of our linked servers are using Kerberos for security to use logins own context. In our VCloud environment everything looks the same as production. The problem we are having is that everything looks good as far as SPN goes and in AD the sql server service account is running under an account that uses account delegation but we are still getting the error:
Msg 18456, Level 14, State 1, Line 1 Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'
We tried to verify it is using kerberos with this query, "select net_transport, auth_scheme from sys.dm_exec_connections where session_id=@@spid". However in vcloud it returns NTLM, and production is returns Kerberos. We have tried a bunch of things and nothing seems to work. We rebooted machines, added and removed account delegation in AD, etc. Anyone else run into this?
May 30, 2013 at 2:36 pm
If you open up a command prompt and run the following, what do you get?
setspn -L <domainName>\<accountName>
Where <domainName> is the pre-Windows 2000 naming convention for the domain (ex: Famicam) and <accountName> is the name of the service account that the SQL Server service account is running under (ex: svc.sql.server). So for example one would run:
setspn -L famicam\svc.sql.server
You should get entries back for the MSSQLSvc for your SQL server.
Are connections being made directly from an application to the database, or is there more hops involved? For example like with SSRS, a user hits a report server and then the report server can relay the credentials back to the SQL Server. Just curious because depending on how many hops there are there could be several layers of delegation between different accounts/services that need to be setup.
Joie Andrew
"Since 1982"
May 30, 2013 at 2:47 pm
The servers were listed in the SETSPN -L. Somehow the problem is resolved, we still aren't sure how. We removed and registered some of the servers in DNS and removed some of the SPN and re-added, eventually we must have done the right thing. It is working for us now. Thanks for your help.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply