server director LDAP ca autentificarea sursă - integrarea cu anunțuri

Este greu de imaginat o rețea modernă, în care ar exista stații de lucru și servere bazate pe Microsoft Windows. UNIX și Windows coexistența într-un mediu de rețea eterogenă determină caracterul său, exprimat inclusiv metode de incompatibilitate de acces la serviciile oferite de către rețeaua locală. Problema cea mai tipică în astfel de rețele este prezența a cel puțin două baze de date la nivel mondial pentru autentificarea utilizatorilor pentru accesul la resurse. În sistemele de operare moderne ale familiei Windows este serverul standard pentru industrie este Active Directory, pentru sistemele bazate pe UNIX, din păcate, o astfel de abordare uniformă nu există, dar în cele mai multe configurații sunt de asemenea folosite LDAP-servere diferite de furnizori. Este evident că prezența a două (sau mai multe) de stocare independentă a datelor de autentificare devine un obstacol atunci când aveți nevoie pentru a avea acces la resursele de servere bazate pe UNIX, cu mașini care rulează Windows, și vice-versa.

Există cel puțin două abordări eficiente pentru rezolvarea acestei probleme

1. software-ul Samba pe UNIX accentuat problemele de interacțiune și a sistemelor bazate pe Windows (de convergență din partea sistemelor bazate pe UNIX). Această metodă permite utilizatorilor de Windows să fie autentificat de un afișaj UNIX respectiv. Conturile de Windows pe intervalul specificat de utilizatori ID-uri UNIX;

2. Serviciile Microsoft pentru Unix (SFU), vă permite să adăugați atribute suplimentare conturi active de utilizator Directory, care sunt tipice pentru sistemele bazate pe UNIX și, astfel, să adapteze AD pentru baza de date de autentificare UNIX.

A doua metodă pe configurații reale folosind relativ rare din cauza necesității de modificare substanțială a AD, care necesită privilegii administrative absolute, iar lipsa de fiabilitate relativă: Microsoft Corporation pot modifica specificațiile AD și Sful destul de des că, în unele situații, poate crea dificultăți nu numai în trecerea la noua versiune a sistemului de operare pentru servere Windows, dar chiar și la actualizarea sa elementar.

Aici vom descrie doar prima metodă, în contextul utilizării LDAP-director ca un depozit de informații despre contul de utilizator a primit de la Active Directory.

  1. Zonă DNS căutare controler de domeniu-SRV inscriptibil și Kerberos Distribution Center pentru a obține informații cu privire la rolul și structura funcțională a rețelei pentru Windows;
  2. cereri de controler RPC-domeniu;
  3. Citirea directă a AD prin LDAP-protocol.

Pentru un anumit REALM'a (domeniul analogic) Winbind preia informații despre conturile existente și utilizarea IDMap face afișarea lor în modulul de sprijin UNIX. Aceasta folosește mecanisme standard UNIX pentru a lucra cu obiect de nivel de sistem: NSS (Nume de comutare spațiu) și PAM (conectabile autentificare Module), descris în articolul „serverul director LDAP ca sursă de autentificare - configurare NSS și PAM“. Pentru o astfel de afișare este necesar să se definească o metodă de stabilire a unei corespondențe între identificatorii de obiecte (utilizatori, grupuri) AD și identificatori unici UNIX (uidNumber, gidNumber respectiv). In cazul ligamentelor Winbind + IDMap în funcție de metoda de potrivire alegere poate fi fie semnificativă (adică predictive, lipsite de ambiguitate) și aleatoriu (neprediktivnym). Metodele neechivoce încercați să utilizați unitatea funcție hash pentru a primi în mod direct din câmpul RID (ID relativ) atribuie contul de utilizator objectSID în valoare AD uidNumber / gidNumber resp. obiect echivalent UNIX. Sursa problemei aici este diferența fundamentală dintre metodele de reprezentare structurală a conturilor de pe UNIX și Windows. După cum se știe, obiectele din rețelele Windows sunt grupate în mod logic într-o structură ierarhică pe baza afilierii domeniului, în UNIX, ca standard este așa-numita plat depozitare sistem de informații despre obiectele din structurile de masă plane, la un nivel mai înalt, combinate într-o anumită aparență de baze de date relative, în care primar tastele sunt valorile UID și GID obiectelor. O consecință directă a celor de mai sus este că, într-un meci nume de utilizator pentru UNIX - o anomalie, și în Windows - ierarhia constând dintr-o pluralitate de încredere reciproc domenii, această situație este absolut normală. Astfel, în cazul în care există în diferite domenii, utilizatorii cu același nume, în UNIX, acestea ar trebui să fie afișate ca utilizatori diferiți, pentru care se adaugă partea de domeniu pentru numele utilizatorului ca o componentă opțională, separate printr-un așa-numit separator - „separator“.

parte domeniu Opționalitatea datorită faptului că primul domeniu în rețea poate fi doar una, când de fapt avem aceeași structură planară ca la UNIX, și în al doilea rând - în nivelul acord poate presupune că numele de utilizator sunt unice în întreaga pădure . Și, de fapt, și în ambele cazuri poate conduce afișarea numelor, fără partea de domeniu.

Voi încerca să explice scopul comprehensibil a opțiunilor reduse:

idmap backend - specifică tipul de IDMap backend (Exemplu: ldap) și parametrii trecut la backend (URI-cale către serverul director, de exemplu, LDAP: //127.0.0.1 sau LDAPS: //ds.mydomain.com: 1636)
ldap sufix - LDAP arbore de sufixe care identifică baza de date;
sufixul ldap idmap - un offset de la sufixul la rădăcina afișajului arborelui ID objectSID / uidNumber - Strict vorbind, numele opțiunii înșelătoare, pentru că în ciuda similitudinii semantice sufixul ldap, de fapt, acest parametru specifică baza relativă pentru căutarea corespondențelor (mapările), dar Ea nu are nici o legătură cu noțiunea de copac director sufixul (rădăcină);
admin ldap dn - DN utilizator, în numele căruia va accesa Marea Britanie. Acest utilizator trebuie să aibă dreptul de a crea noi intrări în ramură țintă, calea spre care este dat în comun de parametrii «ldap sufix» și «ldap idmap sufix»;
Grupuri ENUM winbind. Utilizatorii ENUM winbind - winbind indică necesitatea de a recursiv toate părțile accesibile ale pădurii de domeniu, pentru a forma o listă completă de obiecte care se încadrează în „zona de interes» winbind (utilizatori, grupuri, rețele de stații de lucru). Necesitatea unei astfel de transfer apare rar - de exemplu, atunci când se utilizează un getent utilitar
uid winbind. winbind GID - game de identificatori numerici și grupuri de utilizatori, pentru care, prin transformarea tabelul afișează corespondență, respectiv, grupurile și utilizatorii din Active Directory.

Astfel, pentru IDMap rezervate pool identificatorii numerici, în care ordinea secvenței de afișare și obiecte de control al accesului depinde de setările IDMap;

shell șablon. șablon homedir - coajă de utilizator de la AD în mod implicit. După instalarea Microsoft Services pentru Unix este posibil să se adauge un UNIX-specific atribute ale grupurilor și utilizatorilor Windows-domeniu, astfel încât această opțiune nu se aplică tuturor utilizatorilor de domeniu, ci doar celor care, resp. atribute care urmează să fie determinate. În mod evident, în cazul în care Sful în orice controler de domeniu AD nu este utilizat sau valorile atributelor specifice UNIX instalate nicăieri valori coajă șablon și șablonul homedir devenit la nivel mondial;

smbpasswd -w «parola»

Rețineți că, deși numele utilizatorului și nu este dat Echipa smbpasswd, parola TDB-fișier în continuare va fi introdus împreună cu distinsul Administratorul numele LDAP IDMap-sucursale, astfel încât, dacă schimbați ldap admin Dn, trebuie să executați această comandă, chiar dacă parola noul DN este aceeași cu parola veche. De asemenea, există două puncte importante să ia în considerare atunci când configurați afișare pentru Windows -> UNIX în spațiul unei anumite ramuri a Regatului Unit:

1. În lipsa capacității de a preciza cu exactitate cadru, adâncimea și filtrul de utilizatorii care caută în AD (în opinia mea, aceasta este o winbind semnificativă omisiune), numărul de intrări, care sunt create afișate în LDAP-director, poate fi foarte important. Ca o consecință a topologii de domeniu destul de complexe, sunt încurajate să stabilească IDMap-bază pe cont propriu sufix independent, în caz contrar veți obține o scădere bruscă a performanței în interogări recursive SK cu domeniu de aplicare = sub-

2. Atunci când permisiunile asignarea cont ldap admin Dn, ar trebui să li se permită să modifice obekta- „rădăcină“ ramură a ecranului, deoarece este modificat Winbind'om: add objectClass = sambaUnixIdPool, uidNumber și atribute gidNumber. În atributele menționate anterior IDMap stochează numerele și uidNumber gidNumber, utilizate pentru stabilirea noului utilizator / grup - ia valoarea acestor atribute, atribuite obiectului nou creat, apoi o nouă valoare incrementat este scris peste citire vechi. În cazul în care tabelul IDMap separat de ramura principală a directorului și este stocat într-o bază de date separată, care este de preferat în termeni de performanță (a se vedea mai sus), cel mai simplu mod este de a utiliza un cont de administrator de baze de date. Să ne amintim că pentru OpenLDAP acest parametru este setat ca secțiuni de fișiere de configurare rootdn slapd.conf o valoare corespunzătoare, cât și pentru cea mai mare parte din Marea Britanie, care se bazează pe codul Netscape, implicit este «cn = Director Managerul».

Amintiți-vă că, după efectuarea modificărilor necesare în fișierul smb.conf, trebuie să le aplice, reporniți server și smb winbind.

După finalizarea configurării Samba, comanda testparm a alerga pentru a verifica sintaxa corectitudinii smb.conf. Asigurându-vă că totul este în ordine, să încercăm să intre pe server pentru domeniu:

Aici SMBLINUX - numele mașinii, și My.Domain.Ru - domeniul de ea, în acest caz coincide cu numele DNS-domeniu.
În cazul în care aderarea la domeniul totul merge bine (pe care eu chiar te doresc, nu din auzite știe cum poate fi dificil). Dăm acum familiare namespace comutator de serviciu (NSS) cu privire la necesitatea de a recurge la WinBind pentru conturile de utilizator și grupuri din Active Directory. Pentru a face acest lucru, editați fișierul /etc/nsswitch.conf pentru a adăuga modulul winbind în secvența serviciilor solicitate de către NSS atunci când caută obiecte în bazele la nivel de sistem (namespace) passwd, de grup și umbră. De exemplu, în cazul în care interogările NSS deja procesate folosind fișierele bazei de date și LDAP, winbind este configurat cu linia rezultată în nsswitch.conf trebuie să apară după cum urmează:

GRUP DE LUCRU - numele grupului de lucru AD din același parametru de smb.conf;
WB_DELIMITER - separator între domeniul și o parte a numelui;
USERNAME - numele obiectului utilizator în AD.

      Articole legate de acest subiect: