Kerberos: ticket, chiavi e servizi attendibili

Kerberos consente a un utente o a un processo di autenticarsi presso un servizio di rete senza inviare la password al servizio. A tale scopo, client e server si fidano di un Key Distribution Center (KDC), che rilascia ticket e chiavi di sessione a tempo limitato. In caso di accesso basato su password, dalla password viene comunque derivata una chiave a lungo termine; la qualità della password, la pre-autenticazione e la protezione del client restano quindi rilevanti per la sicurezza (RFC 4120, sezioni 1.1 e 1.2, RFC 3961, sezione 3).

Per gli amministratori di messaggistica e directory, Kerberos si affianca spesso a LDAP, non lo sostituisce. LDAP trasporta operazioni di directory; Kerberos può fornire l’identità per una sessione LDAP tramite SASL. Le interfacce web usano HTTP Negotiate, i servizi Windows SSPI, le applicazioni Unix di norma GSS-API. Un errore può quindi derivare da DNS, orario, raggiungibilità del KDC, mappatura del realm, cache dei ticket, SPN, account di servizio, keytab, tipo di crittografia, PAC o policy di delega, anche se l’applicazione segnala soltanto «Integrated Authentication failed».

La spiegazione segue un principal dal primo contatto con il KDC, attraverso TGT e service ticket, fino al servizio di destinazione. Solo in seguito vengono approfondite le estensioni di Active Directory, la delega, la dipendenza dal tempo, la diagnosi e il recovery.

Approccio architetturale: terza istanza attendibile

Kerberos distribuisce chiavi simmetriche tramite un’istanza attendibile. Il KDC accede alle chiavi a lungo termine dei principal del proprio realm e riunisce logicamente due servizi: l’Authentication Service, AS, rilascia un Ticket-Granting Ticket, TGT; il Ticket-Granting Service, TGS, scambia questo TGT con un ticket per uno specifico servizio applicativo. Lo scambio client/server, AP, avviene successivamente tra client e servizio. Un servizio può normalmente verificare un service ticket con la propria chiave, senza richiamare nuovamente il KDC a ogni accesso (RFC 4120, sezioni 1.2 e 3).

Questo modello riduce la trasmissione delle password e le verifiche online centralizzate, ma crea chiari domini di guasto. Senza un KDC raggiungibile non possono essere rilasciati nuovi ticket; i ticket già presenti possono continuare a funzionare fino alla fine della loro validità. Un database KDC compromesso o una chiave del realm compromettono invece la catena di fiducia dell’intero realm. Kerberos non è quindi una piattaforma stateless di firma di token, bensì un sistema distribuito costituito da stato del KDC, cache dei client, chiavi dei servizi, orologi e servizi dei nomi.

Kerberos autentica i principal e può fornire integrità o riservatezza per un contesto di sicurezza GSS. Non cifra automaticamente l’intero flusso di dati utili di un’applicazione e non offre Perfect Forward Secrecy per le chiavi di sessione distribuite nel nucleo Kerberos. Le applicazioni possono usare Kerberos per autenticare un canale protetto separatamente; TLS resta quindi un livello distinto con propria identità server e verifica del certificato per HTTPS o LDAPS (RFC 4120, sezione 10, RFC 4121, sezioni 2 e 4).

Principal, realm e materiale delle chiavi

Un principal Kerberos è un nome all’interno di un realm. Gli utenti sono spesso rappresentati come alice@EXAMPLE.CH, i servizi come HTTP/intranet.example.ch@EXAMPLE.CH. La parte prima di @ può contenere più componenti; nel modello di denominazione Kerberos le maiuscole/minuscole sono fondamentalmente rilevanti. Un nome di dominio DNS e un realm Kerberos sono spazi dei nomi diversi, anche se i realm hanno di norma l’aspetto di domini DNS in maiuscolo. I client necessitano quindi di un’associazione verificabile da hostname o dominio DNS a realm (RFC 4120, sezioni 6.1 e 7.2.3, MIT Kerberos: Mapping hostnames onto realms).

Le chiavi a lungo termine appartengono ai principal. Le chiavi di sessione sono generate per uno scambio limitato nel tempo. Un ticket contiene tra l’altro client, server, realm, campi temporali, flag, session key e Authorization Data; la sua parte cifrata è protetta con una chiave del servizio di destinazione. Il client riceve la stessa session key in una parte della risposta protetta per lui. Può quindi trasportare il contenuto del ticket, ma non modificare autonomamente la parte cifrata per il servizio (RFC 4120, sezioni 5.3 e 5.4).

Il Key Version Number, KVNO, distingue le generazioni di una chiave principal. L’Encryption Type, Enctype, definisce algoritmo, lunghezza della chiave, string-to-key e checksum. Un servizio può mantenere più voci keytab per lo stesso principal con KVNO o enctype diversi, per gestire una rotazione controllata. Se KVNO ed enctype del ticket non corrispondono ad alcuna chiave di servizio disponibile, il servizio non può decifrare il ticket. «SPN presente» non dimostra quindi ancora che sul sistema di destinazione sia disponibile una chiave adatta (RFC 4120, sezione 5.2.9, MIT Kerberos: Keytabs).

Active Directory memorizza gli SPN nell’attributo multivalore servicePrincipalName di un account utente o computer. Lo SPN collega il nome del servizio composto dal client all’esatto account la cui chiave il KDC usa per il service ticket. Un alias, il nome di un load balancer o un account di servizio modificato richiedono quindi un’associazione SPN consapevole. Gli SPN duplicati sono ambigui nel rispettivo ambito di ricerca; uno SPN sull’account errato porta tipicamente al fatto che il servizio non possa decifrare il ticket rilasciato (Microsoft: Service principal names, Microsoft: setspn).

Una keytab non è un file di esportazione con un’identità ripristinabile arbitrariamente, bensì una raccolta di chiavi reali a lungo termine. Ogni voce contiene principal, KVNO, enctype e chiave. Chi può leggere il file può impersonare quel principal. MIT raccomanda archiviazione locale e restrittiva e nessun trasferimento non protetto. Nell’interoperabilità con Active Directory, ktpass può collegare principal, account e keytab; i parametri scelti possono influire su password, salt, KVNO o enctype e devono far parte di un processo di rotazione testato, non di una nota di installazione una tantum (MIT Kerberos: Application servers).

Chiariti principal, realm e chiavi, il flusso dei ticket può essere letto come tre conversazioni successive: AS, TGS e infine il servizio applicativo.

Flusso del protocollo: AS, TGS e AP

Lo scambio AS inizia con KRB_AS_REQ. Un KDC può rispondere con KDC_ERR_PREAUTH_REQUIRED e indicare i metodi di pre-autenticazione supportati. Con il diffuso timestamp cifrato, il client dimostra di conoscere la propria chiave a lungo termine prima che il KDC rilasci un TGT. KRB_AS_REP contiene il TGT, cifrato per il TGS, e una parte della risposta per il client. PKINIT sostituisce questa prima prova con crittografia a chiave pubblica e certificati; Kerberos FAST può rafforzare la pre-autenticazione in un tunnel protetto (RFC 4120, sezioni 3.1 e 5.2.7, RFC 4556, RFC 6113, sezione 5).

Nello scambio TGS, il client invia KRB_TGS_REQ con il TGT, un authenticator e il service principal richiesto. Il KDC verifica policy del realm, flag del ticket, principal di destinazione e chiavi supportate e fornisce in KRB_TGS_REP un service ticket più una nuova client/service session key. La password dell’utente non è più necessaria. Un TGT già presente può quindi essere usato per molti servizi, finché lifetime, policy o stato della cache non richiedono una nuova autenticazione iniziale (RFC 4120, sezione 3.3).

Nello scambio AP, il client presenta al servizio KRB_AP_REQ: il service ticket e un authenticator nuovo, protetto con la session key. Il servizio decifra il ticket con la propria chiave a lungo termine, verifica principal di destinazione, tempi, flag e stato di replay e ne ricava la session key. Se il client richiede l’autenticazione reciproca, il servizio risponde con KRB_AP_REP. Solo questa risposta dimostra crittograficamente al client che la controparte possiede la chiave del servizio (RFC 4120, sezioni 3.2 e 5.5).

La pre-autenticazione non protegge da ogni attacco offline, ma modifica il presupposto. Gli account senza pre-autenticazione obbligatoria possono fornire una risposta AS la cui parte protetta da password può essere verificata offline. Anche i service ticket sono analizzabili offline; password deboli degli account di servizio e RC4 aggravano questo rischio. La protezione efficace consiste in pre-autenticazione, chiavi di servizio casuali robuste o gMSA, enctype moderni, diritti limitati e dati di audit, non nella mera presenza di Kerberos (RFC 6113, sezione 1, RFC 8429, sezione 5, Microsoft: Detect and remediate RC4 usage).

Ticket, tempi, flag e trasporto

Un ticket possiede authtime, opzionalmente starttime, endtime e, per i ticket rinnovabili, renew-till. Il TGT non è un token di accesso universale: è indirizzato al TGS e serve a ottenere altri ticket. Un service ticket è indirizzato a un preciso server principal. Lifetime e rinnovo sono regolati dalla policy del KDC e possono essere limitati per realm o account. Valori fissi quali «dieci ore» sono quindi default di prodotto, non una proprietà dello standard Kerberos (RFC 4120, sezioni 2.3 e 5.3).

Flag quali forwardable, forwarded, proxiable, proxy, renewable, initial, pre-authent e ok-as-delegate modificano l’utilizzabilità di un ticket. Non sono campi diagnostici decorativi. Un double hop può fallire anche se il primo service ticket è valido, perché manca un flag necessario o una policy KDC. Viceversa, un TGT forwardable amplia l’impatto di un servizio compromesso. I flag dei ticket fanno quindi parte di ogni evidenza relativa a delega e incidenti (RFC 4120, sezione 2).

Gli authenticator e alcuni metodi di pre-autenticazione usano il tempo per verificare la freshness. RFC 4120 lascia la deviazione consentita a una policy locale. Active Directory usa cinque minuti per impostazione predefinita; questa tolleranza non sostituisce una sincronizzazione precisa dell’ora. Sono determinanti client, KDC e servizio di destinazione: un client può ricevere un ticket e fallire comunque sul servizio con KRB_AP_ERR_SKEW se il suo orologio è fuori fase (RFC 4120, sezioni 3.2.3 e 7.5.1, Microsoft: Kerberos troubleshooting guidance, Microsoft: Windows Time Service).

Kerberos usa la porta 88 su UDP e TCP. RFC 4120 richiede il supporto TCP e descrive UDP come opzionale; risposte UDP troppo grandi possono attivare un nuovo tentativo TCP con KRB_ERR_RESPONSE_TOO_BIG. PAC, appartenenze ai gruppi e ulteriori Authorization Data ingrandiscono i ticket. Un firewall che consente solo piccoli test UDP o blocca TCP 88 può quindi generare guasti dipendenti dall’utente o dal gruppo (RFC 4120, sezione 7.2.1, Microsoft: Kerberos KDC configuration keys).

Il service ticket è soltanto la prova crittografica. Affinché HTTP, LDAP o SMB possano usarlo, GSS-API, SSPI e SPNEGO incorporano Kerberos nel rispettivo protocollo applicativo.

Integrazione nei protocolli applicativi

GSS-API fornisce alle applicazioni un Security Context indipendente dal meccanismo; RFC 4121 definisce a tale scopo il meccanismo Kerberos V5. Windows SSPI svolge un ruolo comparabile. SPNEGO negozia tra i meccanismi GSS proposti e in HTTP appare spesso come Negotiate. Il nome dell’header visibile non prova automaticamente che sia stato scelto Kerberos anziché NTLM. La diagnosi deve rilevare il meccanismo effettivamente negoziato e il Target Name richiesto (RFC 4121, RFC 4178, Microsoft: Kerberos authentication overview).

SASL GSS-API integra lo stesso meccanismo Kerberos nei protocolli applicativi. Ciò è possibile, ad esempio, con LDAP, IMAP o SMTP, se client e server offrono il meccanismo. Dopo un contesto GSS riuscito, i Security Layer SASL possono fornire integrità o riservatezza. Se vengano effettivamente usati e come interagiscano con TLS dipende dalla configurazione della specifica applicazione; GSSAPI nell’elenco delle capability da solo non dimostra né SPN né Channel Protection (RFC 4752).

Il client forma il nome del servizio da service class e host di destinazione. Per HTTP è tipicamente rilevante HTTP/fqdn, per LDAP ldap/fqdn. Alias, CNAME, reverse lookup, proxy, nome del cluster e hostname nell’URL possono modificare l’identità composta. Il client deve richiedere il ticket per lo stesso principal la cui chiave possiede il servizio accettante. Un load balancer non risolve questo vincolo; tutte le istanze backend necessitano di un’identità di servizio e di una strategia delle chiavi coerenti (MIT Kerberos: Application servers – DNS, Microsoft: Service principal names).

