Cavalerul tău negru ca Cerberus din Iad,
Din nou, puneți câinii săi credincioși ...
Toată lumea este viclean și agil, aici este drama,
Doar craniul de dinți nu este teribil!
În articolul precedent din această serie, am început să vă prezint capabilitățile protocolului de autentificare Kerberos. Știi că este un Kerberos, creatorii primelor versiuni ale acestui protocol, noua interfață caracteristici SSPI, precum și îmbunătățiri cheie Kerberos protocol de autentificare în comparație cu NTLM. Dar, cel mai probabil, după primul articol al acestei serii, cititorul poate fi aspecte suplimentare legate de protocolul de autentificare luate în considerare.
În acest articol, voi arăta că, de fapt, zgomotul dinților Cerberus nu este atât de teribil. Cu alte cuvinte, veți afla, sper, ceva nou despre Centrul de distribuție cheie (KDC), precum și despre serviciul de bilete. În plus, procesul de autentificare Kerberos va fi examinat.
Pentru ce este KDC?
Chiar și în primul articol al acestei serii, am menționat în treacăt că una dintre componentele principale ale protocolului de autentificare Kerberos efectuează Centrul Key Distribution (Key Distribution Center, KDC) - magazia centrală de date de utilizator pentru autentificarea utilizatorilor. Acum, vom examina mai îndeaproape această componentă de bază a programului Kerberos.
În cazul în care autentificarea se efectuează în conformitate cu modelul secret comun, astfel încât acest secret nu este cunoscut nimănui, hașul utilizatorului este folosit pentru criptarea pachetului. De îndată ce centrul de distribuție cheie primește un astfel de pachet, informațiile se decriptează utilizând un hash care a fost salvat în Active Directory Domain Services, iar atât utilizatorul, cât și serverul trebuie să partajeze acest secret. La rândul său, KDC, aflat pe un controler de domeniu, gestionează toate secretele comune ale utilizatorilor din organizație, care, așa cum este menționat mai sus, se găsesc în aceeași bază de date. Apropo, în terminologia Kerberos, limita definită de baza de date a utilizatorilor într-un KDC este denumită de obicei o sferă. În timp ce în Active Directory, această limită este denumită un domeniu.
KDC în sine funcționează ca un proces separat, bazat pe următoarele două servicii:
Serviciul de autentificare (AS). Acest serviciu eliberează un Ticket-Granting Ticket (TGT) pentru a vă conecta la serviciul Ticketing în propriul dvs. sau într-un domeniu de încredere. Identitatea TGT vă permite să primiți bilete pentru toate serviciile utilizate pentru a obține acces la resurse. La rândul său, înainte ca un utilizator să solicite un bilet la alt computer, trebuie să solicite serviciul de autentificare TGT pentru contul client. Apoi, serviciul de autentificare revine la serviciul de bilete TGT pentru computerul de domeniu țintă. Biletele TGT pot fi folosite înainte de expirarea termenului, însă prima dată când vă conectați la serviciul TGS, utilizatorul va trebui să furnizeze acreditările pentru a efectua autentificarea;
Serviciul de acordare a biletelor (TGS). Spre deosebire de serviciul de autentificare, acest serviciu emite bilete pentru conectarea la computerele din domeniu. Când clienții au nevoie să se conecteze la un computer, accesează serviciul TGS, oferă un TGT și apoi solicită un bilet către computerul țintă. Ca și în toate cazurile, biletele pot fi utilizate înainte de data expirării, dar când vă conectați pentru prima oară la TGS, va trebui să furnizați acreditările.
Ambele servicii sunt inițiate în cadrul procesului Autorității Locale de Securitate (LSA). Apropo, ambele computere client și orice aplicații nu ar trebui să aibă niciodată posibilitatea de a accesa direct baza de date a contului în sine. Pe lângă aceste două servicii, procesul LSA rulează și Agentul de sistem director (DSA), prin care trebuie să treacă toate interogările.
Fig. 1. Determinarea dimensiunii pragului biletului
În plus față de toate cele de mai sus în această secțiune, trebuie amintit că, dacă, din anumite motive, KDC-ul nu este disponibil, controlerul de domeniu care a fost localizat KDC, nu va mai fi un controler de domeniu, și cu acces la servicii de domeniu Active Directory vă pot exista probleme. Din acest motiv, orice controler de domeniu poate accepta cereri de autentificare și de bilete, având rolul centrului KDC.
Procesul de autentificare Kerberos
Anterior, am scurt vorbit despre procesul de autentificare Kerberos, și părea, după cum urmează: utilizatorul introduce datele de conectare pe o hashing parola client folosind subsistemul de securitate locală a LSA, atunci datele sunt transferate către furnizorul de suport de securitate, și după aceea mergeți la controlerul de domeniu.
Este mai mult decât evident că acest lucru nu se termină acolo. Deci, ce acțiuni sunt efectuate în timpul autentificării Kerberos:
În primul rând, furnizorul trimite SSP Key Distribution Center mesajul de autentificare, inclusiv numele de utilizator și domeniu, precum și cererea TGT cu o cheie secretă, care, după cum știți, este extras din parola utilizatorului. Apropo, o cheie secretă poate fi utilizată atât pentru autentificarea clientului, cât și pentru autentificarea serverului. Datorită faptului că biletul va fi trimis într-o formă pură, care este în mod necesar intruși expuse de tensionată parte a cererii este criptat;
Fig. 2. Setarea erorii maxime de sincronizare a ceasului
După ce autentificarea este finalizată cu succes, controlerul de domeniu transmite mesajul cu cheia de sesiune TGS și cu biletul TGT către computerul client, ceea ce va permite utilizatorului accesul la TGS. Cheia sesiunii este o cheie de criptare care este utilizată pentru a autentifica clientul și poate fi utilizată opțional pentru autentificarea serverului, în locul cheii secrete a clientului pentru interacțiunea cu KDC. Acum, dacă utilizatorul de-a lungul ciclului de viață TGT trebuie să furnizeze acreditările pentru o resursă sau o aplicație, clientul va furniza întotdeauna acest tichet TGT la serviciul TGS. În bilet, pe lângă toate informațiile necesare, se transferă și identificatorii de securitate ai utilizatorului și grupurile de securitate la care este inclus utilizatorul, numit Certificatul de atribut Privilege (PAC). Biletul TGT care este trimis utilizatorului în corpul KRB_AS_REP este criptat cu o cheie KDC, pe care utilizatorul nu o cunoaște și nu ar trebui să o cunoască. Adică, utilizatorul primește TGT în formă criptată și nu îl poate decripta.
Durata de viață a biletului de utilizator poate fi predefinită, din nou, utilizând Politica de grup. Pentru a face acest lucru, ar trebui să profitați de setarea politicii "Maximum User Lifetime" de la nodul Configurare computer, Politici, Setări Windows, Setări de securitate, Politici de cont, Kerberos. Aici puteți specifica intervalul maxim de timp în care se poate utiliza un bilet de avion. După expirarea valabilității biletului TGT, trebuie să reînnoiți biletul existent sau să solicitați un nou. Caseta de dialog proprietăți pentru setarea politicii curente poate fi văzută mai jos:
Fig. 3. Durata maximă de viață a biletului de utilizator
În acest moment, pachetul este returnat la computerul utilizatorului și trebuie să fie decriptat din nou. Cheia secretă a utilizatorului este responsabilă de procesul de decriptare a cheii de sesiune TGS de pe computerul client. Ca și în al doilea pas al acestui proces, în cazul în care clientul a fost capabil să decripteze cheia sesiunii și eticheta de timp a fost validă, clientul crede că KDC este valid și poate fi de încredere. Cheia sesiunii este stocată în memoria cache a calculatorului utilizatorului înainte de data expirării, iar această cheie va fi acum utilizată pentru conexiunile la centrul de distribuție cheie. Și din moment ce clientul nu mai are nevoie de o cheie privată - este pur și simplu eliminat din cache;
Utilizatorul a fost deja autentificat, adică se poate spune că una dintre cele mai importante etape a fost deja adoptată. Cu toate acestea, rămâne să se obțină acces la resursele de rețea, care a fost sarcina principală a întregii proceduri examinate. Atunci când permite accesul la serviciul TGS utilizează TGT obținut de către utilizator, accesul la alte resurse de rețea utilizatorul trebuie să fie în afara datoria TGS pentru a obține un bilet pentru a accesa serviciul. Prin urmare, clientul trimite biletul pentru a avea acces la cererea de serviciu la TGS, care include informații cum ar fi numele de utilizator și domeniu, SPN, TGT bilet, care a fost discutat mai sus, UPN, precum și un marcaj de timp, criptat cheia de sesiune în această etapă;
KDC din nou decriptează biletul TGT utilizând o cheie pe termen lung, extrage cheia de sesiune TGS și verifică marcajul de timp dacă cheia sesiunii este validă. Dacă toate datele extrase sunt valide, centrul de distribuție cheie efectuează o interogare LDAP pentru a găsi contul de utilizator și pentru a pregăti un bilet de acces la servicii. Ca și în cazul duratei de viață a biletului utilizatorului, folosind politica "Durata maximă de viață a biletului de serviciu". puteți stabili numărul maxim de minute în care biletul de sesiune primit poate fi utilizat pentru a accesa un anumit serviciu. Biletele pentru sesiuni sunt folosite numai pentru autentificarea pe conexiuni noi la servere. După autentificarea conexiunii, biletul expiră. Dacă specificați o valoare de 0 minute, durata de viață a biletului nu va expira niciodată. Dialogul de proprietăți al acestei setări de politică este prezentat în următoarea ilustrație:
Fig. 4. Durata maximă de funcționare a biletului de serviciu
Acum, computerul client cachează ambele părți ale biletului de sesiune în memoria sa. Pentru a acorda acces, computerul client furnizează serviciului de rețea un bilet de sesiune;
În cele din urmă, serviciul de rețea la care utilizatorul se conectează decodifică biletul de acces la serviciu utilizând cheia secretă, iar apoi ștampila de timp este decriptată, unde se poate găsi interogarea însăși. Dacă totul a fost rezolvat, serviciul de rețea începe să aibă încredere în KDC și determină dacă autentificarea reciprocă este necesară pentru client. Dacă este necesar, marcajul de timp din cerere este criptat și se trimite un răspuns la computerul client. După aceasta, clientul este din nou obligat să efectueze decriptarea amprentei de timp folosind cheia de sesiune. Dacă toate marcările de timp s-au convertit, există încredere generală;
Acesta este modul în care arată procesul de autentificare Kerberos, dar dacă doriți să aflați mai multe despre acest proces, inclusiv procesul de generare a mesajelor și organizarea mesageriei, vă recomandăm să vă familiarizați cu RFC1510.
Și, în sfârșit,
Aș dori să observ că în acest articol nu s-au evidențiat toate nuanțele posibile legate de centrul de distribuție cheie și de procesul de autentificare Kerberos, dar materialul prezentat vă va permite să obțineți cunoștințe generale legate de acesta. Articolul nu ia în considerare serviciul proxy KDC, procesul de criptare a biletelor, diversele mesaje specificate în bilete, autentificarea între domenii nu a fost luată în considerare.
Trimiteți-le prietenilor: