LDAP:: Server e client LDAP – Parte 5

AGGIORNAMENTO: Oggi mi sono reso conto di aver scritto questo stesso argomento due volte, in due post diversi., Questo dovrebbe essere considerato lo sforzo combinato, ma può leggere un po ‘ come un blog Frankenstein. L’originale dell’altro rimane qui:

Questo post è parte 5 della nuova serie LDAP Ho iniziato ad aiutare le persone a diventare più consapevoli di cosa sia LDAP e di come funziona.

La prima parte è stata pubblicata qui:

Che diamine è comunque un LDAP?

Questo post si concentrerà su server e client LDAP.,

Server vs client

Nel regno animale, vedrai spesso relazioni simboliche, come la presunta relazione tra coccodrilli e l’uccello piviere, che mangia roba morta dai denti del coccodrillo.

Anche la relazione client / server LDAP è simbiotica. Il server ha bisogno del client per porre domande e il client ha bisogno del server per alimentare le informazioni.,

Se la natura non fa per te, c’è sempre la relazione simbiotica Spider-Man/Venom:

Nel caso di LDAP, un cliente chiederà cose come nomi utente, posizioni della directory home, appartenenze di gruppo, ecc. Il server sarebbe responsabile della consegna di tali informazioni.

LDAP non è diverso da altri protocolli, come HTTP, NFS, ecc. Esiste una relazione client e server. E proprio come ogni relazione di successo, ci deve essere qualcuno che parla e qualcuno che ascolta.

Ho un figlio di due anni. Parla, ma la maggior parte è solo pratica per lui., Dira ‘cose tipo” dada, bird truck.”E io dirò” Uccello? Camion? Figo!”È per lo più una conversazione unilaterale in cui essenzialmente ACK i suoi SYNs. (Ho bisogno di uscire di più)

A volte, è “dada leggi il libro.”E io obbedisco.

Le conversazioni client / server LDAP non sono molto diverse. Il cliente è il mio bambino di due anni. Il server LDAP sono io.

“LDAP, trova informazioni utente”

“Informazioni utente? Figo! Ecco qua!”

Alla sua base, le conversazioni LDAP non sono altro che SYN TCP e ACK. Quindi, durante la configurazione o la risoluzione dei problemi, dovrebbero essere trattati come tali.,

Dove le cose si confondono è quando si inizia a considerare ciò che serve per una relazione client / server per avere successo. Non è una buona idea lasciare i canali di comunicazione spalancati per tutti nel mondo da vedere, quindi ci sono alcune regole che dobbiamo seguire quando i clienti vogliono parlare con i server.

Configurazione client/Server

I client LDAP possono essere qualsiasi software in esecuzione in grado di interrogare LDAP tramite gli standard RFC-2307. Windows, Linux, sistemi operativi di storage, ecc possono tutti agire come client., Alcuni sistemi operativi contengono funzionalità LDAP integrate (come Windows) che non richiedono l’installazione di nulla di speciale. Alcuni sistemi di archiviazione, come il cluster di dati ONTAP di NetApp, supportano completamente LDAP che aderisce allo standard RFC-2307. Per ulteriori informazioni, vedere TR-4073: Secure Unified Authentication.

Informazioni di rete di base.

Ricorda, alla sua base, è una semplice conversazione TCP.

• Nomi server LDAP, URI o indirizzi IP (il server è in DNS? Ci sono record SRV per LDAP?,)
• Porta LDAP (le porte predefinite sono 389 per LDAP, 636 per LDAP su SSL, 3268 per il catalogo globale; hai cambiato la porta del server?)
• Il client può parlare con il server (routing?)

Prima che un client possa avviare una conversazione con un server, deve essere configurato con informazioni su quel server. La configurazione seguirà le basi del modello O, a partire dai primi strati dello stack per avviare una conversazione TCP con il server.

Client LDAP comuni

Anche i client LDAP tendono ad aderire agli stessi standard dei server. Perché?, Perché ha senso. I client possono stare da soli da un sistema operativo, ma alcuni sistemi operativi integrano LDAP nella loro configurazione per impostazione predefinita. Windows è un esempio di questo a causa di come LDAP integrale è di Active Directory.

Altri client includono (ma non sono certamente limitati a):

• SSSD
• OpenLDAP

Speriamo che le informazioni in questo post abbiano aiutato a chiarire qualsiasi confusione su client e server LDAP.

Alcuni server LDAP ti permetteranno persino di apportare modifiche alla porta su cui è in ascolto per la comunicazione LDAP., Questo per aiutare a proteggere i server LDAP non sfruttando porte ben note. Con i server LDAP comuni come Active Directory, tuttavia, è difficile utilizzare porte diverse da quelle comuni. Quando si configurano i client, è sempre necessario rivedere la configurazione del server LDAP.

Dopo aver superato la connessione TCP, passiamo il nostro tempo nel livello di applicazione del modelloSI.

Informazioni bind / Login.

Per prima cosa dobbiamo preoccuparci di autenticarci sul server LDAP. Questo è anche noto come vincolante., Il livello di autenticazione dipenderà da ciò che il server è stato impostato per consentire. Il livello di autenticazione più basso possibile è “anonimo”, ma nessun server LDAP moderno consente il binding anonimo per impostazione predefinita. In genere, è necessario un account di sola lettura sul server LDAP per autenticarsi su un server per emettere query LDAP.

Le informazioni di bind necessarie sono incluse nella configurazione del client. Per la configurazione più sicura, è preferibile utilizzare un sistema di autenticazione basato su ticket o chiave rispetto all’utilizzo di password.,

LDAP Informazioni di ricerca

Dopo un bind ha luogo, le query vengono eseguite. La natura delle query dipenderà dalla configurazione del client. Che schema stiamo usando? Di quali informazioni abbiamo bisogno? Abbiamo configurato il client per essere sicuri di provare LDAP per informazioni in ogni momento (tramite nsswitch.configurazione conf)? Abbiamo detto al client da dove iniziare a cercare informazioni sul server LDAP fornendo il DN di base?

Questo indica al client da dove iniziare a cercare informazioni nel server LDAP.,Il formato per queste informazioni è Distinguished Names (DNs), che copro nella parte 4. È possibile impostare un DN di base e quindi DNs specifici per utenti, gruppi, netgroup, ecc. È anche possibile specificare più posizioni per la ricerca. L’idea qui è di filtrare le nostre ricerche per accelerare le cose per i clienti.

Fatto divertente: Apple corregge automaticamente DNs in DNS. Non va bene, Apple. Non va bene.

Una volta che il client LDAP ha le informazioni necessarie, dovrebbe separarsi – non vogliamo rimanere connessi indefinitamente. E ‘ un maiale delle risorse.

LDAP schema informazioni

I coprire schemi in dettaglio sulla parte 3., Molti client conoscono gli schemi predefiniti utilizzati da LDAP, come RFC-2307, RFC-2307bis, ecc. Nella maggior parte dei casi, gli schemi sul server non si allontaneranno da quello. Ma in alcuni casi, come attraverso l’intervento manuale o strumenti di terze parti come Dell Vintela (noto anche come Centrify, Quest, ecc.), potrebbe essere necessario apportare modifiche. Questo può essere fatto sul cliente. Ciò consente al client di chiedere le informazioni giuste dal server, che quindi consente al server di trovare le informazioni e rispondere al client.,

Opzioni specifiche del client

Molti client offrono opzioni specifiche come il caching di utenti / gruppi, credenziali, configurazione di Kerberos, ecc. Questi sono generalmente facoltativi, ma dovrebbero essere esaminati su base vendor per cliente.

Configurazione del client di esempio

Il seguente è un esempio di come sarebbe un client LDAP ONTAP dati cluster:

Questo è ciò che la mia configurazione del client che esegue SSSD assomiglia:

Server

Se vuoi da qualche parte per i client chiedere informazioni, hai bisogno di un server., Il server deve disporre di uno schema RFC-2307 valido per contenere gli oggetti LDAP necessari. Se si sta eseguendo LDAP basato su UNIX e si desidera utilizzare Microsoft Active Directory per fornire l’autenticazione basata su UNIX, è necessario assicurarsi che il server abbia attributi UNIX nello schema. Mentre Microsoft Active Directory viene eseguito su un backend LDAP, non è vero server LDAP basato su UNIX finché non si estende lo schema. Parlo un po ‘ di questo nel mio post sul blog su IDMU.

Come menzionato nella sezione client, hai bisogno di un sacco di informazioni per configurare i client. Il server è da dove provengono queste informazioni., Ecco le cose che devi controllare sul server per assicurarti di configurare correttamente i tuoi client:

• Informazioni sulla rete del server (indirizzo IP, nome host, voci DNS, record SRV, porte del server LDAP, ecc.)
• Livello di bind supportato (utilizzare il più forte disponibile, se possibile)
• Utente bind valido o SPN
• Informazioni DN
• Tipo di schema/attributi

I server LDAP possono ospitare tonnellate di informazioni. Creds utente UNIX, creds Windows, netgroups, indirizzi IP, SPN, regole di mappatura dei nomi…. Dipende solo da ciò che i clienti supportano che determina ciò che è possibile utilizzare.,

Server LDAP comuni

Tutti i server LDAP tendono ad aderire a un insieme comune di standard come definito da If. Questo per garantire una vasta gamma di supporto per i clienti., Alcuni dei più comuni server LDAP includono (ma non sono limitati a):

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

Riferimenti LDAP

Se si utilizzano più server LDAP e un client non è in grado di trovare un oggetto in un determinato LDAP server di dominio, si può tentare di utilizzare un LDAP rinvio a guardare in altri server., In sostanza, prende informazioni nel server LDAP su altri server che conosciamo e tenta di connettersi a loro tramite URI LDAP fino a quando a) trova l’oggetto o b) esaurisce i server da provare. Questo può accadere sia nei server LDAP Windows che non Windows. Alcuni client LDAP non supportano il “referral chasing”, quindi è importante sapere se ciò sta accadendo nel tuo ambiente e se il tuo cliente è in grado di inseguire i referral.,

Ricerche di catalogo globale

In Active Directory, è possibile memorizzare una copia di attributi da più domini in una foresta su controller di dominio locali che agiscono come server di catalogo globale. Per impostazione predefinita, gli attributi UNIX non vengono replicati nel catalogo globale, ma è possibile modificare tale comportamento in base alle esigenze. Copro come farlo in TR-4073. Se è necessario interrogare più domini nella stessa foresta e si desidera evitare i referral LDAP, è sufficiente replicare gli attributi necessari e modificare la porta LDAP su 3268 per far sapere ai server di utilizzare invece il catalogo globale!,

Il mio ambiente

Nel mio ambiente, uso Active Directory LDAP con Gestione delle identità. Ma sono stato conosciuto per usare i servizi di directory OpenLDAP e RedHat. Entrambi sono perfettamente validi da usare. Tuttavia, se si è intenzionati a eseguire NAS multiprotocollo (CIFS / SMB e NFS), si consiglia vivamente di utilizzare Microsoft Active Directory per l’autenticazione per gli utenti UNIX e Windows. Rende la vita infinitamente più facile.

Se stai già usando LDAP basato su Linux, va bene. Se possibile, provare a verificare che i nomi utente UNIX (attributo LDAP uid) corrispondano ai nomi utente Windows (attributo sAMAccount)., In questo modo, se si utilizza il NAS multiprotocollo, non è necessario preoccuparsi della mappatura dei nomi.

Se volete vedere qualcosa aggiunto a questo post per quanto riguarda i server LDAP e client, sentitevi liberi di commentare o seguirmi su Twitter @NFSDudeAbides!

Wrap-up

Per informazioni più dettagliate sulla configurazione LDAP (in particolare con NetApp clustered Data ONTAP), vedere TR-4073: Secure Unified Authentication.

Inoltre, rimanete sintonizzati per ulteriori informazioni sulla serie di basi LDAP su questo blog!,

I link ad altre sezioni possono essere trovati sul primo post di questa serie:

Che diamine è comunque un LDAP?