May 7, 2015 at 7:57 am
We are currently having the following problem. When trying to connect using "Be made using the login's current security context" I am getting the following error message "Login Failed for NTAuthority\AnonLogin". Yesterday this worked. The setup is as follows
SQL2008R2, nine instances on a cluster. The instance can use "current security context" when both instances are on the same node ie instance 1 node a to instance 2 node a , but when one is on node a and the other is on node b, ie instance 1 node 1 to instance 2 node b, we get the error above.
any ideas?
May 7, 2015 at 8:27 am
Looks like a kerberos delegation issue. Try to see if the Kerberos Configuration Manager for SQL Server points out some obvious issue.
-- Gianluca Sartori
May 7, 2015 at 9:17 am
So I had a bunch of issues
1. I needed to add SPN to the MSSQLSvs\<ServerNode>.domain:<Instancename> to account <SQLSDE.ServiceAccount>
2. And the service accounts in question are marked Account is sensitive and cannot be delegated
Thanks I know where to start then.
Why does each of cluster nodes have to have its own SPN?
May 8, 2015 at 9:50 am
Joshua D Gang (5/7/2015)
Why does each of cluster nodes have to have its own SPN?
The nodes themselves don't have SPNs, the individual instances have the SPNs configured against each of their virtual network names. For example
Windows Cluster
Nodename
Node1
Node2
Node3
Clustered Instances
Servername
SQLCLUST01\INST1
SQLCLUST02\INST2
SQLCLUST03\INST3
SPNs are registered for
SQLCLUST01 running under domain account MyDomain\User1
SQLCLUST02 running under domain account MyDomain\User2
SQLCLUST03 running under domain account MyDomain\User3
The SPNs are registered against the account used for each of the SQL server services
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
May 8, 2015 at 10:03 am
Yes I see that now after running the tool. Thanks for the reply. We had a number of issues, 4 of the instances did not have SPN's and the service account where not set up correctly. Going to try to fix this this upcoming weekend
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply