Folosind Lightweight Directory Access Protocol (LDAP) când căutați în directorul Active Directory informațiile necesare pentru descărcare și conectare.
Publicul țintă
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet
Adăugați următoarea cheie:
Nume cheie: IPAutoconfigurationEnabled
Tip cheie: REG_DWORD
Valoarea din notația hexazecimală este: 0 (valoarea 0 dezactivează suportul APIPA pentru acest adaptor).
Notă. În cazul în care nici o cheie IPAutoconfigurationEnabled nu este prezentă, se presupune implicit că aceasta este prezentă și are o valoare de 1, care corespunde cu starea activată a instrumentului APIPA.
Pentru mai multe informații, consultați următoarele:
Documentele RFC 1035, RFC 1036.
Versiunea Kerberos 5 este un protocol de autentificare. Permite calculatoarelor să efectueze autentificarea reciprocă. Cu alte cuvinte, permite calculatoarelor să se identifice reciproc. Este, de asemenea, baza tuturor sistemelor de securitate. Până când serverul este pe deplin încrezător că sunteți ceea ce trădați, cum nu poate oferi un acces sigur la resursele sale? Odată ce serverul vă identifică, acesta va putea determina dacă aveți autoritatea corespunzătoare pentru a accesa resursele sale.
Există șase mesaje primare Kerberos. Aceste șase mesaje sunt de fapt trei tipuri de acțiuni, fiecare dintre acestea conținând o solicitare a clientului și un răspuns la Centrul de distribuție cheie (KDC). Primul pas este să introduceți parola pentru client. Clientul Kerberos stația de lucru trimite o solicitare "AS" la serviciul de autentificare (serviciul de autentificare) al centrului KDC, solicitând biletul de autentificare ca răspuns, pentru a confirma că utilizatorii sunt aceia despre care pretind că sunt. Serviciul de autentificare verifică acreditările utilizatorilor și trimite înapoi Ticket Granting Ticket (TGT).
Al doilea pas este acela că clientul solicită accesul la serviciu sau resursă prin trimiterea unei cereri TGS către Serviciul de acordare a biletelor (TGS) al KDC. Serviciul TGS returnează clientului un bilet individual, pe care îl poate utiliza pentru a accesa serviciul solicitat pe orice server pe care îl operează.
Al treilea pas este că clientul Kerberos prezintă serverul cu un bilet pentru accesarea serviciului și solicită permisiunea de a accesa serviciul sau resursa de care are nevoie. Aceste mesaje se numesc "AP". În implementarea ID-urilor de securitate Microsoft (SIDs) sunt cuprinse în câmpul PAC, care face parte din biletul trimis serverului. Această a treia acțiune nu necesită un răspuns de la server decât dacă clientul a solicitat autentificarea reciprocă. Dacă clientul cere autentificarea reciprocă, serverul returnează clientului un mesaj care conține o marcă de timp a autentificării. În cazul unei înregistrări tipice a domeniului, toate aceste trei acțiuni apar înainte ca utilizatorul să poată accesa stația de lucru.
Lucrul la protocolul LDAP
Modelul general adoptat în LDAP presupune că toate operațiile client asociate protocolului sunt efectuate pe server. Clientul trimite o solicitare serverului, care indică operația pe care ar trebui să o efectueze serverul. Din acest moment, întreaga responsabilitate pentru efectuarea operațiunilor necesare în director este plasată pe server. După finalizarea operațiilor necesare, serverul returnează rezultatul operației sau un mesaj de eroare către client.
Modelul de informații LDAP se bazează pe o înregistrare care conține informații despre un obiect (de exemplu o persoană). Înregistrările constau din atribute care au una sau mai multe valori. Fiecare atribut are o sintaxă de ortografie specifică care definește valorile valide pentru atribut și modul în care aceste valori sunt utilizate la efectuarea operațiilor din director. Atributele pot fi: valorile șirului IA5 (ASCII), linkurile URL și cheile publice.
Caracteristici protocol LDAP
Extensiile suplimentare pot fi adăugate la protocol pentru a susține operațiile noi, iar instrumentele de gestionare pot fi utilizate pentru a extinde capabilitățile operațiilor existente.
RootDSE este vârful spațiului de nume logic și, în plus, partea de sus a arborelui prin care caută LDAP. Atributele rootDSE definesc atât partițiile de director (regiuni de domeniu, schemă și partiție de directoare) care sunt specifice unui singur controler de domeniu și rădăcină a arborelui de director rădăcină de domenii.
RootDSE publică informații despre serverul LDAP, inclusiv informații despre ce versiune de LDAP suportă, mecanisme SASL suportate și mecanisme de gestionare, la fel ca numele distins al înregistrării subscheme.
Clienții sunt conectați la rootDSE, la începutul lucrului pe LDAP.
LDAP peste TCP
Utilizarea LDAP la pornire și conectare
Pentru mai multe informații, consultați următoarele:
Securitatea protocolului SMB sa dezvoltat în paralel cu dezvoltarea acelor platforme care au folosit acest protocol. Modelul de bază al protocolului SMB definește două niveluri de securitate:
Nivelul resurselor partajate. În acest caz, protecția este efectuată la nivelul resurselor partajate ale serverului. O parolă este necesară pentru a accesa fiecare resursă partajată. În acest caz, numai clientul căruia îi este cunoscut va putea accesa toate fișierele disponibile pentru această resursă partajată. Acest model de securitate a fost primul folosit în protocolul SMB și a fost singurul model de securitate disponibil în protocoalele Core și CorePlus. În Windows pentru grupuri de lucru (Windows for Workgroups), vserver.exe a folosit acest nivel de securitate în mod implicit, a fost de asemenea utilizat de Windows 95.
Nivel personalizat. În acest caz, protecția este aplicată separat pentru fiecare fișier din fiecare acțiune și se bazează pe drepturile de acces ale utilizatorilor. Fiecare utilizator (client) trebuie să se conecteze la server sub contul său și să treacă autentificarea. După terminarea autentificării, clientul primește un ID de utilizator corespunzător, pe care trebuie să îl prezinte pentru a avea acces la resursele serverului. Acest model de securitate a fost implementat pentru prima dată în protocolul LAN Manager 1.0.
Mesajele de stabilire a conexiunii constau din comenzi care încep și termină conexiunea sistemului de redirecționare cu partajarea pe server.
Utilizarea protocolului SMB în timpul încărcării și conectării
Pentru mai multe informații, vă rugăm să contactați:
Apel la distanță la procedură la MSRPC
Fiind cel mai simplu exemplu al RPC-ului, puteți aduce o situație în care un computer solicită unui alt computer posibilitatea utilizării puterii sale de calcul. Protocolul RPC permite unui proces să solicite un alt proces care rulează pe un alt computer din rețea, despre posibilitatea executării instrucțiunilor primului proces.
În procesul RPC, sunt implicate următoarele:
Aplicație server. Urmați instrucțiunile.
RPC-urile sunt identificate în mod unic prin numărul de interfață (UUID), numărul de operațiuni (opnum) și numărul versiunii. Numărul interfeței definește grupul de proceduri la distanță asociate. Un exemplu de interfață poate fi serviciul de conectare în rețea, în care UUID are valoarea 12345678-1234-ABCD-EF00-01234567CFFB.
Exemplu de apel RPC:
MSRPC: c / o Legătură RPC: UUID 12345678-1234-ABCD-EF00-01234567CFFB apel 0x1
Assoc grp 0x0 xmit 0x16D0 recv 0x16D0
MSRPC: Versiunea = 5 (0x5)
MSRPC: Versiune (Minor) = 0 (0x0)
MSRPC: Tip pachet = Legare
+ MSRPC: Steaguri 1 = 3 (0x3)
MSRPC: Reprezentarea datelor ambalate
MSRPC: Lungimea fragmentului = 72 (0x48)
MSRPC: Lungimea de autentificare = 0 (0x0)
MSRPC: Identificator apel = 1 (0x1)
MSRPC: Max Trans Frag Size = 5840 (0x16D0)
MSRPC: Max Recv Frag Size = 5840 (0x16D0)
MSRPC: identificatorul grupului Assoc = 0 (0x0)
+ MSRPC: Lista de prezentare a prezentărilor
RPC nu depinde de protocoalele de transport la un nivel scăzut. Microsoft RPC (MSRPC) poate utiliza mai multe protocoale de transport diferite, cum ar fi TCP / IP, IPX / SPX sau NetBEUI.
Cele mai multe interfețe RPC utilizează porturi dinamice pentru comunicații în rețea. În acest caz, devine necesar să se utilizeze o interfață specifică, numită Mapper End Point. Această interfață întotdeauna ascultă pe portul 135 pentru conexiunile TCP / IP și are numărul UUID E1AF8308-5D1F-11C9-91A4- 08002B14A0FA.
Înainte ca clientul să poată invoca proceduri, trebuie să se lege de interfață. În cazul în care a fost posibilă stabilirea unei legări, se poate trimite o solicitare către Mapperul End Point, în care va fi specificat UUID-ul interfeței necesare. Comparatorul de punct final returnează numărul de port pe care clientul îl poate utiliza pentru conectare.
Următorul tabel prezintă secvența de pachete schimbate între părțile implicate în proces:
c / o Răspuns RPC: apel 0x1
contextul 0x0 indiciu 0x80 anulează 0x0
De asemenea, puteți încapsula pachetele MSRPC în SMB. În acest caz, clientul și serverul pentru schimbul de date utilizează un descriptor al fișierului deschis anterior.
Pentru mai multe informații, consultați următoarele:
Secțiunea "Traficul de rețea generat de client în Active Directory" din cartea Active Directory Enterprise Services: Traficul de rețea al clientului Active Directory ("Note de la Active Directory Services Enterprise Building Enterprise)
Pentru sincronizare, se utilizează următoarea ierarhie a sistemelor din domeniu:
Toate desktop-urile client utilizează propriul controlor de domeniu ca sursă de timp.
Documentele RFC: 1769, 2030.
Apoi, protocolul de autentificare Kerberos va fi discutat mai detaliat și va fi luată în considerare utilizarea acestuia în timpul încărcării și conectării. Protocolul NTLM utilizat la pornire și conectare a fost același ca în Windows NT 4.0. Este descris în detaliu în organizația Active Directory Enterprise Services: Note din agenda seriei Field Building Active Directory Services.
Pentru mai multe informații, consultați următorul document: