cannot generate sspi context when server in mixed authentication m

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
"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.
>