|
|
You're in the
sql server connect
group:cannot generate sspi context when server in mixed authentication m
sql server connect:
We have a situation for which I have been trying to find an explanation for
over a week. A windows 2005 SP1 server which previously ran in Windows authentication only suddenly caused "cannot generate sspi context" errors after we switched it to mixed authentication mode. -SQL service is running with domain account not trusted for delegation -We have checked for invalid SPNs in the domain and there are none registered for the SQL Service on this machine -TCP/IP protocol is enabled on the server -Named Pipes connections work fine -After switching back to Windows authentication and clearing the ticket cache the problem dissapears If I understand correctly. The default authentication protocol used over tcp/ip when connecting to SQL Server is Kerberos but if the client cannot find a valid SPN for the SQL Service on the server then it should fall back to NTLM. For some reason however, this is not happening as it should.
What is SQL Server service starting as...local system, domain user or domain
admin? -- Kevin Hill 3NF Consulting http://www.3nf-inc.com/NewsGroups.htm Real-world stuff I run across with SQL Server: http://kevin3nf.blogspot.com [quoted text, click to view] "DBA72" <DBA72@discussions.microsoft.com> wrote in message news:65AFAA64-4847-4034-8745-211ED18ACB0E@microsoft.com... > We have a situation for which I have been trying to find an explanation > for > over a week. A windows 2005 SP1 server which previously ran in Windows > authentication only suddenly caused "cannot generate sspi context" errors > after we switched it to mixed authentication mode. > > -SQL service is running with domain account not trusted for delegation > -We have checked for invalid SPNs in the domain and there are none > registered for the SQL Service on this machine > -TCP/IP protocol is enabled on the server > -Named Pipes connections work fine > -After switching back to Windows authentication and clearing the ticket > cache the problem dissapears > > If I understand correctly. The default authentication protocol used over > tcp/ip when connecting to SQL Server is Kerberos but if the client cannot > find a valid SPN for the SQL Service on the server then it should fall > back > to NTLM. For some reason however, this is not happening as it should. >
It is starting with a domain user account.
[quoted text, click to view] "Kevin3NF" wrote:
> What is SQL Server service starting as...local system, domain user or domain > admin? > > -- > Kevin Hill > 3NF Consulting > http://www.3nf-inc.com/NewsGroups.htm > > Real-world stuff I run across with SQL Server: > http://kevin3nf.blogspot.com > > > "DBA72" <DBA72@discussions.microsoft.com> wrote in message > news:65AFAA64-4847-4034-8745-211ED18ACB0E@microsoft.com... > > We have a situation for which I have been trying to find an explanation > > for > > over a week. A windows 2005 SP1 server which previously ran in Windows > > authentication only suddenly caused "cannot generate sspi context" errors > > after we switched it to mixed authentication mode. > > > > -SQL service is running with domain account not trusted for delegation > > -We have checked for invalid SPNs in the domain and there are none > > registered for the SQL Service on this machine > > -TCP/IP protocol is enabled on the server > > -Named Pipes connections work fine > > -After switching back to Windows authentication and clearing the ticket > > cache the problem dissapears > > > > If I understand correctly. The default authentication protocol used over > > tcp/ip when connecting to SQL Server is Kerberos but if the client cannot > > find a valid SPN for the SQL Service on the server then it should fall > > back > > to NTLM. For some reason however, this is not happening as it should. > > > >
A domain admin will need to create an SPN for the SQL Server service
manually using SetSPN or ADSI (I think) Local system or domain admin starting sql does this automatically...domain user does not -- Kevin Hill 3NF Consulting http://www.3nf-inc.com/NewsGroups.htm Real-world stuff I run across with SQL Server: http://kevin3nf.blogspot.com [quoted text, click to view] "DBA72" <DBA72@discussions.microsoft.com> wrote in message news:F01518D8-9430-49AB-95AC-076BF1C5CF84@microsoft.com... > It is starting with a domain user account. > > "Kevin3NF" wrote: > >> What is SQL Server service starting as...local system, domain user or >> domain >> admin? >> >> -- >> Kevin Hill >> 3NF Consulting >> http://www.3nf-inc.com/NewsGroups.htm >> >> Real-world stuff I run across with SQL Server: >> http://kevin3nf.blogspot.com >> >> >> "DBA72" <DBA72@discussions.microsoft.com> wrote in message >> news:65AFAA64-4847-4034-8745-211ED18ACB0E@microsoft.com... >> > We have a situation for which I have been trying to find an explanation >> > for >> > over a week. A windows 2005 SP1 server which previously ran in Windows >> > authentication only suddenly caused "cannot generate sspi context" >> > errors >> > after we switched it to mixed authentication mode. >> > >> > -SQL service is running with domain account not trusted for delegation >> > -We have checked for invalid SPNs in the domain and there are none >> > registered for the SQL Service on this machine >> > -TCP/IP protocol is enabled on the server >> > -Named Pipes connections work fine >> > -After switching back to Windows authentication and clearing the ticket >> > cache the problem dissapears >> > >> > If I understand correctly. The default authentication protocol used >> > over >> > tcp/ip when connecting to SQL Server is Kerberos but if the client >> > cannot >> > find a valid SPN for the SQL Service on the server then it should fall >> > back >> > to NTLM. For some reason however, this is not happening as it should. >> > >> >> >>
[quoted text, click to view] "Kevin3NF" wrote: Kevin,> A domain admin will need to create an SPN for the SQL Server service > manually using SetSPN or ADSI (I think) > > Local system or domain admin starting sql does this automatically...domain > user does not > > -- > Kevin Hill > 3NF Consulting > http://www.3nf-inc.com/NewsGroups.htm > > Real-world stuff I run across with SQL Server: > http://kevin3nf.blogspot.com > > > "DBA72" <DBA72@discussions.microsoft.com> wrote in message > news:F01518D8-9430-49AB-95AC-076BF1C5CF84@microsoft.com... > > It is starting with a domain user account. > > > > "Kevin3NF" wrote: > > > >> What is SQL Server service starting as...local system, domain user or > >> domain > >> admin? > >> > >> -- > >> Kevin Hill > >> 3NF Consulting > >> http://www.3nf-inc.com/NewsGroups.htm > >> > >> Real-world stuff I run across with SQL Server: > >> http://kevin3nf.blogspot.com > >> > >> > >> "DBA72" <DBA72@discussions.microsoft.com> wrote in message > >> news:65AFAA64-4847-4034-8745-211ED18ACB0E@microsoft.com... > >> > We have a situation for which I have been trying to find an explanation > >> > for > >> > over a week. A windows 2005 SP1 server which previously ran in Windows > >> > authentication only suddenly caused "cannot generate sspi context" > >> > errors > >> > after we switched it to mixed authentication mode. > >> > > >> > -SQL service is running with domain account not trusted for delegation > >> > -We have checked for invalid SPNs in the domain and there are none > >> > registered for the SQL Service on this machine > >> > -TCP/IP protocol is enabled on the server > >> > -Named Pipes connections work fine > >> > -After switching back to Windows authentication and clearing the ticket > >> > cache the problem dissapears > >> > > >> > If I understand correctly. The default authentication protocol used > >> > over > >> > tcp/ip when connecting to SQL Server is Kerberos but if the client > >> > cannot > >> > find a valid SPN for the SQL Service on the server then it should fall > >> > back > >> > to NTLM. For some reason however, this is not happening as it should. > >> > > >> > >> > >> > > I think you would be right if I was trying to use Kerberos but as I said, this is not enabled for the sql service account. What I want to do is use
If you are getting SSPI error, something is attempting to use
Kerberos...even if that was not your intention. This is more of an Active Directory issue than SQL Server, so I'm pretty much at the end of my knowledge base... -- Kevin Hill 3NF Consulting http://www.3nf-inc.com/NewsGroups.htm Real-world stuff I run across with SQL Server: http://kevin3nf.blogspot.com [quoted text, click to view] "DBA72" <DBA72@discussions.microsoft.com> wrote in message news:6C11E262-B916-42BA-A294-A16FD71FE5C0@microsoft.com... > > > "Kevin3NF" wrote: > >> A domain admin will need to create an SPN for the SQL Server service >> manually using SetSPN or ADSI (I think) >> >> Local system or domain admin starting sql does this >> automatically...domain >> user does not >> >> -- >> Kevin Hill >> 3NF Consulting >> http://www.3nf-inc.com/NewsGroups.htm >> >> Real-world stuff I run across with SQL Server: >> http://kevin3nf.blogspot.com >> >> >> "DBA72" <DBA72@discussions.microsoft.com> wrote in message >> news:F01518D8-9430-49AB-95AC-076BF1C5CF84@microsoft.com... >> > It is starting with a domain user account. >> > >> > "Kevin3NF" wrote: >> > >> >> What is SQL Server service starting as...local system, domain user or >> >> domain >> >> admin? >> >> >> >> -- >> >> Kevin Hill >> >> 3NF Consulting >> >> http://www.3nf-inc.com/NewsGroups.htm >> >> >> >> Real-world stuff I run across with SQL Server: >> >> http://kevin3nf.blogspot.com >> >> >> >> >> >> "DBA72" <DBA72@discussions.microsoft.com> wrote in message >> >> news:65AFAA64-4847-4034-8745-211ED18ACB0E@microsoft.com... >> >> > We have a situation for which I have been trying to find an >> >> > explanation >> >> > for >> >> > over a week. A windows 2005 SP1 server which previously ran in >> >> > Windows >> >> > authentication only suddenly caused "cannot generate sspi context" >> >> > errors >> >> > after we switched it to mixed authentication mode. >> >> > >> >> > -SQL service is running with domain account not trusted for >> >> > delegation >> >> > -We have checked for invalid SPNs in the domain and there are none >> >> > registered for the SQL Service on this machine >> >> > -TCP/IP protocol is enabled on the server >> >> > -Named Pipes connections work fine >> >> > -After switching back to Windows authentication and clearing the >> >> > ticket >> >> > cache the problem dissapears >> >> > >> >> > If I understand correctly. The default authentication protocol used >> >> > over >> >> > tcp/ip when connecting to SQL Server is Kerberos but if the client >> >> > cannot >> >> > find a valid SPN for the SQL Service on the server then it should >> >> > fall >> >> > back >> >> > to NTLM. For some reason however, this is not happening as it >> >> > should. >> >> > >> >> >> >> >> >> >> >> > Kevin, > I think you would be right if I was trying to use Kerberos but as I said, > this is not enabled for the sql service account. What I want to do is use > NTLM over tcp/ip
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
August 2008
| home · blog · groups | Questions? Comments? Contact the dn |