Active Directory come realm Kerberos

In Active Directory Domain Services, il KDC è integrato nel controller di dominio. Account utente, computer e servizio sono principal Kerberos; la directory fornisce chiavi, SPN, gruppi, account flag e policy. L’account krbtgt rappresenta il TGS del dominio. Disponibilità del KDC e coerenza dei dati KDC seguono quindi DC Locator, DNS, replica AD, siti e modello di recovery di AD DS, non un protocollo cluster Kerberos separato (Microsoft: Kerberos authentication overview, MS-KILE: Kerberos V5 Synopsis, DC Locator).

AD aggiunge normalmente ai ticket un Privilege Attribute Certificate, PAC, come Authorization Data. Può contenere tra l’altro SID, appartenenze ai gruppi, informazioni di profilo e policy, nonché firme. Il KDC genera e firma questi dati; il servizio li usa per l’autorizzazione Windows o eventualmente li fa convalidare. Autenticazione Kerberos di base e autorizzazione AD sono quindi affermazioni distinte: un principal crittograficamente valido non possiede automaticamente l’autorizzazione desiderata (MS-PAC, MS-KILE: PAC Generation).

Il materiale delle chiavi e gli attributi SPN vengono replicati con Active Directory. Dopo modifiche a account, password o SPN, diversi DC possono quindi usare temporaneamente stati diversi. Se il client usa un DC per TGS e l’amministratore un altro DC per il controllo, un errore appare intermittente. Un’evidenza affidabile indica KDC emittente, DC di destinazione della query di directory, KVNO, enctype del ticket e stato della replica. Ciò vale in particolare per rotazioni manuali di keytab e servizi distribuiti tra siti.

La selezione dell’enctype è l’intersezione tra offerta del client, policy KDC, chiavi dell’account di destinazione e supporto del servizio. Un software compatibile con AES non è sufficiente se l’account non possiede le chiavi corrispondenti o se msDS-SupportedEncryptionTypes e la policy di dominio le escludono. RFC 8429 classifica RC4 e 3DES per Kerberos come obsoleti; Microsoft documenta l’inventario mediante gli eventi di sicurezza 4768 e 4769. Una migrazione inizia con misurazione e generazione delle chiavi, non con la disattivazione globale di un bit (RFC 8429, RFC 8009, Microsoft: Detect and remediate RC4 usage).

Per i servizi Windows, i Group Managed Service Accounts, gMSA, riducono la gestione manuale di password e SPN. Non sostituiscono però la verifica dell’identità sotto cui il processo è effettivamente in esecuzione, degli host autorizzati a leggere la managed password e degli SPN registrati sull’account. Per appliance o servizi Unix è spesso ancora necessaria una keytab; la sua rotazione deve essere sincronizzata con l’account AD (Microsoft: Service Accounts).

All’interno di un dominio AD questo percorso è diretto. Per l’accesso oltre confini di realm o dominio si aggiungono ticket cross-realm ed eventualmente più stazioni intermedie.

Trust e percorsi cross-realm

Un trust tra realm non fonde i database dei principal. L’autenticazione cross-realm usa TGT per krbtgt/TARGET@SOURCE ed eventualmente più realm intermedi. Il client segue un percorso di ticket fino a raggiungere il realm del servizio di destinazione. RFC 6806 aggiunge referral e canonicalizzazione dei nomi, come usati in particolare dagli ambienti AD. Il percorso visibile nella cache è quindi più significativo dell’affermazione generica «il trust è verde» (RFC 4120, sezioni 1.1 e 3.3.3, RFC 6806).

Direzione del trust, transitività, Selective Authentication, filtraggio SID, Name Suffix Routing ed enctype disponibili limitano ciò che un TGT cross-realm consente in pratica. Gli SPN devono essere individuabili e univoci nella foresta corretta. Un riscontro locale con setspn -Q non dimostra l’univocità tra foreste; setspn dispone a questo scopo di opzioni forest e domain. La diagnosi documenta ogni referral TGT, non solo l’ultimo errore del service ticket (Microsoft: Windows Authentication Concepts, Microsoft: setspn).

Un ticket verso il frontend non autorizza automaticamente quest’ultimo a contattare un backend a nome dell’utente. Qui inizia esattamente il problema del double hop.

