L'autenticazione AD utilizza due protocolli principali: Kerberos e NTLM
NTLM
Il processo di certificazione è il seguente:
- Il client genera localmente un hash NTLM, e il valore è il valore hash della password dell'utente.
- Il client invia il nome utente al server applicativo.
- Il server applicativo genera un valore casuale per il client, che di solito si chiama nonce o challenge.
- il client cripta il nonce con hash NTLM e lo invia al server applicativo.
- Dopo averlo ricevuto, il server applicativo lo invia al server AD insieme al nome utente e al nonce.
- AD genera un hash NTLM basato sulla password dell'utente, cripta il nonce e poi confronta il messaggio del client.
- Se i valori sono gli stessi, l'autenticazione viene superata, e se sono diversi, l'autenticazione fallisce.
Kerberos
Termini chiave:
- KDC: Centro di Distribuzione delle Chiavi, che fornisce due servizi: Servizio di Autenticazione (AS) e Servizio di Concessione dei Biglietti (TGS). Il dominio genera un account di dominio chiamato krbtgt per KDC, e TGT utilizza la password per la crittografia e la decrittografia. Quando un utente del dominio accede per la prima volta, vuole che l'AS si autentichi e, dopo il passaggio, l'AS richiede al TGS di fornire un ticket (TGT) all'utente del dominio.
- SPN: Nome del Principale del Servizio。 Oltre agli account utente, gli account AD hanno anche account di servizio. L'applicazione avrà anche un account di servizio associato, che faciliterà l'accesso alle risorse server, come Exchange, SQL, IIS, ecc. SPN è un servizio utilizzato per associare il servizio, abilitato dall'applicazione, all'account di servizio in AD.
Processo di certificazione:
1. Quando un utente di dominio effettua l'accesso, viene inviata una richiesta AS (AS_REQ) al DC, che contiene un timestamp criptato con l'hash della password e il nome utente dell'utente.
2. Dopo aver ricevuto la richiesta, il DC utilizza l'hash del nome utente e della password dell'utente per decriptarla. Il DC risponde a una risposta AS (AS_REP) al client, che include una chiave di sessione e un TGT (Ticket che concede il ticket). La chiave di sessione viene criptata con l'hash della password dell'utente. Il TGT contiene l'appartenenza al gruppo, il dominio, il timestamp, l'IP del client e la chiave della sessione. TGT è anch'esso criptato, criptato con la password dell'account di servizio KDC, e il client non può decriptarlo. (TGT è valido per 10 ore di default, e gli aggiornamenti successivi non richiedono all'utente di reinserire la password)
3. Quando un utente richiede una risorsa nel dominio, viene inviata una Richiesta di Servizio di Concessione di Ticket (TGS_REQ), che include nome utente, timestamp, TGT e SPN. Timestamp e nomi utente sono criptati con una chiave di sessione.
4. Dopo aver ricevuto la richiesta, il KDC determina prima se c'è uno SPN nella richiesta, poi decripta il TGT, estrae la chiave di sessione e il timestamp nel TGT, e utilizza la chiave di sessione nel TGT per decriptare il nome utente e il timestamp criptati. Esegui diversi controlli:
(1) Il timestamp decifrato da TGT deve essere valido. (Se si verifica un attacco di ripetizione, il timestamp non è valido.) ）
(2) Se il nome utente nel TGT è coerente con quello nella richiesta.
(3) Se l'indirizzo IP nel TGT corrisponde a quello della richiesta.
Il controllo risponderà al ServiceReply (TGS_REP) di concessione del ticket del client, che contiene l'accesso autorizzato SPN, la nuova chiave di sessione utilizzata per l'accesso tra client e SPN, e il nuovo ticket di servizio del Ticket di Servizio (inclusi la nuova chiave di sessione, nome utente e gruppo utente). Sia l'autorizzazione SPN sia la chiave di sessione che accede allo SPN sono criptate con la chiave di sessione in TGT. Il ticket di servizio è criptato con la password dell'account SPN corrispondente.
1. Dopo il processo sopra, l'utente ha ottenuto la chiave di sessione e il ticket di servizio relativi al servizio applicativo. L'utente invia una Richiesta di Applicazione (AP_REQ) al servizio applicativo, che contiene il nome utente e il timestamp, ed è criptata con una chiave di sessione.
2. Il servizio applicativo utilizza l'hash della password dell'account di servizio per decifrare il ticket di servizio ed estrarre l'utente, il gruppo utente e la chiave della sessione. Decripta il nome utente e il timestamp nel AP_REQ con la chiave di sessione decriptata. AP_REQ Se sì, la richiesta viene accettata e il servizio applicativo assegna permessi basati sulle informazioni del gruppo utenti nel ticket di servizio, e così l'utente può accedere al servizio richiesto.
Indirizzo originale:Il login del link ipertestuale è visibile.
|
Pubblicato su 22/08/2023 19:16:28
|
|
|
|
