Informazioni sull'uso di LDAP con Azure NetApp Files

Articolo
06/13/2024

Ldap (Lightweight Directory Access Protocol) è un protocollo di accesso alla directory standard sviluppato da un comitato internazionale denominato IETF (Internet Engineering Task Force). LDAP è progettato per fornire un servizio directory generico basato sulla rete che è possibile usare su piattaforme eterogenee per individuare gli oggetti di rete.

I modelli LDAP definiscono come comunicare con l'archivio directory LDAP, come trovare un oggetto nella directory, come descrivere gli oggetti nell'archivio e la sicurezza usata per accedere alla directory. LDAP consente la personalizzazione e l'estensione degli oggetti descritti nell'archivio. Pertanto, è possibile usare un archivio LDAP per archiviare molti tipi di informazioni diverse. Molte delle distribuzioni LDAP iniziali sono incentrate sull'uso di LDAP come archivio directory per applicazioni come posta elettronica e applicazioni Web e per archiviare le informazioni sui dipendenti. Molte aziende sostituiscono o hanno sostituito Network Information Service (NIS) con LDAP come archivio directory di rete.

Un server LDAP fornisce identità utente e gruppo UNIX per l'uso con volumi NAS. In Azure NetApp Files Active Directory è l'unico server LDAP attualmente supportato che può essere usato. Questo supporto include sia Dominio di Active Directory Services (AD DS) che Microsoft Entra Domain Services.

Le richieste LDAP possono essere suddivise in due operazioni principali.

I binding LDAP sono account di accesso al server LDAP da un client LDAP. L'associazione viene usata per eseguire l'autenticazione al server LDAP con accesso in sola lettura per eseguire ricerche LDAP. Azure NetApp Files funge da client LDAP.
Le ricerche LDAP vengono usate per eseguire query sulla directory per ottenere informazioni su utenti e gruppi, ad esempio nomi, ID numerici, percorsi della home directory, percorsi della shell di accesso, appartenenze ai gruppi e altro ancora.

LDAP può archiviare le informazioni seguenti usate nell'accesso NAS a doppio protocollo:

Nomi utente
Nomi di gruppo
ID utente numerici (UID) e ID gruppo (GID)
Home directory
Shell di accesso
Netgroup, nomi DNS e indirizzi IP
Appartenenza al gruppo

Attualmente, Azure NetApp Files usa LDAP solo per informazioni su utenti e gruppi, senza informazioni su netgroup o host.

LDAP offre vari vantaggi per gli utenti e i gruppi UNIX come origine delle identità.

LDAP è a prova di futuro.
Man mano che altri client NFS aggiungono il supporto per NFSv4.x, i domini ID NFSv4.x che contengono un elenco aggiornato di utenti e gruppi accessibili dai client e dall'archiviazione sono necessari per garantire una sicurezza ottimale e l'accesso garantito quando viene definito l'accesso. Avere un server di gestione delle identità che fornisce mapping di nomi uno a uno per gli utenti SMB e NFS semplifica notevolmente la vita per gli amministratori di archiviazione, non solo nel presente, ma per anni a venire.
LDAP è scalabile.
I server LDAP offrono la possibilità di contenere milioni di oggetti utente e gruppo e, con Microsoft Active Directory, è possibile usare più server per la replica in più siti per la scalabilità delle prestazioni e della resilienza.
LDAP è sicuro.
LDAP offre sicurezza sotto forma di come un sistema di archiviazione può connettersi al server LDAP per effettuare richieste di informazioni utente. I server LDAP offrono i livelli di associazione seguenti:
- Anonimo (disabilitato per impostazione predefinita in Microsoft Active Directory; non supportato in Azure NetApp Files)
- Password semplice (password di testo normale, non supportata in Azure NetApp Files)
- Autenticazione semplice e livello di sicurezza (SASL): metodi di associazione crittografati, tra cui TLS, SSL, Kerberos e così via. Azure NetApp Files supporta LDAP su TLS, firma LDAP (tramite Kerberos), LDAP su SSL.
LDAP è affidabile.
I file NIS, NIS+e locali offrono informazioni di base quali UID, GID, password, home directory e così via. Tuttavia, LDAP offre questi attributi e molti altri. Gli attributi aggiuntivi usati da LDAP rendono la gestione a doppio protocollo molto più integrata con LDAP rispetto a NIS. Solo LDAP è supportato come servizio di nomi esterno per la gestione delle identità con Azure NetApp Files.
Microsoft Active Directory è basato su LDAP.
Per impostazione predefinita, Microsoft Active Directory usa un back-end LDAP per le voci di utenti e gruppi. Tuttavia, questo database LDAP non contiene attributi di stile UNIX. Questi attributi vengono aggiunti quando lo schema LDAP viene esteso tramite Identity Management per UNIX (Windows 2003R2 e versioni successive), Service for UNIX (Windows 2003 e versioni precedenti) o strumenti LDAP di terze parti, ad esempio Centrify. Poiché Microsoft usa LDAP come back-end, rende LDAP la soluzione perfetta per gli ambienti che scelgono di sfruttare i volumi a doppio protocollo in Azure NetApp Files.

