Kerberos-auth naar SQL of een interne web-app faalt, ik vermoed SPN-issues.
Service Principal Names (SPNs) koppelen een service aan een AD-account. Bij dubbele of missende SPN's faalt Kerberos-auth en val je terug op NTLM, of het werkt helemaal niet.
Probeer dit eerst zelf
- 1Identificeer dubbele SPN's: setspn -X (in heel het forest). Een SPN mag maar één keer voorkomen.
- 2Voor SQL: SPN's moeten op het service-account staan, niet op het computer-account, als SQL onder een domain-account draait. Format: MSSQLSvc/server.fqdn:1433 en MSSQLSvc/server.fqdn:instance.
- 3Voor IIS: SPN op de app-pool identity. Format: HTTP/siteurl en HTTP/siteurl.fqdn. Beide hoofdletters voor 'HTTP'.
- 4Verkeerde of dubbele SPN: setspn -D verwijderen, setspn -A toevoegen op het juiste account. Documenteer wat je doet.
- 5Test: klist purge op client, opnieuw verbinden, klist toont een ticket voor de juiste service. Bij failure log: Event 4 op de client (KDC_ERR_S_PRINCIPAL_UNKNOWN of KRB_AP_ERR_MODIFIED).
Wanneer ons inschakelen
Bij gMSA (group Managed Service Accounts): SPN's worden automatisch beheerd. Voor moderne SQL-installs aan te raden, scheelt SPN-onderhoud handmatig.
Zie ook
- Eén DC of twee DC's voor een MKB-kantoor?Twee is bijna altijd het juiste antwoord; één DC is een single point of failure voor logon, DNS en GPO.
- Moet ik FSMO-rollen verdelen over twee DC's?Voor een klein domein mag alles op één DC; bij twee DC's is verdelen netter maar geen must.
- Hoe weet ik of mijn AD-replicatie gezond is?Replicatie-fouten sluipen er stilletjes in; ze worden pas zichtbaar als logins of GPO's gek doen.
Past het bovenstaande niet?
Beschrijf je situatie hieronder. We sturen jouw input plus de stappen die je al zag naar onze AI en geven gericht vervolg-advies. Als het te risicovol is om zelf te doen, zeggen we dat ook.
Of doe het helemaal niet zelf
Onze Managed IT-klanten zoeken dit soort vragen niet op. Eén aanspreekpunt, vaste prijs per maand, en het is binnen werktijd opgelost.