LDAP::servere și clienți LDAP – Partea 5

UPDATE: am realizat astăzi că am scris același subiect de două ori, în două posturi diferite., Acesta ar trebui să fie considerat efortul combinat, dar poate citi un pic ca un blog Frankenstein. Originalul celuilalt rămâne aici:

această postare este partea 5 a noii serii LDAP am început să ajut oamenii să devină mai conștienți de ceea ce este LDAP și cum funcționează.

prima parte a fost postată aici:

Ce naiba este un LDAP oricum?

această postare se va concentra pe serverele și clienții LDAP.,în regnul animal, veți vedea adesea relații simbotice, cum ar fi presupusa relație dintre crocodili și pasărea plover, care mănâncă lucruri moarte din dinții crocodilului.

relația client / server LDAP este, de asemenea, simbiotică. Serverul are nevoie de client pentru a pune întrebări și clientul are nevoie de server pentru a alimenta informații.,dacă natura nu este lucrul tău, există întotdeauna relația simbiotică Spider-Man/Venom:

în cazul LDAP, un client va cere lucruri precum nume de utilizator, locații de director de acasă, membri de grup etc. Serverul ar fi responsabil pentru furnizarea acestor informații.

LDAP nu este diferit de alte protocoale, cum ar fi HTTP, NFS, etc. Există o relație client și server. Și la fel ca orice relație de succes, trebuie să existe cineva care să vorbească și cineva să asculte.

am un fiu de doi ani. Vorbește, dar cea mai mare parte este doar practică pentru el., El va spune lucruri de genul ” dada, bird truck.”Și voi spune” pasăre? Camion? Mișto!”Este cea mai mare parte o conversație unilaterală în cazul în care am ACK, în esență, SYNs lui. (Trebuie să ies mai mult)

uneori, este ” dada citește cartea.”Și mă supun.

conversațiile client / server LDAP nu sunt foarte diferite. Clientul este copilul meu de doi ani. Serverul LDAP sunt eu.

„LDAP, găsiți informații despre utilizator”

” informații despre utilizator? Mișto! Poftim!”

la baza sa, conversațiile LDAP nu sunt altceva decât TCP SYNs și ACK. Deci, atunci când configurați sau depanați, acestea trebuie tratate ca atare.,

În cazul în care lucrurile se încurcă este atunci când începe să ia în considerare ceea ce este nevoie pentru o relație client/server pentru a avea succes. Nu este o idee bună să lăsăm canalele de comunicare larg deschise pentru ca toată lumea să le vadă, așa că există câteva reguli pe care trebuie să le respectăm atunci când clienții doresc să vorbească cu serverele.

Configurare Client/Server

clienții LDAP pot fi orice software care rulează care poate interoga LDAP prin standardele RFC-2307. Windows, Linux, Sisteme de stocare sisteme de operare, etc pot acționa ca clienți., Unele sisteme de operare conțin funcționalitate LDAP încorporată (cum ar fi Windows) care nu necesită să instalați nimic special. Unele sisteme de stocare, cum ar fi datele grupate ONTAP de la NetApp, acceptă pe deplin LDAP care aderă la standardul RFC-2307. Pentru mai multe informații, consultați TR-4073: autentificare securizată unificată.

informații de bază despre rețea.

amintiți-vă, la baza sa, este o conversație simplă TCP.

• nume de server LDAP, URI sau adrese IP (este serverul în DNS? Există înregistrări SRV pentru LDAP?,)
• port LDAP (porturile implicite sunt 389 pentru LDAP, 636 pentru LDAP prin SSL, 3268 pentru Catalog Global; ați schimbat portul serverului?)
• poate clientul să vorbească cu serverul (rutare?)

înainte ca un client să poată iniția o conversație cu un server, acesta trebuie să fie configurat cu informații despre acel server. Configurația va urma elementele de bază ale modelului OSI, începând de la primele straturi ale stivei pentru a iniția o conversație TCP cu serverul.

clienții LDAP obișnuiți

clienții LDAP tind, de asemenea, să adere la aceleași standarde ca serverele. De ce?, Pentru că are sens. Clienții pot sta singuri dintr-un sistem de operare, dar unele sisteme de Operare integrează LDAP în configurația lor în mod implicit. Windows este un exemplu în acest sens din cauza modului în care integral LDAP este la Active Directory.

Alți clienți includ (dar cu siguranță nu se limitează la):

• SSSD
• OpenLDAP

să Sperăm că informațiile din acest post a ajutat clarifica orice confuzie pe LDAP clienți și servere.

unele servere LDAP vă vor permite chiar să faceți modificări la portul pe care îl ascultă pentru comunicarea LDAP., Acest lucru este pentru a ajuta la securizarea serverelor LDAP prin faptul că nu utilizează porturi bine cunoscute. Cu serverele LDAP comune, cum ar fi Active Directory, este dificil să utilizați porturi diferite de cele comune. La configurarea clienților, configurația serverului LDAP trebuie întotdeauna revizuită.după ce trecem de conexiunea TCP, ne petrecem timpul în stratul de aplicație al Modelului OSI.

Bind / informații de conectare.

Mai întâi trebuie să ne facem griji cu privire la autentificarea pe serverul LDAP. Acest lucru este, de asemenea, cunoscut sub numele de legare., Nivelul de autentificare va depinde de ceea ce serverul a fost setat pentru a permite. Cel mai mic nivel posibil de autentificare este „anonim”, dar niciun server LDAP modern nu permite în mod implicit legături anonime. În general, un cont numai în citire pe serverul LDAP este necesar pentru a se autentifica pe un server pentru a emite interogări LDAP.

informațiile necesare bind sunt incluse în configurația clientului. Pentru cea mai sigură configurație, este preferată utilizarea unui sistem de autentificare bazat pe tichete sau chei decât utilizarea parolelor.,

informații de căutare LDAP

după ce are loc o legare, interogările sunt efectuate. Natura interogărilor va depinde de configurația clientului. Ce schemă folosim? Ce informații avem nevoie? Am configurat clientul pentru a vă asigura că încercați LDAP pentru informații în orice moment (prin nsswitch.configurare conf)? I-am spus clientului de unde să înceapă să caute informații pe serverul LDAP furnizând DN-ul de bază?acest lucru îi spune clientului de unde să înceapă să caute informații în serverul LDAP.,Formatul pentru aceste informații este numele distinse (DNs), pe care le acopăr în partea 4. Puteți seta un DN de bază și apoi DNs specifice pentru utilizatori, grupuri, netgroups, etc. Puteți specifica chiar mai multe locații pentru a căuta. Ideea aici este de a filtra căutările noastre pentru a accelera lucrurile pentru clienți.

fapt distractiv: Apple auto-corectează DNs la DNS. Nu-i frumos, Apple. Nu-i frumos.

odată ce clientul LDAP are informațiile necesare, acesta ar trebui să se desprindă – nu vrem să rămânem conectați pe o perioadă nedeterminată. E un porc de resurse.

LDAP schema informații

i acoperă schemele în detaliu pe partea 3., Mulți clienți știu despre schemele implicite utilizate de LDAP, cum ar fi RFC-2307, RFC-2307bis etc. În cele mai multe cazuri, schemele de pe server nu se vor abate de la asta. Dar, în unele cazuri, cum ar fi prin intervenție manuală sau 3rd party instrumente, cum ar fi Dell Vintela (de asemenea, cunoscut sub numele de Centrify, Quest, etc), ar putea fi nevoie pentru a face ajustări. Acest lucru se poate face pe client. Acest lucru permite clientului să solicite informațiile corecte de la server, ceea ce permite apoi serverului să găsească informațiile și să răspundă clientului.,

opțiuni specifice clientului

mulți clienți oferă opțiuni specifice, cum ar fi cache de utilizatori/grupuri, acreditări, configurare Kerberos, etc. Acestea sunt, în general, opționale, dar ar trebui să fie analizate pe bază de furnizor per-client.

Exemplu de configurare client

următorul este un exemplu de ceea ce un cluster de Date ONTAP LDAP client ar arăta astfel:

Aceasta este ceea ce clientul meu de configurare de funcționare SSSD arata ca:

Servere

