January 23, 2009 at 2:14 am
I am trying to connect to one of my SQL 2005 / Windows 2003 Servers via TCP/IP / default port from a client. I have tried everything suggested via Google including removing the server from the domain and re-adding it, but am still receiving this error on the client:
Event Type:Error
Event Source:Kerberos
Event Category:None
Event ID:4
Date:21/01/2009
Time:18:02:12
User:N/A
Computer:ICT28216
Description:
The kerberos client received a KRB_AP_ERR_MODIFIED error from the server host/papoth17.intra.blackburn.gov.uk. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (INTRA.BLACKBURN.GOV.UK), and the client realm. Please contact your system administrator.
I can connect via TCP/IP when actually on the server and can also connect from a client using Named Pipes no problem.
Any other ideas, I'm stumped!!
Thanks
Steve
January 23, 2009 at 8:55 am
There could be an SPN problem which is why Kerberos is failing. If you use SETSPN -L for the service account under which SQL Server is running, do you see entries like:
MSSQLSvc/papoth17
MSSQLSvc/papoth17.intra.blackburn.gov.uk
The other two connections are explainable. When you are logged on locally, you are likely using Shared Memory. And when you are coming through Named Pipes, it's dropping back to NTLM. Kerberos support for Named Pipes was introduced in SQL Server 2008. It's not there in SQL Server 2005.
K. Brian Kelley
@kbriankelley
January 23, 2009 at 8:59 am
K. Brian Kelley (1/23/2009)
And when you are coming through Named Pipes, it's dropping back to NTLM. Kerberos support for Named Pipes was introduced in SQL Server 2008. It's not there in SQL Server 2005.
Did you mention this in the Kerberos article? I don't recall reading that, but it makes sense to me, sort of.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
January 23, 2009 at 9:02 am
Jack Corbett (1/23/2009)
K. Brian Kelley (1/23/2009)
And when you are coming through Named Pipes, it's dropping back to NTLM. Kerberos support for Named Pipes was introduced in SQL Server 2008. It's not there in SQL Server 2005.Did you mention this in the Kerberos article? I don't recall reading that, but it makes sense to me, sort of.
I don't remember if I did. But I'm pretty sure I did for the Pro SQL 2008 Admin book chapter. Yes, that was a completely shameless plug. Marketing types everywhere would be proud of me. 😉
K. Brian Kelley
@kbriankelley
January 23, 2009 at 9:08 am
Thanks.
Where do I run the SETSPN -L command? At the command prompt?
January 23, 2009 at 9:10 am
K. Brian Kelley (1/23/2009)
Jack Corbett (1/23/2009)
K. Brian Kelley (1/23/2009)
And when you are coming through Named Pipes, it's dropping back to NTLM. Kerberos support for Named Pipes was introduced in SQL Server 2008. It's not there in SQL Server 2005.Did you mention this in the Kerberos article? I don't recall reading that, but it makes sense to me, sort of.
I don't remember if I did. But I'm pretty sure I did for the Pro SQL 2008 Admin book chapter. Yes, that was a completely shameless plug. Marketing types everywhere would be proud of me. 😉
Nothing wrong with a plug. Have you seen the rest of the book? Is it any good (of course I know your chapter must be)?
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
January 23, 2009 at 9:17 am
Steve Hindle (1/23/2009)
Thanks.Where do I run the SETSPN -L command? At the command prompt?
Yes. However, if you haven't already, you may need to install the Support or Resource Kit tools. If you're not the domain admin, you may want to engage that group. This is technically their domain (pun intended).
K. Brian Kelley
@kbriankelley
January 23, 2009 at 9:19 am
Jack Corbett (1/23/2009)
K. Brian Kelley (1/23/2009)
Jack Corbett (1/23/2009)
K. Brian Kelley (1/23/2009)
And when you are coming through Named Pipes, it's dropping back to NTLM. Kerberos support for Named Pipes was introduced in SQL Server 2008. It's not there in SQL Server 2005.Did you mention this in the Kerberos article? I don't recall reading that, but it makes sense to me, sort of.
I don't remember if I did. But I'm pretty sure I did for the Pro SQL 2008 Admin book chapter. Yes, that was a completely shameless plug. Marketing types everywhere would be proud of me. 😉
Nothing wrong with a plug. Have you seen the rest of the book? Is it any good (of course I know your chapter must be)?
Our guys are using my free copy. They've gotten value out of it. I skimmed through it and the sections I looked at were good. It was an all star cast. At the time of writing I was the only non-MVP or Microsoft employee in the author list.
K. Brian Kelley
@kbriankelley
January 27, 2009 at 4:19 am
I have now run the setspn command and received the following message:
C:\Program Files\Resource Kit>SETSPN -L PAPOTH17
Registered ServicePrincipalNames for CN=PAPOTH17,OU=Application Servers,OU=Serve
rs,DC=intra,DC=blackburn,DC=gov,DC=uk:
MSSQLSvc/papoth17.intra.blackburn.gov.uk:1433
HOST/PAPOTH17
HOST/papoth17.intra.blackburn.gov.uk
Any ideas?
January 27, 2009 at 7:30 am
Steve Hindle (1/27/2009)
I have now run the setspn command and received the following message:C:\Program Files\Resource Kit>SETSPN -L PAPOTH17
Registered ServicePrincipalNames for CN=PAPOTH17,OU=Application Servers,OU=Serve
rs,DC=intra,DC=blackburn,DC=gov,DC=uk:
MSSQLSvc/papoth17.intra.blackburn.gov.uk:1433
HOST/PAPOTH17
HOST/papoth17.intra.blackburn.gov.uk
Any ideas?
Check the service account SQL Server is running under. The SPN needs to be registered underneath that. If you are running a Windows domain account, then you'll need to get rid of the MSSQLSvc underneath the server account.
SETSPN -D MSSQLSvc/papoth17.intra.backburn.gov.uk:1433 PAPOTH17
And then you'll need to add the SPNs under the proper account. These four entries will cover everything for a default instance:
SETSPN -A MSSQLSvc/papoth17.intra.blackburn.gov.uk:1433 YourDomain\YourSvcAccount
SETSPN -A MSSQLSvc/papoth17.intra.blackburn.gov.uk YourDomain\YourSvcAccount
SETSPN -A MSSQLSvc/papoth17:1433 YourDomain\YourSvcAccount
SETSPN -A MSSQLSvc/papoth17 YourDomain\YourSvcAccount
The add and delete SPNs require Domain Admin privs. If you're not comfortable executing these commands and you have someone in your organization that is, then this shoudl give them enough to go on.
K. Brian Kelley
@kbriankelley
January 27, 2009 at 8:37 am
It worked!
Do you know how I would have arrived at this as all my other servers are fine?? Seems like an order of installation /setup to me.
Many thanks again.
January 27, 2009 at 8:42 am
Not sure. If the SQL Server was set up to once upon a time run as System or Network Service (not positive about this one) it might have registered the SPN itself.
K. Brian Kelley
@kbriankelley
January 28, 2009 at 6:56 am
Steve Hindle (1/27/2009)
It worked!Do you know how I would have arrived at this as all my other servers are fine?? Seems like an order of installation /setup to me.
Many thanks again.
I'm not sure if this happened in your case, but I have run into a similar problem when I was building a set of Virtual Machines to run under Microsoft's VirtualPC 2007 application. I built one machine, copeid the VM files to different directories, brought those copies online and changed their names then finished configuring them with SQL server. But with all copies running i got that error you reported. I didn't think to try the solution listed in this thread, so I simply rebuilt each VM from scratch.
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply