Configurare il dominio ID NFSv4.1 per Azure NetApp Files

  • Articolo

NFSv4 introduce il concetto di dominio di autenticazione ID. Azure NetApp Files usa il valore defaultv4iddomain.com di voce come dominio di autenticazione e i client NFS usano la propria configurazione per autenticare gli utenti che vogliono accedere ai file in tali volumi. Per impostazione predefinita, i client NFS useranno il nome di dominio DNS come dominio ID NFSv4. È possibile eseguire l'override di questa impostazione usando il file di configurazione NFSv4 denominato idmapd.conf.

Se le impostazioni del dominio di autenticazione nel client NFS e Azure NetApp Files non corrispondono, l'accesso ai file potrebbe essere negato perché il mapping di utenti e gruppi NFSv4 potrebbe non riuscire. In questo caso, gli utenti e i gruppi che non corrispondono correttamente eseguiranno lo squash dell'utente e del idmapd.conf gruppo configurati nel file (in genere nessuno:99) e un evento verrà registrato sul client.

Questo articolo illustra il comportamento predefinito del mapping di utenti/gruppi e come configurare i client NFS corretti per l'autenticazione corretta e consentire l'accesso. 

Comportamento predefinito del mapping di utenti/gruppi

Il mapping dell'utente radice può illustrare cosa accade in caso di mancata corrispondenza tra i client Azure NetApp Files e NFS. Il processo di installazione di un'applicazione richiede spesso l'uso dell'utente radice. Azure NetApp Files può essere configurato per consentire l'accesso per root.

Nell'esempio di elenco di directory seguente, l'utente root monta un volume in un client Linux che usa la configurazione localdomain predefinita per il dominio di autenticazione ID, che è diverso dalla configurazione predefinita di Azure NetApp Files di defaultv4iddomain.com.

Screenshot of file directory output.

Nell'elenco dei file nella directory viene file1 visualizzato come mappato a nobody, quando deve essere di proprietà dell'utente radice.

Esistono due modi per modificare il dominio di autenticazione su entrambi i lati: Azure NetApp Files come server NFS e Linux come client NFS:

  1. Gestione utenti centrale: se si usa già una gestione utenti centrale, ad esempio servizi di Dominio di Active Directory , è possibile configurare i client Linux per l'uso di LDAP e impostare il dominio configurato in Servizi di dominio Active Directory come dominio di autenticazione. Sul lato server è necessario abilitare il servizio di dominio AD per Azure NetApp Files e creare volumi abilitati per LDAP. I volumi abilitati per LDAP usano automaticamente il dominio configurato in Active Directory Domain Services come dominio di autenticazione.

    Per altre informazioni su questo processo, vedere Abilitare l'autenticazione LDAP di Dominio di Active Directory Services (AD DS) per i volumi NFS.

  2. Configurare manualmente il client Linux: se non si usa una gestione utente centrale per i client Linux, è possibile configurare manualmente i client Linux in modo che corrispondano al dominio di autenticazione predefinito di Azure NetApp Files per i volumi non abilitati per LDAP.

In questa sezione verrà illustrato come configurare il client Linux e come modificare il dominio di autenticazione di Azure NetApp Files per tutti i volumi non abilitati per LDAP.

Configurare il dominio ID NFSv4.1 in Azure NetApp Files

È possibile specificare un dominio ID NFSv4.1 desiderato per tutti i volumi non LDAP usando il portale di Azure. Questa impostazione si applica a tutti i volumi non LDAP in tutti gli account NetApp nella stessa sottoscrizione e nella stessa area. Non influisce sui volumi abilitati per LDAP nella stessa sottoscrizione e nella stessa area netApp.

Registrare la funzionalità

Azure NetApp Files supporta la possibilità di impostare il dominio ID NFSv4.1 per tutti i volumi non LDAP in una sottoscrizione usando il portale di Azure. Questa funzionalità è attualmente disponibile solo in anteprima. È necessario registrare la funzionalità prima di usarla per la prima volta. Dopo la registrazione, la funzionalità è abilitata e funziona in background.

  1. Registrare la funzionalità

    Register-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFNFSV4IDDomain

  2. Controllare lo stato della registrazione delle funzionalità:

    Nota

    RegistrationState può trovarsi nello Registering stato per un massimo di 60 minuti prima di passare a Registered. Attendere fino a quando lo stato non viene Registered eseguito prima di continuare.

    Get-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFNFSV4IDDomain

È anche possibile usare iaz feature register comandi dell'interfaccia della riga di comando di Azure e az feature show per registrare la funzionalità e visualizzare lo stato di registrazione.

Passaggi

  1. Nella sottoscrizione di Azure NetApp Files selezionare NFSv4.1 ID Domain (Dominio ID NFSv4.1).

  2. Seleziona Configura.

  3. Per usare il dominio defaultv4iddomain.compredefinito, selezionare la casella accanto a Usa dominio ID NFSv4 predefinito. Per usare un altro dominio, deselezionare la casella di testo e specificare il nome del dominio ID NFSv4.1.

    Screenshot with field to set NFSv4 domain.

  4. Seleziona Salva.

Configurare il dominio ID NFSv4.1 nei client NFS

  1. Modificare il /etc/idmapd.conf file nel client NFS.
    Rimuovere il commento dalla riga #Domain , ovvero rimuovere dalla # riga, e modificare il valore localdomain come indicato di seguito:

    • Se il volume non è abilitato per LDAP, usare il dominio defaultv4iddomain.com predefinito specificando Domain = defaultv4iddomain.como specificare il dominio ID NFSv4.1 come configurato in Azure NetApp Files.
    • Se il volume è abilitato per LDAP, impostare sul Domain dominio configurato in Active Directory Connessione ion nell'account NetApp. Ad esempio, se contoso.com è il dominio configurato nell'account NetApp, impostare Domain = contoso.com.

    Gli esempi seguenti illustrano la configurazione iniziale di prima delle /etc/idmapd.conf modifiche:

    [General]
Verbosity = O 
Pipefs—Directory = /run/rpc_pipefs 
# set your own domain here, if it differs from FQDN minus hostname 
# Domain = localdomain 

[Mapping] 
Nobody-User = nobody 
Nobody-Group = nogroup

    L'esempio seguente mostra la configurazione aggiornata dei volumi non LDAP NFSv4.1 per il dominio defaultv4iddomain.compredefinito :

    [General]
Verbosity = O 
Pipefs—Directory = /run/rpc_pipefs 
# set your own domain here, if it differs from FQDN minus hostname 
Domain = defaultv4iddomain.com 

[Mapping] 
Nobody-User = nobody 
Nobody-Group = nogroup

    L'esempio seguente mostra la configurazione aggiornata dei volumi NFSv4.1 abilitati per LDAP. In questo esempio, contoso.com è il dominio configurato nell'account NetApp:

    [General]
Verbosity = O 
Pipefs—Directory = /run/rpc_pipefs 
# set your own domain here, if it differs from FQDN minus hostname 
Domain = contoso.com

[Mapping] 
Nobody-User = nobody 
Nobody-Group = nogroup

  2. Smontare tutti i volumi NFS attualmente montati.

  3. Aggiornare il file /etc/idmapd.conf.

  4. Cancellare il keyring di NFS idmapper (nfsidmap -c).

  5. Montare i volumi NFS in base alle esigenze.

    Vedere Montare un volume per macchine virtuali Windows o Linux.

L'esempio seguente mostra la modifica di utenti/gruppi risultanti:

Screenshot that shows an example of the resulting user/group change.

Come illustrato nell'esempio, l'utente/gruppo è ora passato da nobody a root.

Comportamento di altri utenti e gruppi (nonroot)

Azure NetApp Files supporta utenti e gruppi locali (creati localmente nel client NFS e rappresentati da ID utente e gruppo) e la proprietà e le autorizzazioni corrispondenti associate a file o cartelle nei volumi NFSv4.1. Tuttavia, il servizio non risolve automaticamente il mapping di utenti e gruppi locali tra client NFS. Gli utenti e i gruppi creati in un host possono esistere o meno in un altro client NFS (o esistono con ID utente e gruppo diversi) e pertanto non verranno mappati correttamente come descritto nell'esempio seguente.

Nell'esempio seguente sono Host1 presenti tre account utente (testuser01, testuser02, testuser03):

Screenshot that shows that Host1 has three existing test user accounts.

In Host2non esistono account utente corrispondenti, ma lo stesso volume viene montato in entrambi gli host:

Resulting configuration for NFSv4.1

Per risolvere questo problema, creare gli account mancanti nel client NFS o configurare i client NFS per l'uso del server LDAP usato da Azure NetApp Files per le identità UNIX gestite centralmente.

Passaggi successivi