Kerberos: billetter, nøkler og pålitelige tjenester

Kerberos gjør det mulig for en bruker eller prosess å autentisere seg overfor en nettverkstjeneste uten å sende passordet til tjenesten. Klient og server stoler da på et Key Distribution Center (KDC), som utsteder tidsbegrensede billetter og øktnøkler. Ved passordbasert pålogging avledes det likevel en langsiktig nøkkel fra passordet; passordkvalitet, pre-autentisering og beskyttelsen av klienten er derfor fortsatt sikkerhetsrelevante (RFC 4120, avsnitt 1.1 og 1.2, RFC 3961, avsnitt 3).

For meldings- og katalogadministratorer ligger Kerberos ofte ved siden av LDAP, ikke i stedet for det. LDAP transporterer katalogoperasjoner; Kerberos kan levere identiteten for en LDAP-økt via SASL. Nettgrensesnitt bruker HTTP Negotiate, Windows-tjenester SSPI og Unix-applikasjoner som regel GSS-API. En feil kan derfor oppstå i DNS, tid, KDC-tilgjengelighet, realm-tilordning, billettbuffer, SPN, tjenestekonto, keytab, krypteringstype, PAC eller delegeringspolicy, selv om applikasjonen bare melder «Integrated Authentication failed».

Forklaringen følger en principal fra første kontakt med KDC-en via TGT og tjenestebillett til måltjenesten. Først deretter utdypes Active Directory-utvidelser, delegering, tidsavhengighet, diagnose og gjenoppretting.

Arkitekturtilnærming: pålitelig tredjepart

Kerberos distribuerer symmetriske nøkler via en pålitelig instans. KDC-en har tilgang til de langsiktige nøklene til principalene i sitt realm og samler logisk to tjenester: Authentication Service, AS, utsteder en Ticket-Granting Ticket, TGT; Ticket-Granting Service, TGS, bytter denne TGT-en mot en billett for en konkret applikasjonstjeneste. Klient/server-utvekslingen, AP, finner deretter sted mellom klient og tjeneste. En tjeneste kan normalt kontrollere en tjenestebillett med sin egen nøkkel uten å kontakte KDC-en på nytt ved hver pålogging (RFC 4120, avsnitt 1.2 og 3).

Denne modellen reduserer passordvidereformidling og sentrale nettkontroller, men skaper tydelige feilområder. Uten en tilgjengelig KDC kan nye billetter ikke utstedes; allerede eksisterende billetter kan fortsette å fungere til gyldigheten utløper. En kompromittert KDC-database eller realm-nøkkel truer derimot tillitskjeden for hele realmet. Kerberos er derfor ikke en tilstandsløs plattform for token-signaturer, men et distribuert system av KDC-tilstand, klientbuffere, tjenestenøkler, klokker og navnetjenester.

Kerberos autentiserer principaler og kan gi integritet eller konfidensialitet for en GSS-sikkerhetskontekst. Det krypterer ikke automatisk hele nyttedatastrømmen til en applikasjon og gir ikke Perfect Forward Secrecy for øktnøklene som distribueres i Kerberos-kjernen. Applikasjoner kan bruke Kerberos til å autentisere en separat beskyttet kanal; TLS forblir derfor et eget lag med egen serveridentitet og sertifikatkontroll ved HTTPS eller LDAPS (RFC 4120, avsnitt 10, RFC 4121, avsnitt 2 og 4).

Principaler, realmer og nøkkelmateriale

En Kerberos-principal er et navn innenfor et realm. Brukere vises ofte som alice@EXAMPLE.CH, tjenester som HTTP/intranet.example.ch@EXAMPLE.CH. Delen foran @ kan inneholde flere komponenter; store og små bokstaver er i utgangspunktet relevante i Kerberos-navnemodellen. Et DNS-domenenavn og et Kerberos-realm er forskjellige navnerom, selv om realmer vanligvis ser ut som DNS-domener med store bokstaver. Klienter trenger derfor en kontrollerbar tilordning fra vertsnavn eller DNS-domene til realm (RFC 4120, avsnitt 6.1 og 7.2.3, MIT Kerberos: Mapping hostnames onto realms).

Langsiktige nøkler tilhører principaler. Øktnøkler opprettes for en begrenset utveksling. En billett inneholder blant annet klient, server, realm, tidsfelt, flagg, øktnøkkel og Authorization Data; dens krypterte del er beskyttet med en nøkkel til måltjenesten. Klienten mottar den samme øktnøkkelen i en responsdel som er beskyttet for klienten. Den kan dermed transportere billettinnholdet, men ikke selv endre den delen som er kryptert for tjenesten (RFC 4120, avsnitt 5.3 og 5.4).

Key Version Number, KVNO, skiller generasjoner av en principal-nøkkel. Encryption Type, Enctype, angir algoritme, nøkkellengde, String-to-Key og kontrollsum. En tjeneste kan ha flere keytab-oppføringer for samme principal med forskjellige KVNO-er eller enctypes for å tåle en kontrollert rotasjon. Hvis billettens KVNO og enctype ikke samsvarer med noen tilgjengelig tjenestenøkkel, kan tjenesten ikke dekryptere billetten. «SPN finnes» beviser derfor ennå ikke at det finnes en passende nøkkel på målsystemet (RFC 4120, avsnitt 5.2.9, MIT Kerberos: Keytabs).

Active Directory lagrer SPN-er i det flerverdige attributtet servicePrincipalName på en bruker- eller datamaskinkonto. SPN-en kobler tjenestenavnet som klienten setter sammen, til nøyaktig den kontoen hvis nøkkel KDC-en bruker for tjenestebilletten. Et alias, et navn på en lastbalanserer eller en endret tjenestekonto krever derfor en bevisst SPN-tilordning. Dupliserte SPN-er er tvetydige innenfor søkeområdet; en SPN på feil konto fører typisk til at tjenesten ikke kan dekryptere den utstedte billetten (Microsoft: Service principal names, Microsoft: setspn).

En keytab er ikke en eksportfil med en identitet som kan gjenopprettes vilkårlig, men en samling reelle langsiktige nøkler. Hver oppføring inneholder principal, KVNO, enctype og nøkkel. Den som kan lese filen, kan utgi seg for å være denne principalen. MIT anbefaler lokal, restriktiv lagring og ingen ubeskyttet overføring. Ved interoperabilitet med Active Directory kan ktpass koble principal, konto og keytab; de valgte parameterne kan da påvirke passord, salt, KVNO eller enctype og må inngå i en testet rotasjonsprosess, ikke på en engangs installasjonslapp (MIT Kerberos: Application servers).

Når principal, realm og nøkler er avklart, kan billettflyten leses som tre påfølgende samtaler: AS, TGS og til slutt applikasjonstjenesten.

Protokollflyt: AS, TGS og AP

AS-utvekslingen begynner med KRB_AS_REQ. En KDC kan svare med KDC_ERR_PREAUTH_REQUIRED og angi de støttede pre-autentiseringsprosedyrene. Med det utbredte krypterte tidsstempelet beviser klienten kjennskap til sin langsiktige nøkkel før KDC-en utsteder en TGT. KRB_AS_REP inneholder TGT-en, som er kryptert for TGS-en, og en responsdel for klienten. PKINIT erstatter dette første beviset med offentlig nøkkel-kryptografi og sertifikater; Kerberos FAST kan herde pre-autentisering i en beskyttet tunnel (RFC 4120, avsnitt 3.1 og 5.2.7, RFC 4556, RFC 6113, avsnitt 5).

I TGS-utvekslingen sender klienten KRB_TGS_REQ med TGT-en, en autentikator og ønsket tjenesteprincipal. KDC-en kontrollerer realm-policy, billettflagg, målprincipal og støttede nøkler og leverer i KRB_TGS_REP en tjenestebillett pluss en ny klient/tjeneste-øktnøkkel. Brukerpassordet behøves ikke igjen. En allerede eksisterende TGT kan derfor brukes for mange tjenester, til levetid, policy eller buffertilstand krever en ny initialautentisering (RFC 4120, avsnitt 3.3).

Ved AP-utvekslingen presenterer klienten KRB_AP_REQ for tjenesten: tjenestebilletten og en fersk autentikator beskyttet med øktnøkkelen. Tjenesten dekrypterer billetten med sin langsiktige nøkkel, kontrollerer målprincipal, tider, flagg og replay-tilstand og mottar derfra øktnøkkelen. Hvis klienten ber om gjensidig autentisering, svarer tjenesten med KRB_AP_REP. Først dette svaret beviser kryptografisk for klienten at motparten har tjenestenøkkelen (RFC 4120, avsnitt 3.2 og 5.5).

Pre-autentisering beskytter ikke mot alle offline-angrep, men endrer forutsetningen. Kontoer uten påkrevd pre-autentisering kan levere et AS-svar der den passordbeskyttede delen kan kontrolleres offline. Tjenestebilletter kan også analyseres offline; svake passord for tjenestekontoer og RC4 forsterker denne risikoen. Den effektive beskyttelsen består av pre-autentisering, sterke tilfeldige tjenestenøkler eller gMSA, moderne enctypes, begrensede rettigheter og revisjonsdata, ikke bare av at Kerberos finnes (RFC 6113, avsnitt 1, RFC 8429, avsnitt 5, Microsoft: Detect and remediate RC4 usage).

Billetter, tider, flagg og transport

En billett har authtime, valgfritt starttime, endtime og, for fornybare billetter, renew-till. TGT-en er ikke et universelt tilgangstoken: Den er rettet mot TGS-en og brukes til å hente flere billetter. En tjenestebillett er rettet mot nøyaktig serverprincipalen. Levetid og fornyelse styres av KDC-policy og kan begrenses per realm eller konto. Faste verdier som «ti timer» er derfor produktstandarder, ikke en egenskap ved Kerberos-standarden (RFC 4120, avsnitt 2.3 og 5.3).

Flagg som forwardable, forwarded, proxiable, proxy, renewable, initial, pre-authent og ok-as-delegate endrer hvordan en billett kan brukes. De er ikke dekorative diagnosefelt. Et double hop kan mislykkes selv om den første tjenestebilletten er gyldig, fordi et nødvendig flagg eller en KDC-policy mangler. Omvendt utvider en videresendbar TGT virkningen av en kompromittert tjeneste. Billettflagg hører derfor til ethvert delegerings- og hendelsesbevis (RFC 4120, avsnitt 2).

Autentikatorer og enkelte pre-autentiseringsmetoder bruker tid til å kontrollere ferskhet. RFC 4120 lar tillatt avvik være åpen som lokal policy. Active Directory bruker fem minutter som standard; denne toleransen erstatter ikke presis tidssynkronisering. Klient, KDC og måltjeneste er avgjørende: En klient kan få en billett og likevel mislykkes hos tjenesten med KRB_AP_ERR_SKEW dersom klokken der avviker (RFC 4120, avsnitt 3.2.3 og 7.5.1, Microsoft: Kerberos troubleshooting guidance, Microsoft: Windows Time Service).

Kerberos bruker port 88 over UDP og TCP. RFC 4120 krever TCP-støtte og beskriver UDP som valgfritt; for store UDP-svar kan med KRB_ERR_RESPONSE_TOO_BIG utløse et nytt forsøk over TCP. PAC, gruppemedlemskap og andre Authorization Data øker billettstørrelsen. En brannmur som bare tillater små UDP-tester eller blokkerer TCP 88, kan derfor skape feil som avhenger av bruker eller gruppe (RFC 4120, avsnitt 7.2.1, Microsoft: Kerberos KDC configuration keys).

Tjenestebilletten er bare det kryptografiske beviset. For at HTTP, LDAP eller SMB skal kunne bruke den, bygger GSS-API, SSPI og SPNEGO Kerberos inn i det aktuelle applikasjonsprotokollet.

Innbygging i applikasjonsprotokoller

GSS-API gir applikasjoner en mekanismeuavhengig Security Context; RFC 4121 definerer Kerberos-V5-mekanismen for dette. Windows SSPI fyller en tilsvarende rolle. SPNEGO forhandler mellom tilbudte GSS-mekanismer og vises ofte som Negotiate i HTTP. Det synlige headernavnet beviser ikke automatisk at Kerberos ble valgt i stedet for NTLM. Diagnosen må fange den faktisk forhandlede mekanismen og det forespurte Target Name (RFC 4121, RFC 4178, Microsoft: Kerberos authentication overview).

SASL GSS-API binder den samme Kerberos-mekanismen inn i applikasjonsprotokoller. Dette er for eksempel mulig med LDAP, IMAP eller SMTP når klient og server tilbyr mekanismen. Etter en vellykket GSS-kontekst kan SASL Security Layers levere integritet eller konfidensialitet. Om de faktisk brukes og hvordan de spiller sammen med TLS, er konfigurasjon i den konkrete applikasjonen; GSSAPI i Capability-listen alene beviser verken SPN eller Channel Protection (RFC 4752).

Klienten danner tjenestenavnet av Service Class og målvert. For HTTP er vanligvis HTTP/fqdn, for LDAP ldap/fqdn relevant. Alias, CNAME, omvendt oppslag, proxy, klyngenavn og vertsnavnet i URL-en kan endre den dannede identiteten. Klienten må be om billetten for den samme principalen som den mottakende tjenesten har nøkkelen til. En lastbalanserer løser ikke denne bindingen; alle backendinstanser trenger en konsistent tjenesteidentitet og nøkkelstrategi (MIT Kerberos: Application servers – DNS, Microsoft: Service principal names).

Active Directory som Kerberos-realm

I Active Directory Domain Services er KDC-en integrert i domenekontrolleren. Bruker-, datamaskin- og tjenestekontoer er Kerberos-principaler; katalogen leverer nøkler, SPN-er, grupper, kontoflagg og policyer. krbtgt-kontoen representerer domenets TGS. KDC-tilgjengelighet og datakonsistens i KDC-en følger dermed DC Locator, DNS, AD-replikering, nettsteder og gjenopprettingsmodellen for AD DS, ikke en separat Kerberos-klyngeprotokoll (Microsoft: Kerberos authentication overview, MS-KILE: Kerberos V5 Synopsis, DC Locator).

AD legger vanligvis et Privilege Attribute Certificate, PAC, til billetter som Authorization Data. Det kan blant annet inneholde SIDs, gruppemedlemskap, profil- og policyinformasjon samt signaturer. KDC-en oppretter og signerer disse dataene; tjenesten bruker dem for Windows-autorisering eller lar dem eventuelt validere. Kerberos-kjerneautentisering og AD-autorisering er derfor separate utsagn: En kryptografisk gyldig principal har ikke automatisk ønsket tilgang (MS-PAC, MS-KILE: PAC Generation).

Nøkkelmateriale og SPN-attributter replikeres med Active Directory. Etter endringer i konto, passord eller SPN kan ulike DC-er derfor kortvarig bruke ulike tilstander. Hvis klienten for TGS og administratoren for kontrollen treffer ulike DC-er, virker en feil intermittent. Et robust bevis angir utstedende KDC, mål-DC for katalogoppslaget, KVNO, billett-enctype og replikeringsstatus. Dette gjelder særlig ved manuelle keytab-rotasjoner og tjenester på tvers av steder.

Valg av enctype er snittet av klienttilbud, KDC-policy, målkonto-nøkler og tjenestestøtte. AES-kompatibel programvare er ikke tilstrekkelig hvis kontoen ikke har tilsvarende nøkler eller msDS-SupportedEncryptionTypes og domenepolicy utelukker dem. RFC 8429 klassifiserer RC4 og 3DES for Kerberos som foreldet; Microsoft dokumenterer inventarisering via sikkerhetshendelsene 4768 og 4769. En utfasing begynner med måling og nøkkelgenerering, ikke med global deaktivering av én bit (RFC 8429, RFC 8009, Microsoft: Detect and remediate RC4 usage).

For Windows-tjenester reduserer Group Managed Service Accounts, gMSA, behovet for manuell administrasjon av passord og SPN. De erstatter imidlertid ikke kontrollen av hvilken identitet prosessen faktisk kjører under, hvilke verter som får lese det administrerte passordet, og hvilke SPN-er som er registrert på kontoen. For apparater eller Unix-tjenester er en keytab ofte fortsatt nødvendig; rotasjonen må synkroniseres med AD-kontoen (Microsoft: Service Accounts).

Innenfor et AD-domene er denne veien direkte. Ved tilgang på tvers av realm- eller domenegrenser kommer Cross-Realm-billetter og eventuelt flere mellomledd i tillegg.

Klareringsforhold og Cross-Realm-baner

Et realm-klareringsforhold slår ikke sammen principal-databaser. Cross-Realm-autentisering bruker TGT-er for krbtgt/TARGET@SOURCE og eventuelt flere mellomrealmer. Klienten følger en billettbane til den når realmet til måltjenesten. RFC 6806 supplerer med referrals og navnekanonisering, slik de særlig brukes i AD-miljøer. Banen som er synlig i bufferen, er derfor mer utsagnskraftig enn den generelle påstanden «klareringsforholdet er grønt» (RFC 4120, avsnitt 1.1 og 3.3.3, RFC 6806).

Retning og transitivitet for klareringsforhold, Selective Authentication, SID-filtrering, Name Suffix Routing og tilgjengelige enctypes begrenser hva en Cross-Realm-TGT praktisk muliggjør. SPN-er må være søkbare og entydige i riktig forest. Et lokalt setspn -Q-treff beviser ingen entydighet på tvers av forest; setspn har forest- og domenealternativer for dette. Diagnosen dokumenterer hver referral-TGT, ikke bare den siste feilen med tjenestebilletten (Microsoft: Windows Authentication Concepts, Microsoft: setspn).

En billett til frontenden gir ikke automatisk denne rett til å kontakte en backend på vegne av brukeren. Det er her double-hop-problemet begynner.

Delegering og Double Hop

Ved normal AP-utveksling mottar en frontend ingen fritt brukbar brukernøkkel. Skal den få tilgang til en backend på vegne av brukeren, trenger den en delegeringsmodell. Forwarded-TGT- eller unconstrained delegation gir tjenesten en gjenbrukbar TGT og utvider virkningen langt utover én enkelt backend. En kompromittert frontend kan bruke den til billetter til andre tjenester; denne formen er derfor en stor utvidelse av tillit (RFC 4120, avsnitt 2.5 og 2.6, MS-SFU: Protocol Overview).

Microsofts Service-for-User-utvidelser deler opp problemet. Med S4U2self kan en tjeneste hente en billett til seg selv på vegne av en bruker, for eksempel etter en annen frontend-autentisering. Med S4U2proxy ber den, under KDC-policy, om en billett til en annen tjeneste på vegne av denne brukeren. Klassisk constrained delegation lagrer tillatte mål på frontendkontoen; resource-based constrained delegation angir tillatte innringere på ressurskontoen. I begge tilfeller inngår mål-SPN, billettflagg, kontoinnstillinger og trustbane i avgjørelsen (MS-SFU: Overview, MS-SFU: Introduction).

Delegering er autorisering for videreformidling av identitet, ikke bare et kompatibilitetsvalg. Administratoren inventariserer frontendprincipal, backend-SPN-er, tillatte brukerklasser, Protocol Transition, trustgrenser og det teknisk minste målomfanget. En vellykket første hop beviser ikke den andre; en direkte backendtest i brukerens kontekst omgår omvendt delegeringsgrensen og kan gi et falskt positivt resultat.

Driftsmodell, overvåking og gjenoppretting

Etter billettflyt og delegering kommer driftsspørsmålet: Hvilken Kerberos-komponent må være tilgjengelig, hvilket bevis viser tilstanden og hva kan gjenopprettes i en nødsituasjon? Tabellen knytter disse spørsmålene til de involverte rollene.

Billettbuffere er driftstilstand. En brukerprosess, tjenestekonto, container eller Windows Logon Session kan se en annen buffer enn det interaktive administratorskallet. Å slette og hente en billett på nytt er en målrettet test, men ingen reparasjon av den underliggende SPN-, nøkkel- eller replikeringsårsaken. Før purge registreres principal, mål-SPN, KDC, KVNO, enctype, flagg og tidsfelt; ellers forsvinner det beste feilbeviset.

Windows logger TGT-forespørsler under 4768, tjenestebilletter under 4769, pre-autentiseringsfeil under 4771 og ytterligere AS-feil under 4772, dersom riktige Advanced Audit Policies er aktive. Volumet er høyt på KDC-er. Overvåking trenger derfor aggregering etter Result Code, klient, måltjeneste, DC og enctype samt baseliner, i stedet for å behandle hver vellykkede TGS Request som en alarm (Microsoft: Advanced Audit Policy Configuration).

Gjenoppretting avhenger av KDC-implementasjonen. I AD DS inngår KDC-data og krbtgt i modellen for System State- og forest-gjenoppretting; en vilkårlig databasefil eller en LDIF-eksport er ikke en gyldig Kerberos-sikkerhetskopi. Operatører av selvstendige MIT-realmer må sikre KDC-database, stash-/master key-materiale, konfigurasjon, ACL-er og replikering samlet. Tjeneste-keytabs må inventariseres i tillegg og etter en restore kontrolleres for konsistens mellom KVNO og nøkkel (Microsoft: Back up the System State data, MIT Kerberos: Backups of secure hosts).

Ved feilsøking kontrolleres veien baklengs: målnavn og SPN, eksisterende tjenestebillett, TGS-svar, TGT, realm-finning, DNS og tid.

Diagnoseverktøy

Diagnosen begynner fra samme nettverkssone, med samme målnavn, realm, bruker- eller tjenestekontekst og samme Logon Session som applikasjonen. Testdata bruker reserverte navn. Utdata fra billetter og keytabs kan avsløre principaler og infrastruktur; nøkkelmateriale må aldri havne i billetter, chat eller prosessargumenter.

Finn KDC og passordtjeneste via DNS

Resolve-DnsName -Type SRV "_kerberos._tcp.example.ch"
Resolve-DnsName -Type SRV "_kerberos._udp.example.ch"
Resolve-DnsName -Type SRV "_kpasswd._tcp.example.ch"

dig +short SRV _kerberos._tcp.example.ch
dig +short SRV _kerberos._udp.example.ch
dig +short SRV _kpasswd._tcp.example.ch

Resolve-DnsName og dig viser prioritet, vekt, port og Target. Deretter må A-/AAAA-oppløsning og tilgjengelighet for hvert leverte Target kontrolleres. RFC 4120 definerer DNS-SRV-oppdagelse, men tillater lokal realm-konfigurasjon; en tom SRV-test beviser derfor bare en feil dersom den konkrete klienten bruker DNS-oppdagelse (RFC 4120, avsnitt 7.2.3, RFC 2782).

Sammenlign tid og TCP-tilgjengelighet

w32tm /query /status
w32tm /stripchart /computer:dc1.example.ch /samples:5 /dataonly
Test-NetConnection dc1.example.ch -Port 88

timedatectl status
chronyc tracking
nc -vz dc1.example.ch 88

w32tm og timedatectl viser kilde og synkroniseringsstatus; chronyc supplerer med offset- og sporingsdata for Chrony. Test-NetConnection eller nc beviser bare TCP 88. UDP, KDC-protokoll, realm og pre-autentisering krever en faktisk AS-/TGS-test.

Hent og vis billetter på nytt målrettet

klist purge
klist get HTTP/intranet.example.ch
klist

kdestroy
KRB5_TRACE=/dev/stderr kinit alice@EXAMPLE.CH
kvno HTTP/intranet.example.ch@EXAMPLE.CH
klist -ef

Windows-klist arbeider i konteksten til den valgte Logon Session. Under MIT Kerberos sletter kdestroy, henter kinit og kvno samt viser klist credentials. KRB5_TRACE gjør KDC-valg og protokollbane synlig. Før purge eller kdestroy skal en eksisterende feilbillett dokumenteres.

Kontroller SPN og tjenestenøkkel mot hverandre

setspn -Q HTTP/intranet.example.ch
setspn -X -F
Get-ADUser svc-web -Properties @(
“servicePrincipalName”
“msDS-SupportedEncryptionTypes”
)