Delega e double hop

Nel normale scambio AP, un frontend non riceve una chiave utente liberamente utilizzabile. Se deve accedere a un backend a nome dell’utente, necessita di un modello di delega. La delegated TGT, ovvero unconstrained delegation, consegna al servizio un TGT riutilizzabile e ne amplia l’impatto ben oltre un singolo backend. Un frontend compromesso può usarlo per ottenere ticket verso altri servizi; questa forma è quindi una grande estensione della fiducia (RFC 4120, sezioni 2.5 e 2.6, MS-SFU: Protocol Overview).

Le estensioni Service-for-User di Microsoft suddividono il problema. Con S4U2self un servizio può ottenere un ticket verso sé stesso a nome di un utente, ad esempio dopo un’altra autenticazione frontend. Con S4U2proxy richiede, nel rispetto della policy KDC, un ticket verso un secondo servizio a nome di tale utente. La constrained delegation classica memorizza le destinazioni consentite sull’account frontend; la resource-based constrained delegation registra i chiamanti consentiti sull’account della risorsa. In entrambi i casi, SPN di destinazione, flag del ticket, impostazioni dell’account e percorso di trust fanno parte della decisione (MS-SFU: Overview, MS-SFU: Introduction).

La delega è autorizzazione alla propagazione dell’identità, non una mera opzione di compatibilità. L’amministratore inventaria principal frontend, SPN backend, classi di utenti consentite, Protocol Transition, confini di trust e l’ambito tecnico minimo di destinazione. Un primo hop riuscito non dimostra il secondo; viceversa, un test backend diretto nel contesto utente aggira il confine della delega e può fornire un falso positivo.

Modello operativo, monitoraggio e recovery

Dopo flusso dei ticket e delega sorge la questione operativa: quale componente Kerberos deve essere disponibile, quale evidenza ne dimostra lo stato e cosa può essere ripristinato in caso di emergenza? La tabella associa queste domande ai ruoli coinvolti.

Le cache dei ticket sono stato operativo. Un processo utente, account di servizio, container o sessione di accesso Windows può vedere una cache diversa da quella della shell amministrativa interattiva. Eliminare e richiedere nuovamente un ticket è un test mirato, ma non ripara la causa sottostante relativa a SPN, chiave o replica. Prima del purge vengono acquisiti principal, SPN di destinazione, KDC, KVNO, enctype, flag e campi temporali; altrimenti scompare la migliore prova dell’errore.

Windows registra le richieste TGT con 4768, i service ticket con 4769, gli errori di pre-autenticazione con 4771 e altri errori AS con 4772, se sono attive le opportune Advanced Audit Policies. Il volume è elevato sui KDC. Il monitoraggio richiede pertanto aggregazione per Result Code, client, servizio di destinazione, DC ed enctype, nonché baseline, anziché trattare ogni TGS Request riuscita come un allarme (Microsoft: Advanced Audit Policy Configuration).

Il recovery dipende dall’implementazione KDC. In AD DS, i dati KDC e krbtgt fanno parte del modello di System State e Forest Recovery; un file di database arbitrario o un’esportazione LDIF non costituiscono un backup Kerberos valido. Gli operatori di realm MIT autonomi devono salvaguardare insieme database KDC, materiale stash/master key, configurazione, ACL e replica. Le keytab di servizio vanno inventariate inoltre e, dopo un restore, verificate per coerenza di KVNO e chiavi (Microsoft: Back up the System State data, MIT Kerberos: Backups of secure hosts).

Per la risoluzione dei problemi, il percorso viene verificato a ritroso: nome di destinazione e SPN, service ticket presente, risposta TGS, TGT, individuazione del realm, DNS e orario.

Strumenti di diagnosi

La diagnosi inizia dalla stessa zona di rete, con lo stesso nome di destinazione, realm, contesto utente o di servizio e la stessa sessione di accesso dell’applicazione. I dati di test usano nomi riservati. Gli output di ticket e keytab possono esporre principal e infrastruttura; il materiale delle chiavi non deve mai finire in ticket, chat o argomenti di processo.

Individuare KDC e servizio password tramite DNS

Resolve-DnsName e dig mostrano priorità, peso, porta e target. Successivamente devono essere verificati la risoluzione A/AAAA e la raggiungibilità di ogni target restituito. RFC 4120 definisce la discovery DNS SRV, ma consente una configurazione locale del realm; un test SRV vuoto prova pertanto un errore solo se il client concreto usa la DNS discovery (RFC 4120, sezione 7.2.3, RFC 2782).

Confrontare orario e raggiungibilità TCP

w32tm e timedatectl mostrano fonte e stato di sincronizzazione; chronyc aggiunge dati di offset e tracking per Chrony. Test-NetConnection oppure nc dimostrano soltanto TCP 88. UDP, protocollo KDC, realm e pre-autenticazione richiedono un vero test AS/TGS.

Richiedere e visualizzare ticket in modo mirato

Windows-klist opera nel contesto della sessione di accesso selezionata. In MIT Kerberos, kdestroy elimina, kinit e kvno ottengono, mentre klist visualizza le credenziali. KRB5_TRACE rende visibili selezione KDC e percorso del protocollo. Prima di purge o kdestroy occorre documentare un ticket di errore esistente.

Verificare reciprocamente SPN e chiave del servizio

setspn mostra l’account di destinazione AD e cerca duplicati nell’intera foresta con -X -F. Get-ADUser legge SPN ed enctype dichiarati; un valore mancante ha una semantica di fallback specifica del prodotto e non deve essere interpretato genericamente come «nessun AES». MIT-klist mostra principal, KVNO ed enctype della keytab; kvno -k richiede un ticket e lo convalida rispetto alla keytab indicata.

Assegnare gli errori a una fase del protocollo

I codici di errore sono standardizzati in RFC 4120; Windows aggiunge contesto di stato e audit. L’automazione dovrebbe mantenere codice numerico, fase, KDC, client principal e principal di destinazione. Il testo libero da solo non è né stabile né univoco. Per l’analisi dei pacchetti, Wireshark può filtrare per kerberos; le parti cifrate dei ticket restano intenzionalmente illeggibili senza chiavi appropriate (RFC 4120, sezione 7.5.9, Microsoft: Kerberos troubleshooting guidance).

Storia tecnica

Kerberos nacque nei primi anni Ottanta nell’ambito del MIT Project Athena. Il protocollo si basa concettualmente sui lavori di trusted third party di Needham e Schroeder nonché di Denning e Sacco. Le versioni da 1 a 4 furono sviluppate nell’ambiente Athena; la versione 4 fu la prima ampiamente utilizzata. Il nome rimanda a Cerbero, il guardiano dalle molte teste della mitologia greca, e rappresenta il ruolo centrale di fiducia del KDC (RFC 4120, sezione 1, MIT Kerberos Consortium: Documentation).

Kerberos V5 eliminò le limitazioni della versione 4 in termini di naming, lifetime dei ticket, crittografia, cross-realm ed estendibilità. RFC 1510 standardizzò V5 nel 1993. RFC 4120 sostituì questa specifica nel 2005 con chiarimenti e una descrizione ASN.1 completa. La famiglia di protocolli fu poi ampliata modularmente, tra l’altro con PKINIT, Pre-Authentication Framework e FAST, GSS-API, referral e nuovi profili AES (RFC 1510, RFC 4120, RFC 4556, RFC 6113).

Microsoft rese Kerberos V5 il protocollo centrale di autenticazione del dominio con Windows 2000 e lo collegò a principal AD, SPN, PAC, SSPI, trust referral ed estensioni di delega. Parallelamente, MIT Kerberos, Heimdal e altre implementazioni sono rimasti interoperabili tramite protocolli IETF e GSS-API. La crittografia si evolse da DES e successivamente RC4 a profili AES; RFC 8429 avviò nel 2018 la dismissione di 3DES e RC4. La storia tecnica spiega perché dispositivi legacy, vecchi account di servizio e trust key rendano tuttora visibili limiti di enctype, senza fissare nell’articolo uno stato effimero delle versioni di prodotto (MS-KILE, RFC 3962, RFC 8009, RFC 8429).

Fonti

