This doesn't make sense, as you are running the service under a domain account with no "write ServicePrincipalName" permissions. If you were running under a localSystem account or a domain account with "write ServicePrincipalName" permissions, it would be able to create the spn. Is it possible that someone/something manually created the spn?
Here's an excerpt from Degremont Michel (SQL Server Core Engineer at Microsoft) explaining how this works:
If you run SQL Server under the LocalSystem account, the SPN is automatically registered as SQL registering with the machine account that has the right to create an SPN default. So Kerberos interacts successfully with the server running SQL Server.
However, if you run SQL Server under a domain account or a local account, the attempt to create the SPN may fail. When creating the service principal name fails, this means that no SPN is set for the service that is running SQL Server.
http://blogs.technet.com/b/mdegre/archive/2009/11/20/the-sql-network-interface-library-was-unable-to-register-spn.aspx
Here's another excerpt from msdn:
When the Database Engine service starts, it attempts to register the Service Principal Name (SPN). If the account starting SQL Server doesn’t have permission to register a SPN in Active Directory Domain Services, this call will fail and a warning message will be logged in the Application event log as well as the SQL Server error log. To register the SPN, the Database Engine must be running under a built-in account, such as Local System (not recommended) or NETWORK SERVICE, or an account that has permission to register an SPN, such as a domain administrator account. If SQL Server is not running under one of these accounts, the SPN is not registered at startup and the domain administrator must register the SPN manually.
http://msdn.microsoft.com/en-us/library/ms191153%28v=sql.105%29.aspx
Sounds like the account "somehow" has permissions that you don't know about. Maybe group policy or something similar...
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).
Best Answer
NTLM is a challenge/response type system, and while it has a resonable level of security it is potentially vunerable to attack and credential theft. In fact NTLM V1 is a known attack vector, considered insecure and should be disabled on your systems. NTLM V2 is more secure, and the current standard.
Kerberos handles mutual authentication between parties, ensuring that the tokens are encrypted and secure. I'd recommend reading the Kerberos basic authentication concepts to get a handle on it. The reading is a little dry, but it will give you a greater understanding.
Of the two, Kerberos is far more secure, and is the recommended protocol for Windows connections to SQL Server.
To resolve your SPN problem look for duplicate tickets using SETSPN-L with both the server, and the service account, and look for duplicates. Remove those, and then adjust the SQL Server service account to allow it to self register its service principal name. This will allow it to handle things itself, which makes life a lot easier.
You will not experience any actual problems with SQL (except for times when you might be using linked servers, or some other double hop type scenario where the ticket cannot be passed along to a second machine), and so it may not be a critical fix to you. Only your security team can really define that.