klist -kte /etc/krb5.keytab
kvno -k /etc/krb5.keytab \
  HTTP/intranet.example.ch@EXAMPLE.CH

setspn viser AD-målkontoen og søker med -X -F etter duplikater i hele forestet. Get-ADUser leser SPN-er og deklarerte enctypes; en manglende verdi har produktspesifikk fallback-semantikk og må ikke generelt tolkes som «ingen AES». MIT-klist viser principal, KVNO og enctype i keytaben; kvno -k ber om en billett og validerer den mot den angitte keytaben.

Knytt feil til en protokollfase

Feilkodene er standardisert i RFC 4120; Windows legger til status- og revisjonskontekst. Automatisering bør beholde den numeriske koden, fasen, KDC-en, klientprincipalen og målprincipalen. Fritekst alene er verken stabil eller entydig. For pakkeanalyse kan Wireshark filtrere på kerberos; krypterte billettdeler forblir med hensikt uleselige uten passende nøkler (RFC 4120, avsnitt 7.5.9, Microsoft: Kerberos troubleshooting guidance).

Teknisk historie

Kerberos oppsto tidlig på 1980-tallet i MIT Project Athena. Protokollen bygger konseptuelt på arbeider om pålitelig tredjepart av Needham og Schroeder samt Denning og Sacco. Versjonene 1 til 4 ble utviklet i Athena-miljøet; versjon 4 var den første bredt anvendte utgaven. Navnet viser til Kerberos, den flerhodede vokteren i gresk mytologi, og står for KDC-ens sentrale tillitsrolle (RFC 4120, avsnitt 1, MIT Kerberos Consortium: Documentation).

Kerberos V5 fjernet begrensninger i versjon 4 knyttet til navngivning, billettlevetider, kryptografi, Cross-Realm og utvidbarhet. RFC 1510 standardiserte V5 i 1993. RFC 4120 erstattet denne spesifikasjonen i 2005 med presiseringer og en fullstendig ASN.1-beskrivelse. Protokollfamilien ble deretter utvidet modulært, blant annet med PKINIT, Pre-Authentication Framework og FAST, GSS-API, referrals samt nye AES-profiler (RFC 1510, RFC 4120, RFC 4556, RFC 6113).

Microsoft gjorde Kerberos V5 til den sentrale domenautentiseringsprotokollen med Windows 2000 og koblet den til AD-principaler, SPN-er, PAC, SSPI, trust-referrals og delegeringsutvidelser. Samtidig forble MIT Kerberos, Heimdal og andre implementasjoner interoperable via IETF-protokoller og GSS-API. Kryptografien utviklet seg fra DES og senere RC4 til AES-profiler; RFC 8429 innledet utfasing av 3DES og RC4 i 2018. Den tekniske historien forklarer hvorfor eldre enheter, gamle tjenestekontoer og trust-nøkler fortsatt synliggjør enctype-grenser, uten at artikkelen fastslår en flyktig produktversjonsstatus (MS-KILE, RFC 3962, RFC 8009, RFC 8429).

Kilder

• IETF RFC 3244 – Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols
• MIT Kerberos – Mapping Hostnames onto Kerberos Realms
• IANA – Kerberos service names and ports
• RFC 4120 – The Kerberos Network Authentication Service (V5) – arkitektur, meldinger, billetter, flagg, feilkoder, transport og sikkerhetsmodell.
• RFC 3961, avsnitt 3
• RFC 4121 – Kerberos V5 GSS-API Mechanism – GSS-kontekst, tokens, integritet og konfidensialitet.
• MIT Kerberos: Mapping hostnames onto realms
• MIT Kerberos – Keytabs – keytab-innhold, KVNO, enctype og nøkkel.
• Microsoft – Service principal names – SPN-entydighet og binding til tjenestekontoer.
• Microsoft – setspn – SPN-forespørsel, registrering og søk etter duplikater.
• Microsoft – ktpass – AD-/keytab-interoperabilitet.
• MIT Kerberos – Application servers – keytab-beskyttelse, rotasjon, klokke og DNS.
• RFC 4556 – PKINIT – Public-Key-Pre-Authentication.
• RFC 6113 – Generalized Framework for Kerberos Pre-Authentication – pre-auth-rammeverk og FAST.
• RFC 8429 – Deprecate 3DES and RC4 in Kerberos – IETF Best Current Practice for foreldede enctypes.
• Microsoft – Detect and remediate RC4 usage – enctype-inventar, kontonøkler og hendelser.
• Microsoft – Kerberos authentication troubleshooting guidance – Windows-feilkoder, tid, SPN og Double Hop.
• Microsoft – Windows Time Service – tidstjeneste og Kerberos-avhengighet.
• Microsoft – Kerberos KDC registry and protocol settings – UDP-størrelse, TCP-fallback og KDC-diagnose.
• RFC 4178 – SPNEGO – forhandling av GSS-mekanismer.
• Microsoft – Kerberos authentication overview – Windows-arkitektur, KDC, SSPI og gjensidig autentisering.
• RFC 4752 – SASL GSS-API Mechanism – innbygging i LDAP, IMAP, SMTP og andre SASL-protokoller.
• MS-KILE – Kerberos V5 Synopsis – AS-, TGS- og AP-utveksling i Windows.
• MS-PAC – Privilege Attribute Certificate – grupper, SIDs, profiler, policyer og signaturer.
• MS-KILE – PAC Generation – opprettelse av PAC-Authorization-Data.
• RFC 8009 – AES with HMAC-SHA2 for Kerberos 5 – AES-SHA2-enctypes.
• Microsoft – Service Accounts – gMSA, passord- og SPN-administrasjon.
• RFC 6806 – Kerberos Principal Name Canonicalization and Cross-Realm Referrals – referrals og navnekanonisering.
• Microsoft – Windows Authentication Concepts – klareringsforhold, Protocol Transition og constrained delegation.
• MS-SFU – Protocol Overview – delegeringsflyter og risikoen ved videresendte TGT-er.
• MS-SFU – Service for User Overview – S4U2self og S4U2proxy.
• MS-SFU – Introduction – Protocol Transition og constrained delegation.
• Microsoft – Advanced Audit Policy Configuration – hendelser 4768, 4769, 4771 og 4772.
• Microsoft – Back up the System State data – AD DS-/KDC-sikkerhetskopi.
• MIT Kerberos – kdb5_util – KDC-database og sikkerhetskopi i MIT Kerberos.
• Microsoft Learn – Resolve-DnsName – DNS-SRV-forespørsler i Windows.
• BIND 9 – dig manual – DNS-SRV-forespørsler på Unix-systemer.
• RFC 2782 – A DNS RR for specifying the location of services – SRV-prioritet, vekt, port og Target.
• Microsoft – w32tm – Windows-tidskilde og offsetdiagnose.
• Linux man-pages – timedatectl(1) – tidssynkroniseringsstatus på Linux.
• Chrony – chronyc – offset-, kilde- og sporingsdiagnose.
• Microsoft Learn – Test-NetConnection – TCP-tilkoblingsdiagnose i Windows.
• OpenBSD – nc(1) – TCP-porttest på Unix-systemer.
• Microsoft – klist – Windows-billettbuffere og test av tjenestebillett.
• MIT Kerberos – kdestroy – slett credential-buffer.
• MIT Kerberos – kinit – hent TGT og pre-auth-alternativer.
• MIT Kerberos – kvno – tjenestebillett og keytab-validering.
• MIT Kerberos – klist – visning av credential-buffer og keytab.
• MIT Kerberos – kerberos environment – KRB5_TRACE og buffer-/keytabvariabler.
• Microsoft Learn – Get-ADUser – SPN- og enctype-attributter for en tjenestekonto.
• Wireshark – Kerberos display filter reference – protokollfelt og displayfiltre.
• MIT Kerberos Consortium – Documentation – opprinnelse i Project Athena og versjonshistorie.
• RFC 1510 – The Kerberos Network Authentication Service (V5) – historisk V5-kjernespesifikasjon fra 1993.
• MS-KILE – Kerberos Protocol Extensions – Active Directory-Kerberos og Microsoft-utvidelser.
• RFC 3962 – AES Encryption for Kerberos 5 – AES-SHA1-profiler.