Data Platform

Inrichten van Kerberos voor SQL Server (deel 2)

Inrichten van Kerberos voor SQL Server

In mijn vorige blog heb ik beschreven wat het Kerberos protocol inhoud en hoe het werkt. In deze blog ga ik verder in op het inrichten van Kerberos voor SQL Server.

Het configureren van Kerberos gebeurt in 5 stappen. Deze stappen dienen zo veel mogelijk in onderstaande volgorde te worden uitgevoerd.

  1. Aanpassen connection strings
  2. Herstart services met een AD service account
  3. Registreer SPN’s voor de service accounts
  4. Aanmaken delegations op service account
  5. Herstarten services

Hieronder zijn de afzonderlijke stappen verder uitgewerkt. Om Kerberos correct te laten werken zijn er diverse randvoorwaarden. Deze zijn per onderdeel toegelicht.

1. Aanpassen connection strings

Bij de connectie tussen de PC en server 1 en tussen server 1 en server 2 moet worden aangegeven dat er gebruik wordt gemaakt van ‘integrated security’. In een OLEDB connectie wordt dit aangegeven met :

integrated security=sspi

Bij het aanmaken van een linked server kun je geen connection string opgeven. Hier moet je in het tabblad ‘Security’ een vinkje zetten bij: ‘Be made using the login’s current security context’.

Voor alle duidelijkheid: alle andere stappen in deze blog beschrijven alleen de verbinding tussen server 1 en server 2 maar voor de connection string geld dat dit in de hele keten moet worden toegepast. Alleen dan worden de user credentials correct doorgegeven aan de volgende stap. Er mag ook geen userID en/of wachtwoord in de connection string worden opgenomen omdat er dan wordt afgeweken van de credentials waarmee de gebruiker is ingelogd op het netwerk.

 

2. Herstart services met een AD service account

Services die nog niet met een AD account werken moeten worden aangepast. Voordat je een service herstart met een ander account moet je controleren of het nieuwe account toegang heeft tot de benodigde recources. Denk hierbij aan de directories met programma bestanden, configuratie en log files. Bij SSRS moet het account ook rechten hebben op de ReportServer en ReportServertempdb databases en moet je voor het wijzigen eerst een backup maken van de encription keys.

Gebruik bij voorkeur de “SQL Server Configuration Manager” voor het wijzigen van het service account. Alleen voor het wijzigen van SSRS gebruik je de “Reporting Services Configuration Manager”.

Als je gebruik maakt van een named instance van SQL Server of Analysis Service dient ook de serverbrowser met een AD service account te worden gestart. Wijzig ook de start mode naar “Automatic”. Om de configuratie van de SPN’s en delegations eenvoudiger te maken kun je voor hetzelfde account kiezen als SQL Server service of SSAS service.

Als IIS wordt gebruikt dient de Application Pool te werken met een AD account.

Indien er bij de double hop een failover cluster of AlwaysOn cluster is betrokken, moet je Kerberos inrichten voor de virtuele naam van dit cluster.  Een SPN dient uniek te zijn binnen het AD en kan maar op een service account gelijktijdig worden geregistreerd. Om te voorkomen dat je bij iedere failover de SPN’s opnieuw moet aanmaken is het raadzaam dat alle betrokken servers in het cluster met hetzelfde service account werken.

Maak je gebruik van SharePoint, neem dan contact op met de beheerder van de SharePoint farm omdat het dan meerdere services en service account betreft. Vraag ook na of de Claims to Windows Token Services (C2WTS) is gestart.

 

3. Registreer SPN’s voor de service accounts

Een SPN is een “Service Principal Name” die je registreert in AD op een service account en het beschrijft de service die beschikbaar is voor Kerberos. Een SPN registreer je met het volgende commando:

setspn –S <serviceclass>/<Computername>:<Port> <Domain\ServiceAccount>

Een SPN mag niet dubbel voor komen. De SPN “MSSQLSvc/SQLServer1” mag bij voorbeeld niet worden geregistreerd op meerdere accounts. Als dit toch wordt gedaan zal Kerberos authenticatie niet meer werken. Gebruik daarom bij voorkeur de setspn –S switch in plaats van de oudere –A switch omdat dan bij het aanmaken wordt gecontroleerd op dubbele SPN registraties.

Als alternatief kan een SPN ook worden geregistreerd op de server in plaats van op het service account. Dit kan alleen als de service niet onder een AD account maar met een build-in account is gestart zoals SYSTEM of NETWORK SERVICES. Onderstaande voorbeeld registreert een SPN voor SQL Server default instance voor de server SQLServer1

setspn –S MSSQLSvc/SQLServer1:1433  SQLServer1

Een overzicht van alle bestaande SPN’s kun je opvragen met de optie –L van setsp.exe.

C:\>setspn -L contoso\svcsqlserver1
Registered ServicePrincipalNames for CN=svcSQLServer1,CN=Users,DC=Contoso,DC=com:
        MSSQLSvc/SQLServer1.contoso.com
        MSSQLSvc/SQLServer1.contoso.com:1433
        MSSQLSvc/SQLServer1
        MSSQLSvc/SQLServer1:1433

Het is niet mogelijk om een SPN te registreren op een service die werkt met een local user zoals “SQLServer1\User1” omdat deze accounts niet bekend zijn in AD.

Je dient voor alle service accounts van de services die in de “double hop” voor komen de noodzakelijke SPN’s aan te maken. Dit geldt dus voor het service account van Server 1 als voor het service account van Server 2.

Hieronder is beschreven welke SPN’s je aan moet maken voor de verschillende onderdelen van SQL Server.

3a. SPN voor SQL Server

Bij het opstarten van SQL Server probeert deze automatisch een SPN te registreren. Dat lijkt leuk maar er kleven twee nadelen aan deze registratie. Het service account heeft niet altijd voldoende rechten om een SPN in AD te registeren. Het advies van Microsoft is zelfs om een service account NIET deze rechten te geven. Deze rechten kunnen een beveiligingsrisico zijn. Tevens wordt door SQL Server alleen de meest gebruikte SPN geregistreerd. Het kan dus voorkomen dat een noodzakelijke SPN niet door SQL server zelf wordt aangemaakt. Het is vaak beter om de SPN’s handmatig aan te maken.

Welke SPN je moet aanmaken is afhankelijk van de volgende aspecten:

  • Servernaam die wordt gebruik in de connection string: NetBIOS , FQDN of DNS Alias
  • Gebruikte protocol: TCP of named pipes
  • Default instance of named instance

Als je zeker wilt zijn dat Kerberos werkt kun je het beste alle mogelijke combinaties registreren. Dit voorkomt achteraf dat je toch die ene SPN nodig had.

Als computer name dien je een SPN te registreren voor zowel de NetBIOS naam en voor de FQDN (Fully Qualified Domain Name). De NetBIOS naam is de verkorte servernaam zoals SQLServer1 in onderstaand voorbeeld. De FQDN naam is de volledige naam inclusief de toevoegingen het domein waar de server in staat zoals SQLServer1.contoso.com

Voor het TCP protocol dien je een poortnummer van SQL Server te specificeren. Voor het protocol named pipes kun je volstaan met de <computername> bij een default instance. Bij een named instance dien je <computername>:<instancename> op te geven. Het TCP protocol wordt in de praktijk het meeste gebruikt. Named pipes wordt minder gebruikt, maar dat kan afhankelijk zijn van de applicaties die worden gebruikt.  Met protocol wordt het protocol bedoeld dat wordt gebruikt tussen server 1 en server 2. Het protocol dat de client PC gebruikt is hier niet van belang.

Als je de opties voor computername en protocol met elkaar combineert levert dat een setje op van 4 SPN’s. Bij het gebruik van een named instance moet aanvullend ook de serverbrowser als SPN te worden geregistreerd.

Het volledige setje van SPN’s wordt dan voor server SQLServer1 met service account svcSQLServer1 voor de default instance:

setspn –S MSSQLSvc/SQLServer1:1433  CONTOSO\svcSQLServer1
setspn –S MSSQLSvc/SQLServer1  CONTOSO\svcSQLServer1
setspn –S MSSQLSvc/SQLServer1.contoso.com:1433  CONTOSO\svcSQLServer1
setspn –S MSSQLSvc/SQLServer1.contoso.com  CONTOSO\svcSQLServer1

