Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
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 tenta di accettare tale ID numerico e cercarlo in LDAP (Lightweight Directory Access Protocol) in un 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 non riesce e l'accesso viene negato. Questo rifiuto si verifica anche se l'utente richiedente dispone dell'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. 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 visualizza "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 arrivano 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, viene usata la stringa del nome. Se la stringa del nome non corrisponde, il client applica il nome all'utente anonimo specificato nel file idmapd.conf del client. L'abilitazione dell'opzione "Consenti utenti NFS locali con LDAP" non influisce sull'accesso NFSv4.1. L'accesso esegue 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 per 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 (NFSv3 e NFSv4.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 DA 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 del nome UNIX a Windows completa il tentativo con 1001@contoso.com. Nella maggior parte dei casi, gli utenti con tale nome non esistono. Di conseguenza, 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 viene mappata all'utente di Windows non corretto (in questo scenario, user1 ha concesso l'accesso a user2).
L'abilitazione di "Consenti utenti NFS locali con LDAP" disabilita tutte le traduzioni LDAP degli ID numerici ai nomi utente. Questa azione interrompe efficacemente l'accesso ai volumi dello stile di sicurezza NTFS. Di conseguenza, l'uso di questa opzione con volumi di stile di sicurezza NTFS è sconsigliato.