• 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) – architettura, messaggi, ticket, flag, codici di errore, trasporto e modello di sicurezza.
• RFC 3961, sezione 3
• RFC 4121 – Kerberos V5 GSS-API Mechanism – contesto GSS, token, integrità e riservatezza.
• MIT Kerberos: Mapping hostnames onto realms
• MIT Kerberos – Keytabs – contenuto della keytab, KVNO, enctype e chiave.
• Microsoft – Service principal names – univocità SPN e associazione ad account di servizio.
• Microsoft – setspn – query SPN, registrazione e ricerca dei duplicati.
• Microsoft – ktpass – interoperabilità AD/keytab.
• MIT Kerberos – Application servers – protezione della keytab, rotazione, orario e DNS.
• RFC 4556 – PKINIT – pre-autenticazione a chiave pubblica.
• RFC 6113 – Generalized Framework for Kerberos Pre-Authentication – framework pre-auth e FAST.
• RFC 8429 – Deprecate 3DES and RC4 in Kerberos – IETF Best Current Practice per enctype obsoleti.
• Microsoft – Detect and remediate RC4 usage – inventario enctype, chiavi degli account ed eventi.
• Microsoft – Kerberos authentication troubleshooting guidance – codici di errore Windows, orario, SPN e double hop.
• Microsoft – Windows Time Service – servizio orario e dipendenza Kerberos.
• Microsoft – Kerberos KDC registry and protocol settings – dimensione UDP, fallback TCP e diagnosi KDC.
• RFC 4178 – SPNEGO – negoziazione di meccanismi GSS.
• Microsoft – Kerberos authentication overview – architettura Windows, KDC, SSPI e autenticazione reciproca.
• RFC 4752 – SASL GSS-API Mechanism – integrazione in LDAP, IMAP, SMTP e altri protocolli SASL.
• MS-KILE – Kerberos V5 Synopsis – scambi AS, TGS e AP in Windows.
• MS-PAC – Privilege Attribute Certificate – gruppi, SID, profili, policy e firme.
• MS-KILE – PAC Generation – generazione di PAC Authorization Data.
• RFC 8009 – AES with HMAC-SHA2 for Kerberos 5 – enctype AES-SHA2.
• Microsoft – Service Accounts – gMSA, gestione password e SPN.
• RFC 6806 – Kerberos Principal Name Canonicalization and Cross-Realm Referrals – referral e canonicalizzazione dei nomi.
• Microsoft – Windows Authentication Concepts – trust, Protocol Transition e constrained delegation.
• MS-SFU – Protocol Overview – flussi di delega e rischio di TGT inoltrati.
• MS-SFU – Service for User Overview – S4U2self e S4U2proxy.
• MS-SFU – Introduction – Protocol Transition e constrained delegation.
• Microsoft – Advanced Audit Policy Configuration – eventi 4768, 4769, 4771 e 4772.
• Microsoft – Back up the System State data – backup AD DS/KDC.
• MIT Kerberos – kdb5_util – database KDC e backup in MIT Kerberos.
• Microsoft Learn – Resolve-DnsName – query DNS SRV in Windows.
• BIND 9 – dig manual – query DNS SRV nei sistemi Unix.
• RFC 2782 – A DNS RR for specifying the location of services – priorità SRV, peso, porta e target.
• Microsoft – w32tm – sorgente oraria Windows e diagnosi dell’offset.
• Linux man-pages – timedatectl(1) – stato della sincronizzazione oraria in Linux.
• Chrony – chronyc – diagnosi di offset, sorgente e tracking.
• Microsoft Learn – Test-NetConnection – diagnosi della connettività TCP in Windows.
• OpenBSD – nc(1) – test della porta TCP nei sistemi Unix.
• Microsoft – klist – cache ticket Windows e test dei service ticket.
• MIT Kerberos – kdestroy – eliminazione della credential cache.
• MIT Kerberos – kinit – ottenimento TGT e opzioni pre-auth.
• MIT Kerberos – kvno – service ticket e convalida keytab.
• MIT Kerberos – klist – visualizzazione di credential cache e keytab.
• MIT Kerberos – kerberos environment – KRB5_TRACE e variabili di cache/keytab.
• Microsoft Learn – Get-ADUser – attributi SPN ed enctype di un account di servizio.
• Wireshark – Kerberos display filter reference – campi del protocollo e filtri di visualizzazione.
• MIT Kerberos Consortium – Documentation – origine nel Project Athena e storia delle versioni.
• RFC 1510 – The Kerberos Network Authentication Service (V5) – specifica storica di base V5 del 1993.
• MS-KILE – Kerberos Protocol Extensions – Kerberos Active Directory ed estensioni Microsoft.
• RFC 3962 – AES Encryption for Kerberos 5 – profili AES-SHA1.