Nota

Azure NetApp Files attualmente supporta solo Microsoft Active Directory nativo per i servizi LDAP.

Nozioni di base su LDAP in Azure NetApp Files

La sezione seguente illustra le nozioni di base di LDAP in quanto riguarda Azure NetApp Files.

Le informazioni LDAP vengono archiviate in file flat in un server LDAP ed è organizzato tramite uno schema LDAP. È consigliabile configurare i client LDAP in modo da coordinare le richieste e le ricerche con lo schema nel server LDAP.
I client LDAP avviano query tramite un'associazione LDAP, che è essenzialmente un account di accesso al server LDAP usando un account con accesso in lettura allo schema LDAP. La configurazione dell'associazione LDAP nei client è configurata per l'uso del meccanismo di sicurezza definito dal server LDAP. In alcuni casi, sono scambi di nomi utente e password in testo normale (semplice). In altri casi, le associazioni vengono protette tramite metodi simple authentication e security layer (sasl), ad esempio Kerberos o LDAP su TLS. Azure NetApp Files usa l'account del computer SMB per eseguire l'associazione usando l'autenticazione SASL per ottenere la massima sicurezza possibile.
Le informazioni sull'utente e sul gruppo archiviate in LDAP vengono sottoposte a query dai client usando richieste di ricerca LDAP standard, come definito in RFC 2307. Inoltre, i meccanismi più recenti, ad esempio RFC 2307bis, consentono ricerche di utenti e gruppi più semplificate. Azure NetApp Files usa una forma di RFC 2307bis per le ricerche dello schema in Windows Active Directory.
I server LDAP possono archiviare informazioni su utenti e gruppi e netgroup. Azure NetApp Files attualmente non può usare la funzionalità netgroup in LDAP in Windows Active Directory.
LDAP in Azure NetApp Files opera sulla porta 389. Questa porta attualmente non può essere modificata per usare una porta personalizzata, ad esempio la porta 636 (LDAP su SSL) o la porta 3268 (ricerche nel Catalogo globale di Active Directory).
Le comunicazioni LDAP crittografate possono essere ottenute usando LDAP su TLS (che opera sulla porta 389) o la firma LDAP, entrambe configurate nella connessione Active Directory.
Azure NetApp Files supporta query LDAP che richiedono non più di 3 secondi per il completamento. Se il server LDAP ha molti oggetti, è possibile che il timeout venga superato e che le richieste di autenticazione non riescano. In questi casi, valutare la possibilità di specificare un ambito di ricerca LDAP per filtrare le query per ottenere prestazioni migliori.
Azure NetApp Files supporta anche la specifica dei server LDAP preferiti per velocizzare le richieste. Usare questa impostazione se si vuole assicurarsi che il server LDAP più vicino all'area di Azure NetApp Files venga usato.

Se non è impostato alcun server LDAP preferito, il nome di dominio di Active Directory viene sottoposto a query in DNS per i record del servizio LDAP per popolare l'elenco dei server LDAP disponibili per l'area all'interno del record SRV. È possibile eseguire manualmente query sui record del servizio LDAP in DNS da un client usando nslookup comandi o dig .

Ad esempio:

C:\>nslookup
Default Server:  localhost
Address:  ::1

> set type=SRV
> _ldap._tcp.contoso.com.

Server:  localhost
Address:  ::1

_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 0
          port           = 389
          svr hostname   = oneway.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = ONEWAY.Contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = oneway.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = parisi-2019dc.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = contoso.com
oneway.contoso.com       internet address = x.x.x.x
ONEWAY.Contoso.com       internet address = x.x.x.x
oneway.contoso.com       internet address = x.x.x.x
parisi-2019dc.contoso.com        internet address = y.y.y.y
contoso.com      internet address = x.x.x.x
contoso.com      internet address = y.y.y.y

I server LDAP possono essere usati anche per eseguire il mapping dei nomi personalizzati per gli utenti. Per altre informazioni, vedere Mapping dei nomi personalizzati con LDAP.
Timeout delle query LDAP

Per impostazione predefinita, le query LDAP si verifica un timeout se non possono essere completate in modo tempestivo. Se una query LDAP non riesce a causa di un timeout, la ricerca dell'utente e/o del gruppo avrà esito negativo e l'accesso al volume di Azure NetApp Files potrebbe essere negato, a seconda delle impostazioni di autorizzazione del volume. Per informazioni sulle impostazioni di timeout delle query LDAP di Azure NetApp Files, vedere Creare e gestire connessioni Active Directory.

Tipi di mapping dei nomi

Le regole di mapping dei nomi possono essere suddivise in due tipi principali: simmetrica e asimmetrica.

Il mapping dei nomi simmetrici è il mapping implicito dei nomi tra gli utenti UNIX e Windows che usano lo stesso nome utente. Ad esempio, l'utente di Windows esegue il mapping all'utente CONTOSO\user1 user1UNIX.
Il mapping dei nomi asimmetrici è il mapping dei nomi tra gli utenti UNIX e Windows che usano nomi utente diversi . Ad esempio, l'utente di Windows esegue il mapping all'utente CONTOSO\user1 user2UNIX.

Per impostazione predefinita, Azure NetApp Files usa regole di mapping dei nomi simmetrici. Se sono necessarie regole di mapping dei nomi asimmetriche, è consigliabile configurare gli oggetti utente LDAP per usarli.

Mapping di nomi personalizzati con LDAP

LDAP può essere una risorsa di mapping dei nomi, se gli attributi dello schema LDAP nel server LDAP sono stati popolati. Ad esempio, per eseguire il mapping degli utenti UNIX ai nomi utente di Windows corrispondenti che non corrispondono a uno,ovvero asimmetrico, è possibile specificare un valore diverso per uid nell'oggetto utente rispetto a quello configurato per il nome utente di Windows.

Nell'esempio seguente, un utente ha un nome Windows di asymmetric e deve eseguire il mapping a un'identità UNIX di UNIXuser. Per ottenere questo risultato in Azure NetApp Files, aprire un'istanza del Utenti e computer di Active Directory MMC. Individuare quindi l'utente desiderato e aprire la casella delle proprietà. In questo modo è necessario abilitare l'editor di attributi. Passare alla scheda Editor attributi e trovare il campo UID, quindi popolare il campo UID con il nome UNIXuser utente UNIX desiderato e fare clic su Aggiungi e OK per confermare.

Al termine di questa azione, i file scritti dalle condivisioni SMB di Windows dall'utente asymmetric di Windows saranno di proprietà del UNIXuser lato NFS.

L'esempio seguente mostra il proprietario asymmetricSMB di Windows :

L'esempio seguente mostra il proprietario UNIXuser NFS (mappato dall'utente asymmetric di Windows tramite LDAP):

root@ubuntu:~# su UNIXuser
UNIXuser@ubuntu:/root$ cd /mnt
UNIXuser@ubuntu:/mnt$ ls -la
total 8
drwxrwxrwx  2 root     root   4096 Jul  3 20:09 .
drwxr-xr-x 21 root     root   4096 Jul  3 20:12 ..
-rwxrwxrwx  1 UNIXuser group1   19 Jul  3 20:10 asymmetric-user-file.txt

Consentire utenti NFS locali con LDAP

Quando un utente tenta di accedere a un volume di Azure NetApp Files tramite NFS, la richiesta viene inserita in un ID numerico. Per impostazione predefinita, Azure NetApp Files supporta le appartenenze estese ai gruppi per gli utenti NFS (per superare il limite standard di 16 gruppi). Di conseguenza, Azure NetApp files tenterà di accettare tale ID numerico e cercarlo in LDAP nel tentativo di risolvere le appartenenze ai gruppi per l'utente anziché passare le appartenenze ai gruppi in un pacchetto RPC. A causa di questo comportamento, se tale ID numerico non può essere risolto in un utente in LDAP, la ricerca avrà esito negativo e l'accesso verrà negato, anche se l'utente richiedente ha l'autorizzazione per accedere al volume o alla struttura dei dati. L'opzione Consenti utenti NFS locali con LDAP nelle connessioni Active Directory è destinata a disabilitare le ricerche LDAP per le richieste NFS disabilitando la funzionalità del gruppo esteso. Non fornisce "creazione/gestione utente locale" in Azure NetApp Files.

Quando l'opzione "Consenti utenti NFS locali con LDAP" è abilitata, gli ID numerici vengono passati ad Azure NetApp Files e non viene eseguita alcuna ricerca LDAP. In questo modo viene creato un comportamento variabile per diversi scenari, come illustrato di seguito.

NFSv3 con volumi di stile di sicurezza UNIX

Gli ID numerici non devono essere convertiti in nomi utente. L'opzione "Consenti utenti NFS locali con LDAP" non influisce sull'accesso al volume, ma può influire sulla modalità di visualizzazione della proprietà dell'utente/gruppo (traduzione dei nomi) nel client NFS. Ad esempio, se un ID numerico 1001 è user1 in LDAP, ma è user2 nel file passwd locale del client NFS, il client visualizzerà "user2" come proprietario del file quando l'ID numerico è 1001.

NFSv4.1 con volumi di stile di sicurezza UNIX

Gli ID numerici non devono essere convertiti in nomi utente. Per impostazione predefinita, NFSv4.1 usa le stringhe dei nomi (user@CONTOSO.COM) per l'autenticazione. Tuttavia, Azure NetApp Files supporta l'uso di ID numerici con NFSV4.1, il che significa che le richieste NFSv4.1 arriveranno al server NFS con un ID numerico. Se non esiste alcun ID numerico per la conversione dei nomi utente nei file locali o nei servizi dei nomi come LDAP per il volume di Azure NetApp Files, il valore numerico viene presentato al client. Se un ID numerico viene convertito in un nome utente, verrà usata la stringa del nome. Se la stringa del nome non corrisponde, il client eseguirà lo squash del nome all'utente anonimo specificato nel file idmapd.conf del client. L'abilitazione dell'opzione "Consenti utenti NFS locali con LDAP" non influirà sull'accesso NFSv4.1, perché eseguirà il fallback al comportamento NFSv3 standard, a meno che Azure NetApp Files non possa risolvere un ID numerico in un nome utente nel database utente NFS locale. Azure NetApp Files ha un set di utenti UNIX predefiniti che possono essere problematici per alcuni client e squash a un utente "nessuno" se le stringhe ID di dominio non corrispondono.

Gli utenti locali includono: root (0), pcuser (65534), nessuno (65535).
I gruppi locali includono: root (0), daemon (1), pcuser (65534), nessuno (65535).

In genere, la radice potrebbe essere visualizzata in modo errato nei montaggi client NFSv4.1 quando l'ID di dominio NFSv4.1 non è configurato correttamente. Per altre informazioni sul dominio ID NFSv4.1, vedere Configurazione del dominio ID NFSv4.1 per Azure NetApp Files.

Gli ACL NFSv4.1 possono essere configurati usando una stringa di nome o un ID numerico. Se vengono usati ID numerici, non è necessaria alcuna traduzione dei nomi. Se viene usata una stringa del nome, la traduzione dei nomi sarebbe necessaria per una corretta risoluzione ACL. Quando si usano gli ACL NFSv4.1, l'abilitazione di "Consenti utenti NFS locali con LDAP" può causare un comportamento di ACL NFSv4.1 errato a seconda della configurazione ACL.

NFS (v3 e v4.1) con volumi di stile di sicurezza NTFS in configurazioni con doppio protocollo

