I protocolli di condivisione dei file come SMB (CIFS), NFSv3 con gruppi estesi e NFSv4, che utilizzano i principali della sicurezza, si basano su servizi di directory esterni per fornire informazioni sull'identità utente. NetApp Volumes si basa su Microsoft Active Directory per i servizi di directory. Active Directory fornisce servizi come i server LDAP per la ricerca di oggetti, ad esempio utenti, gruppi, account macchina, i server DNS per la risoluzione dei nomi host e i server Kerberos per l'autenticazione.
Per ulteriori informazioni, consulta le best practice per l'esecuzione di Active Directory su Google Cloud.
Microsoft Active Directory gestito di Google Cloud non è supportato da NetApp Volumes.
Casi d'uso
NetApp Volumes utilizza Active Directory per i casi descritti nelle sezioni seguenti.
Servizio di dominio SMB
Active Directory è il servizio di dominio centrale per SMB. SMB viene utilizzato per la verifica dell'identità e le ricerche di identità per utenti e gruppi. I volumi NetApp si uniscono al dominio come membri e non supportano SMB in modalità di gruppo di lavoro.
Supporto dei gruppi estesi NFSv3
Per NFSv3 con supporto dei gruppi estesi, Active Directory fornisce il server LDAP necessario per la ricerca di oggetti come utenti, gruppi o account macchina. Nello specifico, è necessario un server LDAP conforme a RFC2307bis per le ricerche di ID utente e ID gruppo. Il supporto di LDAP viene attivato nei pool di archiviazione durante la loro creazione.
Il supporto dei gruppi estesi ignora tutti gli ID gruppo inviati dal client NFS in una chiamata NFS. Invece, prende l'ID utente della richiesta e cerca tutti gli ID gruppo per l'ID utente specificato nel server LDAP per eseguire i controlli delle autorizzazioni dei file.
Per saperne di più, consulta Gestire gli attributi POSIX RFC2307bis di LDAP.
Mappatura dell'entità di sicurezza NFSv4.x all'ID utente e all'ID gruppo
Per NFSv4.x, Active Directory viene utilizzato per mappare i principali della sicurezza agli ID utente e ai gruppi. NFSv4 utilizza un modello di autenticazione basato su entità. Nell'autenticazione basata su entità, gli utenti vengono identificati da entità di sicurezza che hanno il formato user@dns_domain (vedi https://www.rfc-editor.org/rfc/rfc7530.html#section-19) anziché da ID utente e ID gruppo. Per mappare i principali della sicurezza agli ID utente e ai gruppi quando si accede al volume utilizzando un protocollo NFSv4.x, NetApp Volumes richiede un server LDAP conforme a RFC2307bis. L'unico server LDAP supportato è Active Directory. Il supporto di LDAP viene attivato nei pool di archiviazione durante la loro creazione.
Per utilizzare i principali della sicurezza, il client e il server NFS devono connettersi alla stessa origine LDAP e il file idmapd.conf deve essere configurato sul client. Per ulteriori informazioni sulla configurazione del file idmapd.conf, consulta la pagina di manuali di Ubuntu: idmapd.conf - file di configurazione per libnfsidmap.
Il nome di dominio Active Directory viene utilizzato per dns_domain. user è il nome degli utenti di Active Directory. Utilizza questi valori quando imposti gli attributi POSIX LDAP.
Per utilizzare NFSv4.1 senza configurare la mappatura degli ID e utilizzare solo ID utente e ID gruppo in modo simile a NFSv3, puoi utilizzare ID numerici per ignorare i principali della sicurezza. NetApp Volumes supporta gli ID numerici e gli attuali client NFS utilizzano per impostazione predefinita gli ID numerici se la mappatura degli ID non è configurata.
NFSv4.x con Kerberos
Se utilizzi Kerberos, è obbligatorio utilizzare Active Directory come server LDAP per le ricerche degli elementi di sicurezza. Le entità Kerberos vengono utilizzate come identificatori di sicurezza. Active Directory viene utilizzato anche come KDC (Key Distribution Center) Kerberos. Per farlo, devi collegare al pool un criterio Active Directory contenente le impostazioni Kerberos e attivare il supporto di LDAP su un pool di archiviazione durante la creazione del pool.
Per ulteriori informazioni, consulta Creare un pool di archiviazione.
Accesso LDAP di Active Directory
Per i casi d'uso NFS, Active Directory viene utilizzato come server LDAP. NetApp Volumes si aspetta che i dati di identità utilizzino uno schema RFC2307bis. Active Directory fornisce già questo schema, ma devi assicurarti di compilare gli attributi obbligatori per gli utenti e i gruppi.
NetApp Volumes utilizza le credenziali fornite dal criterio Active Directory per eseguire il binding con LDAP utilizzando la firma LDAP.
Se non è possibile trovare l'utente o il gruppo, l'accesso viene negato.
Memorizzazione nella cache degli attributi
NetApp Volumes memorizza nella cache i risultati delle query LDAP. La tabella seguente descrive le impostazioni della durata (TTL) per la cache LDAP. Se la cache contiene dati non validi a causa di configurazioni errate che stai cercando di correggere, devi attendere che la cache venga aggiornata prima che le modifiche in Active Directory vengano rilevate. In caso contrario, il server NFS continua a utilizzare i vecchi dati per verificare l'accesso, il che probabilmente genera messaggi di autorizzazione negata sul client. Al termine del periodo TTL, le voci vengono eliminate in modo che quelle obsolete non rimangano inutilizzate. Le richieste di ricerca che non vengono trovate vengono conservate per un TTL di un minuto per evitare problemi di prestazioni.
| Cache | Tempo di attesa predefinito |
|---|---|
| Elenco delle iscrizioni ai gruppi | TTL di 24 ore |
| Gruppi Unix (GID) | TTL di 24 ore, TTL negativo di 1 minuto |
| Utenti Unix (UID) | TTL di 24 ore, TTL negativo di 1 minuto |
Topologie dei controller di dominio Active Directory
Dopo aver eseguito la connessione ai controller di dominio Active Directory, puoi utilizzare i seguenti protocolli di condivisione file:
- PMI
- NFSv3 con gruppi estesi
- NFSv4
Le sezioni seguenti illustrano varie potenziali topologie. I diagrammi mostrano solo il controller di dominio utilizzato da NetApp Volumes. Gli altri controller di dominio per lo stesso dominio vengono mostrati solo se necessario.
Microsoft consiglia di implementare almeno due controller di dominio (DC) per la ridondanza e la disponibilità.
Domain controller Active Directory nella stessa regione dei volumi NetApp Volumes
Il seguente diagramma mostra la modalità di implementazione più semplice, un controller di dominio nella stessa regione dei volumi NetApp.
Controller di dominio Active Directory in più regioni che utilizzano i siti AD
Se utilizzi volumi NetApp Volumes in più regioni, ti consigliamo di collocare almeno un controller di dominio in ogni regione. Sebbene il servizio cerchi di scegliere automaticamente il DC migliore da utilizzare, è consigliabile gestire la selezione del DC utilizzando i siti AD.
Domain controller Active Directory in una rete on-premise
L'utilizzo di un controller di dominio on-premise tramite VPN è supportato, ma potrebbe influire negativamente sulle prestazioni dell'autenticazione e dell'accesso ai file degli utenti finali. Assicurati di non aggiungere altri hop di peering VPC nel percorso di rete.
Considerazioni per i DC on-premise
Le connessioni ai DC on-premise utilizzano TCP e IP. Queste connessioni spesso non riescono a causa delle seguenti limitazioni:
Peering VPC: i volumi NetApp possono raggiungere solo i DC che si trovano nella VPC del pool di archiviazione o che sono collegati tramite VPN. I volumi NetApp non possono raggiungere i DC in nessun altro VPC, inclusi quelli in peering con il VPC che si connette al pool di archiviazione.
Firewall: devi consentire a NetApp Volumes di contattare i tuoi DC. Consulta le regole del firewall per l'accesso ad Active Directory.
Domain controller Active Directory in un'altra rete VPC
Non puoi posizionare il controller di dominio in un VPC diverso perché il peering VPC di Google Cloud non consente l'instradamento transitivo. In alternativa, puoi collegare i volumi NetApp a una rete VPC condivisa che ospita i controller di dominio Active Directory. Se colleghi i volumi NetApp a una rete VPC condivisa, dal punto di vista dell'architettura questo scenario diventa uno degli scenari descritti nelle sezioni precedenti.
Gestire le selezioni dei controller di dominio utilizzando i siti AD
Per rappresentare le sedi, gli uffici e la topologia di rete dei data center il più fedelmente possibile, posiziona i controller di dominio nella stessa regione dei volumi e definisci un sito Active Directory per quella regione.
Quando NetApp Volumes è connesso al tuo dominio, il servizio utilizza il rilevamento basato su DNS per trovare i controller di dominio corretti con cui comunicare. Utilizzando i risultati della scoperta, il servizio gestisce un elenco di DC validi a cui connettersi e utilizza quello con la latenza più bassa.
Quando specifichi un sito nelle impostazioni di Active Directory dei volumi NetApp, puoi limitare l'elenco dei DC a quelli specificati nel sito AD.
Se la selezione automatica del DC non va a buon fine, l'utilizzo dei siti AD può contribuire a risolvere il problema:
Esegui il deployment di almeno un controller di dominio nella regione dei volumi NetApp e collegalo ad Active Directory esistente.
Crea un sito Active Directory per la tua regione Google Cloud e inserisci i controller di dominio appropriati in questo sito.
Utilizza il sito Active Directory quando configuri le connessioni ad Active Directory.
Per verificare manualmente l'elenco dei potenziali DC che il servizio può utilizzare, consulta Come identificare i controller di dominio Active Directory utilizzati da NetApp Volumes
Per ulteriori informazioni, consulta Active Directory: considerazioni sul design e best practice.