Als je meerdere servers in je serverpark hebt staan krijg je te maken met het “double hop scenario”. Kerberos wordt gebruikt wanneer een gebruiker vanaf zijn eigen systeem een connectie maakt naar server 1 en dat server 1 op zijn beurt weer resources gebruikt van server 2. Het is daarbij noodzakelijk om de user credentials mee door te geven voor de juiste security context. Het mechanisme dat Active Directory hiervoor gebruikt is Kerberos Contrained Delegations (KCD). Het uitwisselen van de user credentials tussen server 1 en 2 zal door kerberos mogelijk worden gemaakt.

Enkele gevallen waarbij kerberos nodig is:

1. Een SSRS server die gegevens leest uit een SSAS kubus of SQL Server database die op een andere server staat
2. Een linked servers connectie tussen twee SQL Servers instances die op verschillende servers staan
3. Als je rapporten in SharePoint zet die databronnen gebruiken die buiten de SharePoint farm staan

Double hop scenario:

Iedere keer weer blijkt kerberos weer een lastig thema om te configureren. Het is niet moeilijk, maar het is erg gemakkelijk om het verkeerd te doen. Je kunt zien dat kerberos niet werkt als je op server 1 bent inlogged en alles werkt correct maar vanaf een andere computer krijg je de volgende melding:

Kerberos is een typisch iets van Active Directory dus om gebruik te kunnen maken van kerberos dienen alle servers opgenomen te zijn een Active Directory domain. Ook de configuratie zal voornamelijk plaats vinden in AD. Dit is gelijk ook het grootste struikelblok van kerberos. In veel grotere organisaties is het beheer van AD voorbehouden aan de afdeling met AD beheerders en heb je als DBA daar geen toegang toe. De wereld van een AD beheerder bestaat uit infra structuur en user accounts terwijl kerberos configuratie een onderdeel is van applicatie beheer. Ik heb meer dan eens een AD beheerder moeten uitleggen wat kerberos is en waar we het voor nodig hebben.

Het configureren van kerberos gebeurt in 4 stappen. De stappen dienen in onderstaande volgorde te worden uitgevoerd.

1. Herstart services met een AD service account
2. Registreer spn’s voor de service accounts
3. Aanmaken delegations op service account
4. Herstaren services

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

1. 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 ReportServertempbd databases en moet je voor het wijzigen van het service account eerst een backup maken van de encription keys.

Gebruik bij voorkeur de “SQL Server Configuration Manager” voor het wijzigen van het service account bij SQL Server. 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 bij de 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. SharePoint bestaat uit meerdere services en service accounts die betrokken kunnen zijn bij de kerberos constrained delegation. Vraag ook na of de Claims to Windows Token Services (C2WTS) is gestart.

2. Registreer spn’s voor de service accounts

Een spn is een “Service Principal Name” die je registreert in AD op een service account. 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 geregisterd op meerder accounts. Als dit toch word gedaan zal kerberos authenticatie niet meer werken. Gebruik daarom bij voorkeur de setspn –s switch ipv 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 ipv op het service account. Dit kan alleen als de service niet onder een AD account maar 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

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” voorkomen de noodzakelijke spn’s aan te maken. Dit geld dus voor het service account van Server 1 als voor het service account van Server 2.

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

2a. 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 beveiliging risico 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.

Hierdoor kan het noodzakelijk of gewenst zijn om de spn’s handmatig aan te maken. Welke spn je moet aanmaken is afhankelijk van de volgende aspecten:

• Server naam 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 voor optie veilig gaat kun je het beste mogelijke alle combinaties registreren. Dit voorkomt achteraf dat je toch die ene spn nodig had.

Bij het registreren van een spn dien je een computer name op te geven. Je dient 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 on onderstaande voorbeeld. De FQDN naam is de volledige naam inclusief de toevoegingen van het domein waar de server in staat zoals SQLServer1.contoso.com

Bij het gebruik van het TCP protocol dien je het 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 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 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

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

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 te registreren als spn voor beide protocol varianten. Voor bovenstaande 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.

2b. 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 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 op:

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\svcASServer1 

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\svcSQLServer1 setspn –s MSOLAPDisco.3/mydns.contoso.com  CONTOSO\svcSQLServer1 

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

2c. 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 poorten voor http (poort 80). 

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 gebruik met van 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, zelfs als de rest juist is geconfigureerd.

3. Aanmaken delegations op service account

De spn’s die zojuist zijn aangemaakt maken nog niet dat kerberos gaat werken. Er dient nu een delegation te worden gemaakt tussen 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 credetials 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

Uit bovenstaande 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, registreer dan gelijk de juiste spn’s. Mogelijk dat bij een toekomstige uitbreiding deze spn’s alsnog nodig zijn.

4. Herstart services

Herstart alle services die betroken 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 nog geen poging hebt gedaan om de connectie te testen zullen er ook geen oude tickets aanwezig en 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 en 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.