I volumi di stile di sicurezza UNIX sfruttano le autorizzazioni di stile UNIX (bit di modalità e ACL NFSv4.1). Per questi tipi di volumi, NFS sfrutta solo l'autenticazione in stile UNIX sfruttando un ID numerico o una stringa di nome, a seconda degli scenari elencati in precedenza. I volumi di stile di sicurezza NTFS, tuttavia, usano autorizzazioni di stile NTFS. Queste autorizzazioni vengono assegnate usando utenti e gruppi di Windows. Quando un utente NFS tenta di accedere a un volume con un'autorizzazione di stile NTFS, deve verificarsi un mapping dei nomi UNIX a Windows per garantire controlli di accesso appropriati. In questo scenario, l'ID numerico NFS viene ancora passato al volume NFS di Azure NetApp Files, ma è necessario convertire l'ID numerico in un nome utente UNIX in modo che possa quindi essere mappato a un nome utente di Windows per l'autenticazione iniziale. Ad esempio, se l'ID numerico 1001 tenta di accedere a un montaggio NFS con autorizzazioni di stile di sicurezza NTFS che consentono l'accesso all'utente di Windows "user1", 1001 deve essere risolto in LDAP con il nome utente "user1" per ottenere l'accesso previsto. Se non esiste alcun utente con l'ID numerico "1001" in LDAP o se LDAP non è configurato correttamente, il mapping dei nomi UNIX a Windows che viene tentato sarà 1001@contoso.com. Nella maggior parte dei casi, gli utenti con tale nome non esistono, quindi l'autenticazione non riesce e l'accesso viene negato. Analogamente, se l'ID numerico 1001 viene risolto con il nome utente errato (ad esempio user2), la richiesta NFS verrà mappata a un utente Windows imprevisto e le autorizzazioni per l'utente useranno i controlli di accesso "user2".

L'abilitazione di "Consenti utenti NFS locali con LDAP" disabiliterà tutte le traduzioni LDAP di ID numerici ai nomi utente, che interromperanno efficacemente l'accesso ai volumi di stile di sicurezza NTFS. Di conseguenza, l'uso di questa opzione con volumi di stile di sicurezza NTFS è altamente sconsigliato.

Schemi LDAP

Gli schemi LDAP sono il modo in cui i server LDAP organizzano e raccolgono informazioni. Gli schemi del server LDAP seguono in genere gli stessi standard, ma i provider di server LDAP diversi potrebbero presentare variazioni sulla modalità di presentazione degli schemi.

Quando Azure NetApp Files esegue query LDAP, gli schemi vengono usati per velocizzare le ricerche dei nomi perché consentono l'uso di attributi specifici per trovare informazioni su un utente, ad esempio l'UID. Per trovare la voce, gli attributi dello schema devono esistere nel server LDAP per Azure NetApp Files. In caso contrario, le query LDAP potrebbero non restituire dati e le richieste di autenticazione potrebbero non riuscire.

Ad esempio, se un numero UID (ad esempio root=0) deve essere sottoposto a query da Azure NetApp Files, viene usato l'attributo dello schema RFC 2307 uidNumber Attribute . Se nel campo non esiste alcun numero 0 UID, uidNumber la richiesta di ricerca ha esito negativo.

Il tipo di schema attualmente usato da Azure NetApp Files è una forma di schema basato su RFC 2307bis e non può essere modificato.

RFC 2307bis è un'estensione di RFC 2307 e aggiunge il supporto per posixGroup, che consente ricerche dinamiche per i gruppi ausiliari usando l'attributo uniqueMember , anziché usando l'attributo memberUid nello schema LDAP. Anziché usare solo il nome dell'utente, questo attributo contiene il nome distinto completo (DN) di un altro oggetto nel database LDAP. Di conseguenza, i gruppi possono avere altri gruppi come membri, che consente l'annidamento di gruppi. Il supporto per RFC 2307bis aggiunge anche il supporto per la classe groupOfUniqueNamesoggetto .

Questa estensione RFC si adatta perfettamente al modo in cui Microsoft Active Directory gestisce utenti e gruppi tramite gli strumenti di gestione consueti. Ciò è dovuto al fatto che quando si aggiunge un utente di Windows a un gruppo (e se tale gruppo ha un GID numerico valido) usando i metodi di gestione standard di Windows, le ricerche LDAP eseguiranno automaticamente il pull delle informazioni aggiuntive necessarie sul gruppo dall'attributo di Windows consueto e troveranno automaticamente i GID numerici.

Condividi tramite