Cannot register SPN, error 0x80090350, state 4

Question

This is my first time trying to configure kerberos. I need it for SQL Server.

Considerations

• I'm running SQL Server 2008 R2 on Windows 2008 R2 server.

• I have an Active Directory account for SQL Server 2008 R2.

• The account is delegated for kerberos.

• The account is configured to start SQL Server services. This works without problems.

• SPNs are registered for both netbios and FQDN for computername and also computername:1433.

• The same SPNS are registered for the server and the account.

I mean, if I do

• setspn -L domain\serviceaccount

or

• setsqpn -Q MSSSQLSvc/Server.domain.local,

I get

MSSQLSvc/Server:1433

MSSQLSvc/Server.domain.local

MSSQLSvc/Server.domain.local:1433

When I run this query:

select auth_scheme 
  from sys.dm_exec_connections 
 where session_id=@@spid

...the result is NTLM.

This query I'm running from another server, connecting to the SQL Server that I need to use Kerberos on.

When I restart SQL Server services I see this error in the log:

The SQL Server Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service. Error: 0x80090350, state: 4. Failure to register an SPN may cause integrated authentication to fall back to NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies.

Any idea what I'm missing?

Answer 1

The error message you're seeing, 0x80090350, is defined as:

c:\util\Err>err 0x80090350

# for hex 0x80090350 / decimal -2146892976 :
  SEC_E_DOWNGRADE_DETECTED                                        winerror.h
# The system detected a possible attempt to compromise
# security.  Please ensure that you can contact the server
# that authenticated you.
# 1 matches found for "0x80090350"

I'm looking this up with the Exchange Error Lookup Tool.

According to the information in this post, this error is often caused by the MaxTokenSize issue caused by an account (indirectly or directly) being a member of a large number of groups.

Another possibility I'd consider is that a duplicate SPN exists. You can determine which SPNs Windows thinks are duplicates by running setspn -X -F (info here).

Answer 2

Looking at all the steps again I noticed that the account didn't have permissions to read and write SPNs. Modiefied the values with ADSI edit.

Thanks for all the help!