En voor een named instance INSTANCE00 op poort 61499 is het volledige setje, inclusief de server browser (uitgaande dat server browser met hetzelfde account werkt):

setspn –S MSSQLSvc/SQLServer1:61499  CONTOSO\svcSQLServer1
setspn –S MSSQLSvc/SQLServer1:INSTANCE00  CONTOSO\svcSQLServer1
setspn –S MSSQLSvc/SQLServer1.contoso.com:61499  CONTOSO\svcSQLServer1
setspn –S MSSQLSvc/SQLServer1.contoso.com:INSTANCE00  CONTOSO\svcSQLServer1
setspn –S MSOLAPDisco.3/SQLServer1  CONTOSO\svcSQLServer1
setspn –S MSOLAPDisco.3/SQLServer1.contoso.com  CONTOSO\svcSQLServer1

Als je voor je server een extra DNS alias registratie hebt, en je wilt deze gebruiken in de connection string dien je deze ook deze te registreren als SPN voor beide protocol varianten. Voor bovenstaand voorbeeld zou de DNS “mydns.contoso.com” de volgende extra regels opleveren voor de named instance:

setspn –S MSSQLSvc/mydns.contoso.com:61499  CONTOSO\svcSQLServer1
setspn –S MSSQLSvc/mydns.contoso.com:INSTANCE00  CONTOSO\svcSQLServer1
setspn –S MSOLAPDisco.3/mydns.contoso.com  CONTOSO\svcSQLServer1

Bij een default instance kan de extra registratie voor de server browser achterwege blijven.

3b. SPN voor Analysis Service

De SPN’s voor Analysis service zijn iets eenvoudiger dan die voor SQL server. Welke SPN’s nodig zijn is afhankelijk van:

  • Server naam die wordt gebruik in de connection string: NetBIOS , FQDN of DNS alias
  • Default instance of named instances

Dit levert de volgende SPN’s voor een default instance van SSAS voor server ASServer1 met service account svcASServer1:

setspn –S MSOLAPSvc.3/ASServer1  CONTOSO\svcASServer1
setspn –S MSOLAPSvc.3/ASServer1.contoso.com  CONTOSO\svcASServer1

Bij de registratie van een SPN voor SSAS kun je geen poortnummer opgeven. Bij een named instance heb je de server browser nodig zodat een connectie de juiste poort kan vinden. Uitgaande dat server browser met hetzelfde account werkt levert dat de volgend SPN’s:

setspn –S MSOLAPSvc.3/ASServer1  CONTOSO\svcASServer1
setspn –S MSOLAPSvc.3/ASServer1.contoso.com  CONTOSO\svcASServer1
setspn –S MSOLAPDisco.3/ASServer1  CONTOSO\svcSAServer1
setspn –S MSOLAPDisco.3/ASServer1.contoso.com  CONTOSO\svcSAServer1

Als je voor je server een extra DNS alias hebt, en je wilt deze gebruiken in de connection string dien je ook deze te registreren als SPN. Voor bovenstaande voorbeeld zou de DNS alias “mydns.contoso.com” de volgende extra regels opleveren voor de named instance:

setspn –S MSOLAPSvc.3/mydns.contoso.com  CONTOSO\svcSAServer1
setspn –S MSOLAPDisco.3/mydns.contoso.com  CONTOSO\svcSAServer1

Bij een default instance kan de extra registratie voor de server browser achterwege blijven.

 

3c. SPN voor Reporting Service en IIS

Bij SSRS is er geen verschil tussen een default of named instance. Van belang zijn de volgende opties:

  • Server naam die wordt gebruik in de connection string: NetBIOS , FQDN of DNS alias
  • Gebruikte poort nummer

Je hoeft geen poort nummer op te geven als je kiest voor de standaard poort voor http (poort 80) of https(443).

setspn –S HTTP/RSServer1 CONTOSO\svcRSServer1
setspn –S HTTP/RSServer1.contoso.com  CONTOSO\svcRSServer1

Als je voor je server een extra DNS alias hebt en je wilt deze gebruiken in de connection string dien je deze ook te registreren als SPN. Voor bovenstaande voorbeeld zou de DNS alias “mydns.contoso.com” de volgende extra regels opleveren voor de named instance (dus ook de serverbrowser registreren):

setspn –S HTTP/mydns.contoso.com  CONTOSO\svcRSServer1

De SPN’s die je aanmaakt voor http zijn ook geschikt voor het https protocol.

Tot slot controleer of in de configuratie file RsReportServer.config onder de sectie  <AuthenticationTypes> de optie <RSWindowsNegotiate/> is opgenomen. Zonder deze regel zal SSRS geen Kerberos gebruiken, ook als de rest juist is geconfigureerd.

 

4. Aanmaken delegations op service account

De SPN’s die zojuist zijn aangemaakt zorgen er nog niet voor dat Kerberos gaat werken. Daarvoor moet er nu een delegation worden gemaakt tussen de service accounts en de SPN’s. De SPN’s zijn aangemaakt voor zowel server 1 als server 2 in de “double hop”. Om ervoor te zorgen dat server 1 de credentials kan  door geven aan server 2 moet er een relatie worden gedefinieerd tussen de twee service accounts.

Er dient een constrained delegation te worden gemaakt op service account 1 naar de SPN’s van service account 2

In Active Directory dien je het service account op te zoeken dat wordt gebruikt door server 1.

  1. Open het tabje Delegation en klik op Trust this computer for delegation to specified services only.
  2. Klik op Use any authentication protocol.
  3. Kies voor Add, en kies voor Users and Computers.
  4. Zoek het service account dat wordt gebruikt door server 2.
  5. Kies alle beschikbare SPN’s en voeg deze toe als delegations.

Voorbeeld van account svcSQLServer1 met Delegations naar de SPN’s van svcSQLServer2 die op bovenstaande wijze zijn toegevoegd.

Delegations voor account svcSQLServer1
Delegations voor account svcSQLServer1

Er is ook de optie voor “Trust this user for delegation to any service (Kerberos only)”. Dit wordt ook wel de unconstrained delegation genoemd. Het gebruik hiervan raad ik af omdat dit niet kan worden toegepast in combinatie met SharePoint Claims based authentication. Daarnaast kunnen er ook problemen ontstaan met het correct doorgeven van de user credentials als er in een multi-hop constrained en unconstrained delegation door elkaar worden gebruikt.

Uit bovenstaande configuratie kun je afleiden dat de SPN’s die zijn aangemaakt op service account voor server 1 uiteindelijk niet zijn gebruikt voor het inrichten van Kerberos. Een ‘eigenschap’ van Active Directory is dat je op een account alleen een delegation kunt maken als dit account ook een SPN heeft. Bij accounts zonder SPN is er geen tabje met ‘delegations’. Dit maakt het noodzakelijk dat eerst alle SPN’s zijn geregistreerd voordat de delegations kunnen worden aangemaakt. Theoretisch zou je voor account 1 iedere willekeurige SPN kunnen registreren. Mijn advies is, als je toch SPN’s moet aanmaken op een account, maak dan de juiste SPN’s. Mogelijk dat bij een toekomstige uitbreiding deze SPN’s alsnog nodig zijn.

 

5. Herstart services

Herstart alle services die betrokken zijn bij de “double hop”. Deze stap is eigenlijk optioneel. Het doel van het herstarten van de services is om oude en mogelijk foutieve Kerberos tickets kwijt te raken. Als je tijdens het inrichten van Kerberos geen poging hebt gedaan om de connectie te testen zullen er geen oude tickets aanwezig zijn zal Kerberos gewoon werken. Zit je in echter een “trial en error” situatie en ben je steeds kleine aanpassingen aan het testen, dan is het verstandig de services te herstarten om er zeker van te zijn dat foutieve tickets zijn verwijderd.

Een Kerberos ticket heeft een maximale geldigheid. Als er een langere tijd zit tussen het configureren van Kerberos en het testen van je verbinding zullen de oude tickets vervallen zijn. Bij het testen van de verbinding worden er nieuwe Kerberos tickets aangemaakt. De levensduur van een Kerberos ticket is een policy setting en staat bij Active Directory standaard op 600 minuten.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *