Jag ser Active Directory och Kerberos som en praktisk säkerhetsfråga där tekniken behöver kunna verifieras, inte bara beskrivas. Kerberos i Active Directory blir lättare att felsöka när man ser autentisering som biljetter mellan klient, KDC och tjänst i stället för som ett enda lösenordsögonblick.
Active Directory och Kerberos i praktiken
Första byggstenen: TGT används för att begära service tickets utan att skicka lösenordet till varje tjänst. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
En annan viktig del: SPN kopplar en tjänsteidentitet till ett konto. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det tekniska ankaret: Klocksynkronisering är viktig eftersom Kerberos är tidskänsligt. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Det som ofta avgör kvaliteten: NTLM-fallback kan dölja att Kerberos egentligen inte fungerar som tänkt. Det behöver kopplas till ett tydligt syfte och kunna observeras i den miljö där kontrollen faktiskt ska användas.
Ett arbetsflöde jag skulle använda
- Identifiera klient, användare, tjänst och DC i samma tidsfönster.
- Kontrollera SPN och DNS när service ticket uteblir.
- Granska Kerberos-event på klient och domain controller.
- Jämför lyckad och misslyckad autentisering.
- Bekräfta att tjänsten faktiskt använder Kerberos och inte fallback.
För Active Directory och Kerberos håller jag därför införandet i små steg. Då går det att skilja ett säkerhetsproblem från ett rent driftfel och att rulla tillbaka just den ändring som gav ett oväntat resultat.
Ett konkret scenario
Om en intern webbapp plötsligt ber om credentials trots Windows-integrerad inloggning tittar jag på DNS, SPN och tickets innan jag börjar ändra användarens lösenord. Felet kan ligga helt utanför kontot.
Vanliga sätt att göra kontrollen svagare
- Att felsöka genom att återställa lösenord utan att förstå ticketfelet.
- Att skapa duplicerade SPN.
- Att anta att lyckad åtkomst automatiskt betyder att Kerberos användes.
Vad som måste gå att bevisa
För Active Directory och Kerberos vill jag avsluta med mätbara efterkontroller i stället för att nöja mig med att en statusruta visar ”enabled”. De viktigaste kontrollerna här är:
- Förväntad service ticket kan observeras.
- Duplicerade eller felaktiga SPN saknas.
- Klockoffset är inom rimligt intervall.
Ett negativt test hör också till Active Directory och Kerberos: den väg, identitet eller operation som inte ska vara tillåten ska misslyckas på ett förutsägbart sätt. Då kan nästa tekniker upprepa kontrollen och förstå både avsikten och gränsen.
Slutsats
Active Directory och Kerberos – förstå biljetterna innan du felsöker autentisering handlar därför inte om att samla fler säkerhetsinställningar. Det handlar om att minska en konkret risk med en kontroll som har tydligt scope, tydlig ägare och ett verifierbart resultat. När före-läge, förändring och eftertest dokumenteras blir säkerhetsarbetet både säkrare och lättare att förvalta.