July 6, 2015 at 2:18 pm
I've run into something strange here, and I'm not sure how to resolve it. I ran into a Kerberos authentication issue because of a missing AOAG SPN, and I was helping to do some of the troubleshooting when I noticed something odd. Some of the tickets that granted me access to the nodes of the AOAG cluster were using the encryption type that I would expect. However, the MSSQLSvc SPNs were not using what I would expect!
klist
#XX> Client Somebody@somedomain.com
Server: RPCSS/MySQLServer@somedomain.com
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
#XX> Client Somebody@somedomain.com
Server: MSSQLSvc/MySQLServer@somedomain.com
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
#XX> Client Somebody@somedomain.com
Server: MSSQLSvc/MyAOAGListener@somedomain.com
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
I can't seem to figure out what the next step should be, and the infrastructure admins are stumped as well. Any thoughts on how to proceed?
Thanks!
July 7, 2015 at 6:00 am
is this the SPN for the listener Virtual NetworkName?
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
July 7, 2015 at 7:41 am
Yes, the SPN for the listener and the node both exist and are being used to access the server. We had to create them manually because we are using domain accounts to run the SQL service. Which reminds me, I think there is a setting in Active Directory that can enable/disable the Kerberos ticket encryption level and perhaps that hasn't been set properly.....
July 7, 2015 at 11:43 am
Jim_K (7/7/2015)
Yes, the SPN for the listener and the node both exist and are being used to access the server. We had to create them manually because we are using domain accounts to run the SQL service. Which reminds me, I think there is a setting in Active Directory that can enable/disable the Kerberos ticket encryption level and perhaps that hasn't been set properly.....
You must use the same account for each sql service that can host the listener, this is because the SPN is bound to the user account, hence each sql server instance must use the same service account as its partners so that when the SPN fails over it continues to work
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
July 9, 2015 at 7:26 am
Hello Perry,
Yes we are using a single account across all our nodes for the SQL service (thank you btw for your series, it has helped me immensely). The issue was as I suspected, the service account was created without having the "This account supports Kerberos AES 256 bit encryption" enabled. Once it was enabled, Kerberos generated a ticket protected with the higher level of encryption.
Thanks!
July 9, 2015 at 7:32 am
great, thanks for posting back
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply