Informazioni sull'uso di LDAP con Azure NetApp Files

  • Articolo

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 eseguono il 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\user1user1UNIX.
  • 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\user1user2UNIX.

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.

Screenshot that shows the Asymmetric Properties window and Multi-valued String Editor window.

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 :

Screenshot that shows Windows SMB owner named Asymmetric.

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

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.

Passaggi successivi