SQL Server 2008 R2 en Kerberos

Nadat ik met mijn PowerShell script een SQL Server 2008 R2 installatie heb uitgevoerd liep ik de meldingen in de Event log door. In het application gedeelte kwam ik onderstaande informational melding tegen.

The SQL Server Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service. Error: 0x2098, state: 15. 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.

Deze melding is te verwachten op het moment dat de server draait onder een local of domein account in plaats van onder een Network Service of Local System account. De reden hiervan is dat deze accounts, in tegenstelling tot de Network Server of Local System accounts, geen autorisatie hebben om een SPN (= Service Principal Name) te registreren. Aangezien de registratie van de SPN mislukt valt de authenticatie terug naar het standaard NTLM protocol.

Om de server toch onder Kerberos te laten draaien zijn er twee opties.

1. Als beheerder zelf de SPN te registreren. De syntax hiervoor is: SetSPN.exe -A MSSQLSvc/<ComputerName>.<DomainName>:<port> <AccountName>. Dit is een veel gebruikte methode en deze wordt bijvoorbeeld beschreven in het artikel "SQL Protocols: Using Kerberos with SQL Server".
   
2. Het account rechten geven om zelf zijn SPN te mogen registreren. Het account heeft hiervoor de rechten "Read servicePrincipalName" en "Write servicePrincipalName" nodig op het eigen account. Deze manier is ook de door Microsoft beschreven methode in het knowledge base artikel "How to use Kerberos authentication in SQL Server". De procedure die Microsoft in dit artikel beschrijft gaat wel uit van handmatige configuratie door middel van het gebruik van ADSI EDIT (Adsiedit.msc).

De tweede optie heb ik verder uitgewerkt. In plaats van handmatig via ADSI EDIT de aanpassing door te voeren heb ik ervoor gekozen deze aanpassing met Dcacls.exe door te voeren. De aanroep van dit commando heb ik in een PowerShell script gevat. Deze is echter ook vanaf de command line uit te voeren.

$DistinguishedName = "CN=SQL_Server,OU=...,DC=antiohne,DC=local";

# Technet informatie over Dcacls.exe: 
# http://technet.microsoft.com/en-us/library/cc771151(WS.10).aspx
#
# Samenvatting:
# ------------------------------------------------------------------------------
# "[\\<Computer>\]<ObjectDN>" 
#  Identificeert het Active Directory object welke aangepast dient te worden.
# De distinguished name van het object dient gebruikt te worden. Indien het 
# object op een remote computer staat dient de computer name ook opgegeven te
# worden. De parameter dient tussen quotes te staan.
# /I 
#  Specifieert de objecten waarop de rechten gezet te worden
#  T: Het object zelf en de kinderen daaronder
#  S: Alleen de kinderen onder het object
#  P: Het object en de kinderen tot 1 niveau lager
# /G
# De rechten die gezet dienen te worden op de gebruiker of groep

& dsacls.exe $DistinguishedName /I:P /G "\SELF:RPWP;servicePrincipalName" 

Nadat het script succesvol is uitgevoerd herstart ik de SQL Server. Nu is in de log twee keer te zien dat de registratie van de SPN is gelukt en dat de SQL Server nu onder Kerberos authenticatie draait.

The SQL Server Network Interface library successfully registered the Service Principal Name (SPN) [ MSSQLSvc/atlas.antiohne.local:1433 ] for the SQL Server service. 

The SQL Server Network Interface library successfully registered the Service Principal Name (SPN) [ MSSQLSvc/atlas.antiohne.local ] for the SQL Server service.