Dacă doriți undeva pentru clienții pentru a cere informații, ai nevoie de un server., Serverul trebuie să aibă o schemă RFC-2307 validă pentru a conține obiectele LDAP necesare. Dacă faceți LDAP bazat pe UNIX și doriți să utilizați Microsoft Active Directory pentru a servi autentificarea bazată pe UNIX, atunci va trebui să vă asigurați că serverul are atribute UNIX în schemă. În timp ce Microsoft Active Directory rulează pe un backend LDAP, nu este adevărat server LDAP bazat pe UNIX până când extindeți schema. Vorbesc puțin despre asta în postarea mea pe blog pe IDMU.după cum se menționează în secțiunea client, aveți nevoie de o grămadă de informații pentru a configura clienții. Serverul este locul de unde provin aceste informații., Iată lucrurile pe care trebuie să le verificați pe server pentru a vă asigura că vă configurați corect clienții:

• informații despre rețeaua serverului (adresa IP, numele de gazdă, intrările DNS, înregistrările SRV, porturile serverului LDAP etc.)
• nivel bind acceptat (utilizați cel mai puternic disponibil, dacă este posibil)
• utilizator bind Valid sau SPN
• informații DN
• Schema type/attributes

serverele LDAP pot găzdui tone de informații. Unix user creds, Windows creds, netgroups, IP addresses, SPN, name mapping rules…. Depinde doar de ceea ce susțin clienții care determină ce puteți utiliza.,

servere LDAP comune

servere LDAP toate tind să adere la un set comun de standarde definite de IETF. Acest lucru este de a asigura o gamă largă de sprijin pentru clienți., Unele dintre cele mai comune servere LDAP includ (dar nu sunt limitate la):

• Active Directory
• OpenLDAP
• RedHat Directory Server/389 Directory Server
• Apple Open Directory
• Oracle Internet Directory
• ApacheDS

LDAP Recomandari

Dacă utilizați mai multe servere LDAP și un client nu este în măsură de a găsi un obiect pe un anumit server LDAP de domeniu, se pot încerca să utilizeze un LDAP sesizare să se uite la alte servere., În esență, este nevoie de informații în serverul LDAP despre alte servere știm despre și încearcă să se conecteze la ele prin LDAP URI până când fie a) găsește obiectul sau b) rămâne fără servere pentru a încerca. Acest lucru se poate întâmpla atât în serverele LDAP Windows, cât și în cele non-Windows. Unii clienți LDAP nu acceptă „urmărirea recomandărilor”, deci este important să știți dacă acest lucru se întâmplă în mediul dvs. și dacă clientul dvs. este capabil să urmărească recomandările.,în Active Directory, este posibil să stocați o copie a atributelor din mai multe domenii într-o pădure pe controlerele de domenii locale care acționează ca servere de Catalog globale. În mod implicit, atributele UNIX nu sunt reproduse în catalogul Global, dar puteți schimba acest comportament după cum este necesar. Am acoperi cum se face acest lucru în TR-4073. Dacă trebuie să interogați mai multe domenii în aceeași pădure și doriți să evitați trimiterile LDAP, puteți reproduce pur și simplu atributele necesare și puteți schimba portul LDAP în 3268 pentru a anunța serverele să utilizeze catalogul Global în schimb!,

mediul meu

în mediul meu, folosesc Active Directory LDAP cu managementul identității. Dar am fost cunoscut de a utiliza OpenLDAP și RedHat Directory Services. Ambele sunt perfect valabile pentru utilizare. Cu toate acestea, dacă intenționați să faceți multiprotocol NAS (CIFS/SMB și NFS), vă sugerez cu tărie utilizarea Microsoft Active Directory pentru autentificare pentru utilizatorii Unix și Windows. Face viața infinit mai ușoară.

dacă utilizați deja LDAP bazat pe Linux, este în regulă. Dacă este posibil, încercați să vă asigurați că numele de utilizator Unix (atributul UID LDAP) se potrivesc cu numele de utilizator Windows (atributul sAMAccount)., În acest fel, dacă utilizați multiprotocol NAS, nu trebuie să vă faceți griji cu privire la maparea numelui.dacă doriți să vedeți ceva adăugat la această postare cu privire la serverele și clienții LDAP, nu ezitați să comentați sau să mă urmați pe Twitter @Nfsdudeabides!

Wrap-up

Pentru informații mai detaliate despre configurația LDAP (în special cu NetApp clustered Data ONTAP), consultați TR-4073: Secure Unified Authentication.

de asemenea, stay tuned pentru mai multe în seria de bază LDAP pe acest blog!,link-uri către alte secțiuni pot fi găsite pe primul post din această serie:

Ce naiba este un LDAP oricum?