Informazioni su Kerberos in Azure NetApp Files

Kerberos è un protocollo di autenticazione che usa una chiave privata per convalidare l'identità delle entità. Le chiavi segrete vengono generate prendendo la password di un'entità e convertendola in un formato di chiave crittografica con hash usando un metodo di crittografia concordato dal client e dal server (ad esempio AES). Per informazioni sui termini usati in questo documento, vedere la sezione Terminologia Kerberos.

I centri di distribuzione di chiavi (KDC),ad esempio Active Directory di Windows, mantengono un database di entità Kerberos e le relative password con hash. In Kerberos la chiave privata è una prova di un'identità univoca. Di conseguenza, il KDC può essere considerato attendibile per autenticare qualsiasi entità a qualsiasi altra entità, ad esempio l'autenticazione di un nome SPN (Service Principal Name) del client NFS a un nome SPN del server NFS durante il montaggio. Può anche essere considerato attendibile per autenticare un'entità utente a un nome SPN del server NFS per l'accesso utente a un punto di montaggio NAS. Come misura di sicurezza aggiuntiva, Kerberos non invia password di testo non crittografato per l'autenticazione attraverso la rete.

Azure NetApp Files supporta l'uso di Kerberos per garantire la sicurezza in anteprima per i protocolli SMB e NFS.

Tipi di crittografia supportati

Azure NetApp Files supporta Kerberos NFS con tipi di crittografia specifici, a seconda della modalità operativa e della versione usata.

Per assicurarsi che un client usi il tipo di crittografia appropriato, è possibile limitare i tipi di crittografia validi nell'entità oggetto che si trova nel Centro distribuzione chiavi (ad esempio, l'account computer) o nel file keytab creato manualmente del client anziché globalmente nel file /etc/krb5.conf, se possibile, poiché la gestione di numerosi file krb5.conf client può causare un problema di gestione. La gestione centralizzata di Kerberos dal KDC è più scalabile in ambienti aziendali di grandi dimensioni, è più semplice da automatizzare e forza il client a usare tipi di crittografia più avanzati quando sono supportati.

Note

È consigliabile impostare l'opzione allow_weak_crypto su false nel file krb5.conf nei client. Questa impostazione impedisce una minore sicurezza enctypes per la comunicazione Kerberos (ad esempio DES o 3DES).

La tabella seguente illustra i tipi di crittografia supportati per Kerberos (SMB e NFS) per Azure NetApp Files.

Protocollo Tipi di crittografia supportati
Piccole e Medie Imprese (PMI)
  • RC4-HMAC
  • AES-128
  • AES-256
NFS AES-256

Modalità di sicurezza Kerberos NFS supportate

Oltre al concetto di tipi di crittografia, esistono anche livelli di controllo della sicurezza e dell'integrità in Kerberos. A seconda della modalità di sicurezza in uso, queste modalità di sicurezza consentono di evitare attacchi man-in-the-middle offrendo la crittografia end-to-end per il traffico NFS.

In Azure NetApp Files queste modalità di sicurezza vengono specificate nelle regole dei criteri di esportazione impostate per il volume per NFS e definite durante il montaggio NFS iniziale tramite l'opzione di montaggio sec.

Ad esempio: # mount -o sec=krb5p

Note

Per Kerberos SMB, le modalità di sicurezza per Kerberos vengono controllate tramite impostazioni di crittografia SMB nella condivisione, la protezione avanzata UNC e i criteri di firma/chiusura SMB nei controller di dominio.

Le modalità di sicurezza seguenti sono supportate da Azure NetApp Files per l'uso con Kerberos NFS:

Modalità di sicurezza Descrizione
krb5 Solo crittografia dell'autenticazione.

Usa stringhe dei nomi Kerberos V5 e nomi di entità utente anziché ID utente UNIX (UID) locali e ID gruppo (GID) per autenticare gli utenti.
krb5i Crittografia dell'autenticazione e controllo dell'integrità crittografata.

Usa Kerberos V5 per l'autenticazione utente ed esegue anche il controllo dell'integrità delle operazioni NFS usando checksum sicuri per evitare manomissioni dei dati e attacchi man-in-the-middle.
krb5p Intera conversazione NFS crittografata.

Usa Kerberos V5 per il controllo autenticazione e integrità degli utenti e crittografa anche tutto il traffico NFS per impedire l'analisi dei pacchetti. Questa impostazione è la più sicura, ma crea anche il sovraccarico delle prestazioni più alto.

Terminologia Kerberos

Questa sezione definisce la terminologia chiave usata durante la descrizione dei processi Kerberos. Questa sezione è destinata a chiarire i termini che potrebbero non essere familiari agli amministratori di archiviazione.

Termine Definizione
Centro distribuzione chiavi (KDC) Il KDC è il server di autenticazione che include il servizio di concessione ticket (TGS) e il servizio di autenticazione (AS). I termini KDC, AS e TGS vengono usati in modo intercambiabile. Negli ambienti Microsoft un controller di dominio Active Directory (AD) è un KDC. La modifica dei valori KDC può essere ottenuta solo modificando le impostazioni di Active Directory.
Area di autenticazione (o area di autenticazione Kerberos) Un'area di autenticazione (o area di autenticazione Kerberos) può usare qualsiasi stringa ASCII. Lo standard consiste nell'usare il nome di dominio in lettere maiuscole; ad esempio, contoso.com diventa l'area di autenticazione CONTOSO.COM. Le aree di autenticazione Kerberos vengono in genere configurate nei file krb5.conf nei client e nei server.

Amministrativamente, ogni principal@REALM deve essere univoco. Per evitare un singolo punto di errore, ogni area di autenticazione può avere più KDC che condividono lo stesso database (entità e password) e hanno le stesse chiavi master KDC. Microsoft Windows Active Directory esegue questa operazione in modo nativo tramite la replica di Active Directory, che avviene ogni 15 minuti per impostazione predefinita.
Server principale Il termine principal fa riferimento a ogni entità all'interno di un database Kerberos. Gli utenti, i computer e i servizi sono tutte entità assegnate per l'autenticazione Kerberos. Ogni entità deve essere univoca all'interno del database Kerberos ed è definita da un suo nome distinto. Un'entità può essere un nome dell'entità utente (UPN) o un nome dell'entità servizio (SPN).

Il nome di un'entità ha tre parti:
  • Primario: la parte primaria può essere un utente o un servizio, ad esempio il servizio NFS. Può anche trattarsi del servizio speciale "host", che indica che questa entità servizio è configurata per fornire più servizi di rete.
  • Istanza: questa parte è facoltativa nel caso di un utente. Un utente può avere più di un'entità, ma ogni entità deve essere univoca nel KDC. Ad esempio, Fred potrebbe avere un'entità di sicurezza per uso quotidiano (fred@contoso.com) e un'entità che consente l'uso con privilegi, ad esempio un account sysadmin (admin-fred@contoso.com). L'istanza è necessaria per le entità servizio e definisce il nome di dominio completo (FQDN) dell'host che fornisce il servizio.
  • Area di autenticazione: un'area di autenticazione Kerberos è il set di entità Kerberos registrate all'interno di un server Kerberos. Per convenzione, il nome dell'area di autenticazione è in genere uguale al nome DNS, ma viene convertito in lettere maiuscole. Le lettere maiuscole non sono obbligatorie, ma la convenzione fornisce una semplice distinzione tra il nome DNS e il nome dell'area di autenticazione.
Ticket Un ticket è un set temporaneo di credenziali che verifica l'identità di un'entità per un servizio e contiene la chiave di sessione. Un ticket può essere un servizio, un ticket di applicazione o un ticket-granting ticket (TGT). I ticket vengono scambiati tra client, server e KDC per l'autenticazione Kerberos.
Chiavi private Kerberos usa un sistema di chiavi simmetriche in cui viene usata la chiave privata sia per la crittografia che per la decrittografia. La chiave privata viene generata dalla password Kerberos dell'entità di sicurezza con una funzione hash unidirezionale. Il KDC archivia la password per ogni entità e può quindi generare la chiave privata dell'entità. Per gli utenti che richiedono un servizio Kerberos, la chiave privata in genere deriva da una password presentata al programma kinit. Le entità servizio e daemon in genere non usano una password; il risultato della funzione hash unidirezionale viene invece archiviato in un keytab.
Keytab Un keytab contiene un elenco di entità e le relative chiavi segrete. Le chiavi segrete in un keytab vengono spesso create usando una password casuale e vengono usate principalmente per le entità servizio o daemon.

Informazioni sulla porta di rete

La tabella seguente illustra le porte di rete usate per le comunicazioni Kerberos. Se è presente un firewall di rete, queste porte devono essere aperte per consentire la corretta funzionalità Kerberos. Per altre informazioni su queste porte, vedere IANA Service Name e Transport Protocol Port Number Registry.

Servizio Porta
Kerberos 88 (TCP/UDP)
kpasswd 464 (TCP/UDP)
Lightweight directory access protocol (LDAP) (per i mapping dei nomi) 389 (TCP/UDP)
Server admin 749 (TCP/UDP)
Catalogo globale (ricerche utente di Windows) 3268 (TCP/UDP)

Valori di validità della cache in Azure NetApp Files

Nella tabella seguente viene visualizzato il tempo di memorizzazione di una voce della cache in un volume di Azure NetApp Files.

Cache Validità della cache
Connessioni al server dei nomi inattive 60 secondi
Timeout query LDAP 10 secondi
Voce host DNS locale per KDC TTL 24 ore
Validità del ticket Kerberos Specificato da KDC* e/o client

* Il valore predefinito è 10 ore per i KDC di Windows Active Directory
Credenziali dell'utente 24 ore
Sfasamento orario Kerberos 5 minuti

Requisiti per il corretto funzionamento degli ambienti Kerberos in Azure NetApp Files

L'autenticazione Kerberos dipende in modo elevato dai servizi esterni per una funzionalità appropriata. In Microsoft Active Directory la maggior parte di questi servizi viene combinata in un singolo server in molti casi. Ad esempio, un controller di dominio Active Directory può eseguire le dipendenze Kerberos seguenti:

  • Servizi di sincronizzazione dell'orario
  • Sistema dei Nomi di Dominio (DNS)
  • Distribuzione delle chiavi Kerberos
  • Servizi password/Single Sign-On
  • Servizi di identità (ad esempio LDAP)

Quando si usa Microsoft Active Directory nativo (l'unico tipo di KDC attualmente supportato da Azure NetApp Files), la maggior parte delle dipendenze esterne per Kerberos in Azure NetApp Files è coperta, ad esempio DNS, KDC e servizi password. In alcuni casi, i servizi necessari possono essere ospitati all'esterno del dominio di Active Directory, ad esempio DNS. In questi casi, è importante assicurarsi che i servizi necessari siano configurati correttamente.

Azure NetApp Files presenta dipendenze specifiche per il corretto funzionamento di Kerberos NFS. Continuare a leggere per altre informazioni.

Servizi di sincronizzazione dell'orario

I servizi di sincronizzazione dell'ora sono obbligatori quando si usa Kerberos per l'autenticazione, poiché i meccanismi dei ticket Kerberos dipendono dalle differenze temporali tra client e server entro un intervallo di 5 minuti predefinito. Se le impostazioni relative all'ora nel client o nel server superano l'intervallo di cinque minuti, l'autenticazione Kerberos non va a buon fine con un errore di asimmetria temporale (KRB_AP_ERR_SKEW) e l'accesso viene negato alla condivisione NAS. Questo timeout è una funzionalità di sicurezza che consente di impedire "attacchi di riproduzione", in cui un utente malintenzionato può intercettare i messaggi tra KDC e client e quindi riprodurre tali messaggi in un secondo momento per rappresentare un utente autenticato. I limiti di asimmetria temporale consentono di ridurre al minimo il rischio di questi tipi di attacchi.

Considerazioni chiave per i problemi di sincronizzazione dell'orario:

Per altre informazioni, vedere Tolleranza massima per la sincronizzazione dell'orologio del computer.

Domain Name Systems (DNS)

Domain Name Systems (DNS) è obbligatorio per Kerberos come funzionalità di sicurezza. La risoluzione del nome host viene usata per formulare le entità servizio Kerberos usate per l'autenticazione. In questo processo, le ricerche dirette di nomi host (record A/AAAA) vengono usate per connettersi alle condivisioni che sfruttano l'autenticazione Kerberos. La ricerca diretta viene quindi usata per formulare il nome dell'entità servizio (SPN) usato nella richiesta di autenticazione Kerberos. Se non è possibile trovare un nome SPN esistente nel KDC, l'autenticazione Kerberos ha esito negativo.

Negli ambienti SMB di Windows è possibile provare un metodo di autenticazione di backup, ad esempio NTLM. Tuttavia, in molti casi, NTLM è disabilitato per motivi di sicurezza, il che causa un errore di accesso alla condivisione quando l'autenticazione Kerberos non riesce. Il Visualizzatore eventi di Windows registra spesso la causa radice degli errori (ad esempio SPN duplicati/mancanti, errori di ricerca DNS, errori NTLM e così via).

Oltre alla risoluzione SPN, DNS viene ampiamente utilizzato per risolvere i nomi host e gli indirizzi IP per i servizi di dominio, ad esempio LDAP, KDC Kerberos e così via tramite record SRV. Per informazioni più dettagliate sul DNS in Azure NetApp Files (inclusi i record SRV necessari), vedere Informazioni su DNS in Azure NetApp Files.

Note

Se per l'accesso Kerberos viene usato un indirizzo IP, il comportamento dipende dal protocollo NAS (NFS o SMB) in uso. Per altre informazioni, vedere Indirizzi IP per l'accesso con Kerberos.

LDAP

Lightweight Directory Access Protocol (LDAP) sfrutta i database di identità back-end per fornire un'origine unificata del servizio dei nomi per i client e i server NAS in modo che tutti i dispositivi partecipanti accettino l'autenticità dell'utente, le appartenenze ai gruppi e gli ID numerici, che vengono quindi usati per le autorizzazioni dei file.

Per Kerberos, le entità utente e servizio vengono archiviate con le voci nei database LDAP come attributi negli account di entità di sicurezza Windows Active Directory supporta questa funzionalità per impostazione predefinita. In alcuni casi, ad esempio durante la creazione di alias o entità servizio, gli utenti e i computer richiedono l'aggiunta o la modifica dei nomi delle entità servizio. È possibile soddisfare questo requisito usando Microsoft Management Console (MMC) Utenti e computer di Active Directory o con PowerShell. Per altre informazioni sulla gestione dei nomi delle entità servizio, vedere Gestione dei nomi delle entità servizio.

Oltre ai nomi delle entità servizio e agli ID numerici per l'autenticazione Kerberos, LDAP può essere usato anche per le identità di utenti e gruppi UNIX, usate per il mapping dei nomi di identità in Azure NetApp Files, nonché per l'autenticazione iniziale per i montaggi Kerberos NFS tramite un nome SPN -> mapping dei nomi utente UNIX. Per altre informazioni, vedere Funzionamento di Kerberos NFS nel ruolo di Azure NetApp Files e LDAP con Kerberos in Azure NetApp Files.

Funzionamento di Kerberos SMB in Azure NetApp Files

Kerberos SMB funziona separatamente dai servizi Kerberos NFS, poiché gli account computer creati per ogni protocollo non possono condividere i keytab a causa del potenziale di modifiche al numero di versione chiave (kvno) in un keytab che influisce sull'altro servizio. Di conseguenza, oltre alle differenze naturali nei protocolli NAS, i flussi di lavoro per i servizi SMB per Kerberos e NFS per Kerberos differiscono in alcune aree.

Configurazione iniziale dei servizi SMB

I servizi SMB in Azure NetApp Files vengono inizialmente configurati configurando una connessione Active Directory, che definisce diversi elementi critici per l'interazione con i servizi di dominio, tra cui:

  • Server DNS primario (obbligatorio)
  • DNS secondario
  • Nome DNS di Active Directory*
  • Nome del sito di Active Directory (per l'individuazione del controller di dominio) (obbligatorio)
  • Nome del prefisso del server SMB
  • Unità organizzativa (in cui vengono creati gli account dei computer server SMB)
  • Abilitazione/disabilitazione della crittografia AES
  • Abilitazione/disabilitazione della firma LDAP
  • Configurazione LDAP
  • Crittografia SMB nel controller di dominio
  • Utenti con privilegi
  • Credenziali di nome utente/password dell'utente con autorizzazioni dell'unità organizzativa

Note

È consentita una sola connessione di Azure Active Directory (AD) per account. Dopo aver creato la connessione AD, qualsiasi nuovo volume SMB di Azure NetApp Files usa la configurazione della connessione AD.

Account computer Kerberos SMB

Un account computer in Active Directory contiene informazioni rilevanti per l'uso nelle richieste di autenticazione, incluso il nome dell'entità servizio (SPN). Quando si crea un volume SMB in Azure NetApp Files, la configurazione delle connessioni di Active Directory viene usata per l'interazione nella creazione di un account computer per fornire l'accesso sicuro a una condivisione SMB tramite l'autenticazione Kerberos (o NTLM, se abilitata).

I nuovi account computer vengono creati quando viene effettuato il provisioning di un volume SMB di Azure NetApp Files in una risorsa back-end specifica nel servizio. Di seguito sono illustrati diversi scenari in cui è possibile creare o riutilizzare un account computer SMB nelle configurazioni del volume di Azure NetApp Files.

Sceneggiatura Risultato
Primo nuovo volume SMB Nuovo account computer SMB/nome DNS
Volumi SMB successivi creati in breve successione dal primo volume SMB Account computer SMB/nome DNS riutilizzato (nella maggior parte dei casi).
I volumi SMB successivi creati molto più tardi rispetto al primo volume SMB Il servizio determina se è necessario un nuovo account computer. È possibile creare più account computer, creando più endpoint di indirizzi IP.
Primo volume a doppio protocollo Nuovo account computer SMB/nome DNS
I volumi a doppio protocollo successivi creati in breve successione dal primo volume a doppio protocollo Account computer SMB/nome DNS riutilizzato (nella maggior parte dei casi)
I volumi con doppio protocollo successivi sono stati creati molto più tardi rispetto al primo volume con doppio protocollo. Il servizio determina se è necessario un nuovo account computer. È possibile creare più account computer, creando più endpoint di indirizzi IP
Primo volume SMB creato dopo il volume a doppio protocollo Nuovo account computer SMB/nome DNS
Primo volume a doppio protocollo creato dopo il volume SMB Nuovo account computer SMB/nome DNS

L'account macchina SMB creato per il volume SMB (o a doppio protocollo) di Azure NetApp Files utilizza una convenzione di denominazione che rispetta il limite di 15 caratteri imposto da Active Directory. Il nome usa la struttura di [prefisso del server SMB specificato nella configurazione della connessione di Azure AD]-[identificatore numerico univoco].

Ad esempio, se sono state configurate le connessioni AD per l'uso del prefisso del server SMB "AZURE", l'account del computer SMB creato da Azure NetApp Files è simile a "AZURE-7806". Lo stesso nome viene usato nel percorso UNC per la condivisione SMB ,ad esempio \AZURE-7806, ed è il nome usato dai servizi DNS dinamici per creare il record A/AAAA.

Note

Poiché un nome come "AZURE-7806" può essere difficile da ricordare, è utile creare un record CNAME come alias DNS per i volumi di Azure NetApp Files. Per altre informazioni, vedere Creazione di alias server SMB.

Diagramma di più account computer/voci DNS in Azure NetApp Files.

In alcuni casi, quando si creano più volumi SMB e/o dual-protocol, la configurazione può finire con più account di computer SMB e nomi DNS diversi.

Se si desidera uno spazio dei nomi singolo per l'accesso utente tra i volumi, questo può presentare una sfida nella configurazione, poiché un singolo alias CNAME può puntare solo a un singolo record host A/AAAA, mentre l'uso di più alias di record A/AAAA identici può comportare un'imprevedibilità dell'accesso ai dati nell'accesso ai volumi in diversi account del computer SMB, poiché non esiste alcuna garanzia che l'endpoint selezionato dal client nella ricerca DNS contenga il volume previsto a causa della natura round robin della selezione di record DNS in tali configurazioni.

Per risolvere questa limitazione, i volumi di Azure NetApp Files possono partecipare come destinazioni in una configurazioneMicrosoft Distributed File System (DFS), che consente di associare più volumi SMB a un singolo punto di ingresso dello spazio dei nomi.

Diagramma di un file system distribuito in Azure NetApp Files.

Flusso di lavoro di creazione SPN Kerberos SMB

Il diagramma seguente illustra come viene creato uno SPN Kerberos SMB quando viene creato un volume di Azure NetApp Files SMB o a doppio protocollo. Gli SPN SMB sono associati ad oggetti account computer SMB nel dominio. Il nome SPN può essere visualizzato e gestito tramite le proprietà dell'account del computer usando l'editor di attributi nella visualizzazione Avanzate.

Screenshot delle proprietà di Azure-SMB.

È anche possibile visualizzare e gestire le proprietà con il comando setspn .

Screenshot del comando 'setspn'.

Questo processo segue gli stessi passaggi di quando un normale client Windows aggiunge un dominio (DNS, LDAP, Kerberos, query RPC su named pipe).

Diagramma dell'account del computer Kerberos.

Nella maggior parte dei casi, conoscere i passaggi dettagliati non è necessario per le attività di amministrazione quotidiane, ma è utile per risolvere eventuali errori quando si tenta di creare un volume SMB in Azure NetApp Files.

Procedura dettagliata

For passaggi dettagliati sulla creazione di un account del computer SMB in Azure NetApp Files, espandere l'elenco.

  • La ricerca DNS viene eseguita usando la configurazione DNS per il record SRV di un KDC Kerberos. Azure NetApp Files usa i record SRV seguenti nelle richieste.

    • _kerberos._tcp.dc._msdcs.CONTOSO.COM
    • _kerberos._tcp.CONTOSO.COM (se la query precedente non restituisce risultati)

  • La ricerca DNS viene eseguita usando i nomi host restituiti nella query SRV per i record A/AAAAA dei KDC.

    • Viene effettuato un ping LDAP (LDAP bind e query RootDSE) per cercare i server legacy Netlogon disponibili usando la query (&(DnsDomain=CONTOSO.COM)(NtVer=0x00000016)) con un filtro di attributo per NetLogon. Le versioni più recenti del controller di dominio Windows (più recente della versione del 2008) non hanno il valore NtVer presente.

  • Una query DNS viene eseguita da Azure NetApp Files per trovare i server LDAP nel dominio usando i record SRV seguenti:

    • _ldap._tcp.CONTOSO.COM
    • _kerberos._tcp.CONTOSO.COM

    Note

    Queste query vengono eseguite più volte nella stessa chiamata su parti diverse del processo. I problemi DNS possono creare lentezza in queste chiamate o, con timeout, errori totali. - Se le query non riescono a trovare una voce o se non è possibile contattare le voci trovate, la creazione del volume SMB non riesce. - Se le query DNS hanno esito positivo, i passaggi successivi vengono elaborati.

  • ICMP (ping) viene inviato per verificare che gli indirizzi IP restituiti dal DNS siano raggiungibili.

  • Se il ping è bloccato nella rete dai criteri firewall, la richiesta ICMP ha esito negativo. Vengono invece usati ping LDAP.

  • Viene eseguito un altro ping LDAP per cercare i server NetLogon legacy disponibili usando la query (&(&(DnsDomain=CONTOSO.COM)(Host=KDChostname.contoso.com))(NtVer=0x00000006)) con il filtro attributo NetLogon. Le versioni più recenti del controller di dominio Windows (più recente della versione del 2008) non hanno il valore NtVer presente.

  • Un'autenticazione AS-REQ viene inviata dal servizio Azure NetApp Files usando il nome utente configurato con la connessione Active Directory.

  • Il controller di dominio risponde con KRB5KDC_ERR_PREAUTH_REQUIRED, che chiede al servizio di inviare la password per l'utente in modo sicuro.

  • Un secondo AS-REQ viene inviato con i dati di preautenticazione necessari per l'autenticazione con il KDC per l'accesso per procedere con la creazione dell'account del computer. In caso di esito positivo, viene inviato un ticket di concessione ticket (TGT) al servizio.

  • In caso di esito positivo, un TGS-REQ viene inviato dal servizio per richiedere il ticket di servizio CIFS (cifs/kdc.contoso.com) dal KDC usando il TGT ricevuto nel AS-REP.

  • Viene eseguita una nuova associazione LDAP tramite il ticket di servizio CIFS. Le query vengono inviate da Azure NetApp Files:

    • Ricerca di base RootDSE per il DN ConfigurationNamingContext del dominio
    • Ricerca OneLevel di CN=partitions nel DN recuperato per ConfigurationNamingContext usando il filtro (&(&(objectClass=crossRef)(nETBIOSName=*))(dnsRoot=CONTOSO.COM)) per l'attributo NETBIOSname.
    • Una ricerca di base che usa il filtro (|(objectClass=organizationalUnit)(objectClass=container)) viene eseguita sull'unità organizzativa specificata nella configurazione delle connessioni di Active Directory. Se non specificato, viene utilizzato il valore predefinito OU=Computers. In questo modo viene verificata l'esistenza del contenitore.
    • Viene eseguita una ricerca sottoalbero sul DN di base del dominio usando il filtro (sAMAccountName=ANF-XXXX$) per verificare se l'account esiste già.
      • Se l'account esiste, viene riutilizzato.
    • Se l'account non esiste, viene creato, purché l'utente disponga delle autorizzazioni per creare e modificare oggetti nel contenitore usando un comando LDAP addRequest. Gli attributi LDAP seguenti sono impostati nell'account:
    Attributo valore
    CN ANF-XXXX
    sAMAccountName ANF-XXXX$
    objectClass
    • TOP
    • Persona
    • OrganizationalPerson
    • Utente
    • Computatore
    servicePrincipalName
    • HOST/ANF-XXXX
    • HOST/anf-xxxx.contoso.com
    • CIFS/anf-xxxx.contoso.com
    userAccountControl 4096
    sistema operativo Versione di NetApp
    dnsHostName ANF-XXXX.CONTOSO.COM
    • Se addRequest ha esito negativo, la creazione del volume avrà esito negativo. Un oggetto addRequest può non riuscire a causa di autorizzazioni non corrette per l'oggetto contenitore.
    • Se l'operazione addRequest ha esito positivo, viene eseguita una ricerca LDAP usando il filtro (sAMAccountName=ANF-XXXX$) per recuperare l'attributo objectSid.
    • Viene eseguita una conversazione SMB2 "Negotiate protocol" per recuperare il mechTypes Kerberos supportato dal KDC.
    • Viene eseguita un'operazione "Session setup" di SMB2 che usa il nome SPN CIFS e il mechType più elevato supportato e viene eseguita una "connessione albero" a IPC$.
    • Un file SMB2 lsarpc viene creato nella condivisione IPC$.
    • Viene eseguita un'associazione a DCERPC . Il file lsarpc viene scritto e quindi letto.
    • Vengono quindi eseguite le richieste LSA seguenti:

  • Viene eseguito un TGS-REQ che usa il TGT per recuperare il ticket per il kadmin/changepwSPN associato all'account krbtgt.

  • Viene effettuata una richiesta KPASSWD dal servizio al KDC per modificare la password dell'account del computer.

  • Viene eseguita una query LDAP con il filtro (sAMAccountName=ANF-XXXX) per gli attributi distinguishedName e isCriticalSystemObject.

  • Se l'account isCriticalSystemObject è false (impostazione predefinita), il DN recuperato viene usato per formulare un oggetto modifyRequest per l'attributo msDs-SupportedEncryptionTypes. Questo valore è impostato su 30, che equivale a DES_CBC_MD5 (2) + RC4 (4) + AES 128 (8) + AES 256 (16).

  • Viene eseguita una seconda operazione "Negotiate protocol"/Kerberos ticket exchange/"Session setup"/"Tree connect" a IPC$. L'account computer del server’SMB (ANF-XXXX$) funge da entità Kerberos.

  • Le comunicazioni NetLogon, NetrServer ReqChallenge/Authenticate2 sono state completate.

  • Viene eseguito una terza operazione "Negotiate protocol"/Kerberos ticket exchange/"Session setup"/"Tree connect" a IPC$; l'account computer del server’SMB (ANF-XXXX$) viene usato come entità Kerberos.

  • Entrambe le connessioni lsarpc e NetLogon vengono effettuate come controllo finale dell'account.

Flusso di lavoro della connessione di condivisione SMB (Kerberos)

Quando un volume di Azure NetApp Files viene montato tramite Kerberos, viene usato uno scambio di ticket Kerberos durante le richieste di installazione di più sessioni per fornire l'accesso sicuro alla condivisione. Nella maggior parte dei casi, conoscere i passaggi dettagliati non è necessario per le attività di amministrazione quotidiane. Questa conoscenza è utile per la risoluzione degli errori durante il tentativo di accedere a un volume SMB in Azure NetApp Files.

Diagramma del flusso di lavoro della connessione di condivisione SMB.

Per i passaggi che illustrano in dettaglio l'accesso alla condivisione SMB in Azure NetApp Files, espandere l'elenco.
  • Il client tenta di accedere a una condivisione SMB usando il percorso UNC illustrato in Azure NetApp Files. Per impostazione predefinita, il percorso UNC includerà il nome del server SMB (ad esempio ANF-XXXX)
  • Viene eseguita una query DNS per eseguire il mapping del nome host a un indirizzo IP
  • Viene eseguita una conversazione iniziale SMB2 "Negotiate Protocol"
    • Una richiesta viene inviata dal client per individuare quali dialetti SMB sono supportati dal server e include ciò che il client richiedente supporta
    • Il server risponde con ciò che supporta, tra cui:
      • Modalità di sicurezza (firma o meno)
      • Versione di SMB
      • GUID del server
      • Funzionalità supportate (DFS, leasing, MTU di grandi dimensioni, multicanale, handle permanenti, leasing di directory, crittografia)
      • Dimensioni massime delle transazioni
      • Dimensioni massime lettura/scrittura
      • BLOB di sicurezza (Kerberos o NTLM)
  • Una seconda conversazione SMB2 "Negotiate Protocol" viene eseguita come "preauthorization"/login
    • La richiesta dal client include:
      • Hash di preautenticazione
      • Modalità di sicurezza supportate (firma o meno)
      • Funzionalità supportate (DFS, leasing, MTU di grandi dimensioni, multicanale, handle permanenti, leasing di directory, crittografia)
      • GUID del client
      • Dialetti SMB supportati
    • Se l'hash di preautenticazione viene accettato, il server risponde con:
      • Modalità di sicurezza (firma o meno)
      • Funzionalità supportate (DFS, leasing, MTU di grandi dimensioni, multicanale, handle permanenti, leasing di directory, crittografia)
      • Dimensioni massime delle transazioni
      • Dimensioni massime lettura/scrittura
      • BLOB di sicurezza (Kerberos o NTLM)
      • Funzionalità di preautenticazione e crittografia SMB
  • Se la negoziazione del protocollo ha esito positivo, viene effettuata una richiesta di configurazione della sessione .
    • Il programma di installazione usa l'hash di preautenticazione proveniente dalla negoziazione del protocollo.
    • Il programma di installazione informa il server SMB in merito a ciò che il client richiedente supporta, tra cui:
      • StructureSize
      • Flag di binding della sessione
      • Modalità di sicurezza (firma abilitata/richiesta)
      • Capabilities
      • Tipi di crittografia Kerberos supportati
  • Viene inviata una risposta "Configurazione sessione".
    • Vengono concessi crediti SMB.
    • Viene stabilito l'ID sessione.
    • I flag di sessione sono impostati (guest, null, encrypt).
    • Il tipo di crittografia Kerberos è definito.
  • Una richiesta di connessione ad albero viene inviata dal client per la connessione alla condivisione SMB.
    • I flag o le funzionalità di condivisione vengono inviati dal server, insieme alle autorizzazioni di condivisione.
  • Il comando ioctlFSCTL_QUERY_NETWORK_INTERFACE_INFO viene inviato per ottenere l'indirizzo IP del server SMB.
  • Il server SMB in Azure NetApp Files restituisce i report con le informazioni di rete, tra cui: * Indirizzo IP * Funzionalità di interfaccia (RSS attivato o disattivato) * Numero di code RSS * Velocità di collegamento
  • Una richiesta di connessione ad albero viene inviata dal client per la connessione alla condivisione amministrativa IPC$.
    • La condivisione IPC$ è una risorsa che condivide le named pipe essenziali per la comunicazione tra programmi. La condivisione IPC$ viene usata durante l'amministrazione remota di un computer e quando si visualizzano le risorse condivise di un computer. Non è possibile modificare le impostazioni di condivisione, condividere le proprietà o gli ACL della condivisione IPC$. Non è anche possibile rinominare o eliminare la condivisione IPC$.
  • Un binding DCERPC viene eseguito al file srvsvc per stabilire una connessione sicura.
    • Il file viene scritto utilizzando le informazioni recuperate in precedenza.
  • Un TGS-REQ Kerberos viene rilasciato dal client Windows al KDC per ottenere un ticket di servizio (ST) per il servizio SMB.
  • Un comando NetShareGetInfo viene eseguito dal client SMB al server e viene inviata una risposta.
  • Il ticket di servizio SMB viene recuperato dal KDC.
  • Azure NetApp Files tenta di eseguire il mapping dell'utente Windows che richiede l'accesso alla condivisione a un utente UNIX valido.
    • Viene effettuata una richiesta Kerberos TGS usando le credenziali Kerberos del server SMB archiviate con il keytab del server SMB dalla creazione iniziale del server SMB da usare per un'associazione server LDAP.
    • In LDAP viene cercato un utente UNIX mappato all'utente SMB che richiede l'accesso alla condivisione. Se non esiste alcun utente UNIX in LDAP, l'utente pcuser UNIX predefinito viene usato da Azure NetApp Files per il mapping dei nomi (file/cartelle scritti in volumi a doppio protocollo usano l'utente UNIX mappato come proprietario UNIX).
  • Viene eseguita un'altra perazione negotiate protocol/session request/tree connect, questa volta usando il nome SPN Kerberos del server SMB alla condivisione IPC$ del controller di dominio Active Directory.
    • Viene stabilita una named pipe alla condivisione tramite srvsvc.
    • Viene stabilita una sessione NETLOGON per la condivisione e l'utente di Windows viene autenticato.
  • Se le autorizzazioni lo consentono per l'utente, la condivisione elenca i file e le cartelle contenuti nel volume.

Note

Azure NetApp Files aggiunge voci alla cache del contesto Kerberos per il client. Queste voci risiedono nella cache per tutta la durata del ticket Kerberos (impostata dal KDC e controllata dai criteri Kerberos.

Creazione di alias server SMB

Quando Azure NetApp Files crea un server SMB usando una convenzione di denominazione [prefisso del server SMB specificato nella configurazione della connessione AD]-[identificatore numerico univoco]. (Per informazioni dettagliate sull'identificatore numerico univoco, vedere Account computer Kerberos SMB). Questa formattazione indica che i nomi dei server SMB non vengono costruiti in modo intuitivo. Ad esempio, un nome "SMB-7806" è più difficile da ricordare rispetto a qualcosa di simile ad "AZURE-FILESHARE".

A causa di questo comportamento, gli amministratori possono voler creare nomi di alias descrittivi per i volumi di Azure NetApp Files. In questo modo è necessario puntare un nome canonico DNS (CNAME) al record A/AAAA DNS esistente nel server.

Quando viene creato e usato un CNAME nelle richieste di percorso UNC (ad esempio, \\AZURE-FILESHARE anziché \\SMB-7806), DNS reindirizza la richiesta CNAME (AZURE-FILESHARE.contoso.com) al record A/AAAA appropriato (SMB-7806.contoso.com), usato nel recupero di SPN Kerberos (cifs/SMB-7806). Ciò consente l'accesso Kerberos alla condivisione SMB durante l'uso del nome con alias.

Se viene creato un record DNS A/AAAA (ad esempio, AZURE-FILESHARE.contoso.com) e si è tentato di usare come alias, le richieste Kerberos hanno esito negativo. L'errore è il risultato del nome SPN costruito usato per eseguire l'autenticazione alla condivisione (cifs/AZURE-FILESHARE) che non corrisponde al nome SPN Kerberos per il server SMB (cifs/SMB-7806). L'errore può essere risolto se un altro SPN viene creato e aggiunto all'account del computer server SMB, ad esempio cifs/AZURE-FILESHARE.

Funzionalità del server SMB supportate in Azure NetApp Files

Quando viene effettuata la richiesta SMB "negotiate protocol", viene eseguita una query sul server SMB di Azure NetApp Files per il supporto di funzionalità specifiche. La tabella seguente illustra le funzionalità sottoposte a query e la risposta restituita da un volume SMB di Azure NetApp Files quando viene eseguita una connessione di installazione/albero della sessione.

Funzionalità SMB Supportato da Azure NetApp Files?
Destinazione DFS Sì
Locazione finanziaria (Leasing) Sì
MTU di grandi dimensioni Sì
SMB multicanale Sì
Handle permanenti SMB Sì
Leasing di directory NO
Crittografia SMB Sì (se abilitata)

Funzionalità e proprietà di condivisione SMB supportate in Azure NetApp Files

Durante l'accesso alla condivisione SMB, viene eseguita una richiesta di connessione ad albero e il client interroga il server Azure NetApp Files per le funzionalità e le proprietà della condivisione SMB supportate. La tabella seguente illustra le funzionalità di condivisione sottoposte a query e la risposta restituita da un volume SMB di Azure NetApp Files, come illustrato in un'acquisizione pacchetti.

Funzionalità di condivisione SMB Supportato da Azure NetApp Files?
Disponibilità continua (CA) Sì, per carichi di lavoro specifici* (se abilitato)
Scaleout NO
Cluster NO
Asimmetrica NO
Reindirizzamento al proprietario NO

* Per i carichi di lavoro supportati, vedere Abilitare la disponibilità continua nei volumi SMB esistenti.

Nella tabella seguente vengono visualizzate le proprietà di condivisione sottoposte a query e la risposta restituita da un volume SMB di Azure NetApp Files.

Funzionalità di condivisione SMB Supportato da Azure NetApp Files?
Destinazione DFS Sì
Radice DFS NO
Limita apertura esclusiva NO
Eliminazione condivisa forzata NO
Consenti memorizzazione nella cache dello spazio dei nomi NO
Enumerazione basata sull'accesso Sì (se abilitata)
Forzare blocco opportunistico di livello II NO
Abilitare hash V1 NO
Abilitare hash v2 NO
Crittografia richiesta Sì (se abilitata)
Remoting di identità NO
I/O compresso NO
Trasporto isolato NO

Funzionamento di Kerberos NFS in Azure NetApp Files

Kerberos NFS funziona separatamente dai servizi SMB, perché gli account computer creati per ogni protocollo non possono condividere i keytab a causa del potenziale di modifiche apportate al numero di versione chiave (kvno) in un keytab che influisce sull'altro servizio. Di conseguenza, i flussi di lavoro per i servizi SMB per Kerberos e NFS per Kerberos differiscono in alcune aree.

Configurazione iniziale dell'area di autenticazione Kerberos

L'area di autenticazione Kerberos NFS viene configurata quando le informazioni sull'area di autenticazione Kerberos vengono compilate nel portale di Azure NetApp Files nella pagina Connessioni di Active Directory.

Screenshot della configurazione dell'area di autenticazione Kerberos.

Il nome del server AD e l'IP KDC vengono usati per connettersi ai servizi di AD KDC durante la creazione dell'account macchina iniziale.

Note

I campi KDC IP e AD Server Name nell'oggetto Active Directory non possono essere cancellati finché l'oggetto Active Directory non viene eliminato. Può essere modificato solo in un valore non vuoto valido.

Il servizio Azure NetApp Files sfrutta le informazioni di dominio esistenti per compilare il resto della configurazione dell'area di autenticazione. Ad esempio:

Kerberos Realm: CONTOSO.COM
KDC Vendor: Microsoft
KDC IP Address: x.x.x.x 
KDC Port: 88
Clock Skew: 5
Active Directory Server Name: dc1.contoso.com
Active Directory Server IP Address: x.x.x.x
Comment: -
Admin Server IP Address: x.x.x.x
Admin Server Port: 749
Password Server IP Address: x.x.x.x
Password Server Port: 464
Permitted Encryption Types: aes-256
-    Configured by Azure NetApp Files administrator in the portal
-    Automatically configured by the service using Active Directory connection information/system defaults

Quando l'area di autenticazione Kerberos NFS è configurata, viene aggiunta una voce host locale nel servizio con il KDC specificato nella configurazione. Quando l'area di autenticazione viene modificata, anche la voce host locale viene modificata nel servizio.

Diagramma della configurazione dell'area di autenticazione Kerberos.

Questa voce host locale funge da "ultima risorsa" nel caso in cui dovesse verificarsi un'interruzione KDC nel KDC specificato nella configurazione dell'area di autenticazione e non fosse possibile eseguire query sui KDC ridondanti tramite DNS.

Note

Se il KDC nell'area autenticazione Kerberos deve essere disattivato per manutenzione (ad esempio per aggiornamenti o dismissione di un server), è consigliabile configurare l'area autenticazione in modo che utilizzi un KDC non in manutenzione, per evitare interruzioni del servizio.

Creazione iniziale dell'account computer/SPN

Quando Kerberos è abilitato in un volume di Azure NetApp Files, viene creato un account computer o un'entità denominata NFS-{SMB-server-name} nel dominio nell'unità organizzativa specificata nelle connessioni di Active Directory (Unità organizzativa). I nomi degli account del computer vengono troncati dopo 15 caratteri.

Note

Quando si aggiungono client Linux con nomi host maggiori di 15 caratteri a un dominio di Active Directory, i nomi SPN dell'account computer Kerberos vengono troncati. Ad esempio, un client Linux con un nome di MORE-THAN-FIFTEEN ha un nome di account computer di MORE-THAN-FIFT$, che diventa un NOME SPN di MORE-THAN-FIFT$@CONTOSO.COM. Quando DNS cerca un nome host client, trova il nome più lungo e tenta di usare tale nome in una richiesta SPN ( MORE-THAN-FIFTEEN@CONTOSO.COM). Poiché tale SPN non esiste, il client tenta di usare il SPN successivo nella keytab nella richiesta (in genere host/nome host). Solo i nomi dell'account computer SPN funzionano in modo nativo con Kerberos NFS di Azure NetApp Files. Di conseguenza, assicurarsi che i nomi host client Linux usati per Kerberos NFS con Azure NetApp Files non superino i 15 caratteri. In alternativa, se si vuole usare il nome host/nome host SPN, configurare un utente UNIX in LDAP con il nome utente "host". Questa configurazione fornisce un mapping dei nomi krb-unix per il nome SPN.

In Azure NetApp Files, i keyblocks Kerberos (o le voci keytab) vengono aggiunti al servizio con il SPN del servizio NFS (nfs/nfs-server-name.contoso.com@CONTOSO.COM). Vengono create più voci: una per ogni tipo di crittografia supportato. In Azure NetApp Files è supportato solo il tipo di crittografia AES-256 per Kerberos NFS.

Nella maggior parte dei casi, conoscere questi passaggi in modo approfondito non sarà necessario per le attività di amministrazione quotidiane, ma è utile per la risoluzione degli errori durante il tentativo di creare un volume Kerberos NFS in Azure NetApp Files.

Flusso di lavoro di creazione SPN Kerberos NFS

Il diagramma seguente illustra come viene creato un nome SPN NFS quando viene creato un volume NFS di Azure NetApp Files o a doppio protocollo con Kerberos abilitato. Nella maggior parte dei casi, conoscere i passaggi dettagliati non sarà necessario per le attività di amministrazione quotidiane, ma è utile per risolvere eventuali errori quando si tenta di creare un volume SMB in Azure NetApp Files.

Diagramma del flusso di lavoro di creazione SPN Kerberos NFS.

Per i passaggi dettagliati su come viene creato un nome SPN Kerberos NFS con Azure NetApp Files, espandere l'elenco.
  • Credenziali di amministratore passate al KDC specificato nella configurazione dell'area di autenticazione usando il nome utente fornito per l'uso nella connessione Active Directory. L'utente deve disporre dell'autorizzazione per visualizzare/creare oggetti nell'unità organizzativa specificata.
  • I server DNS specificati nella configurazione della connessione di Active Directory di Azure NetApp Files vengono sottoposti a query da Azure NetApp Files per i record del servizio Kerberos (SRV) nei formati seguenti:
    • Query URI per _kerberos.CONTOSO.COM
    • Query SRV per _kerberos-master._udp. CONTOSO.COM
    • Query SRV per _kerberos-master._tcp. CONTOSO.COM

Note

Queste query vengono eseguite più volte nella stessa chiamata su parti diverse del processo. I problemi DNS possono creare lentezza in queste chiamate o errori totali. Questi record non sembrano esistere per impostazione predefinita nelle distribuzioni di Active Directory e devono essere creati manualmente.

  • Se le query non riescono a trovare una voce o se le voci trovate non possono essere contattate o usate come KDC master, una query record A che usa il nome dell'area di autenticazione trovata nella configurazione dell'area di autenticazione Kerberos NFS viene usata come ultima risorsa per connettersi al KDC sulla porta 88.
  • Durante la configurazione di Kerberos NFS, viene aggiunta una voce host statica per il KDC specificato al file host locale come backup se le ricerche DNS hanno esito negativo.
  • Se è presente una voce DNS memorizzata nella cache per l'area di autenticazione, viene usata. In caso contrario, viene usata la voce del file locale. Le voci DNS memorizzate nella cache sono attive fino a quando la durata (TTL) è configurata per il record DNS. La voce del file locale è configurata con un TTL di 86.400 secondi (24 ore). La configurazione ns-switch per le ricerche host in Azure NetApp Files usa prima i file e quindi DNS. Quando la voce locale viene trovata, non vengono eseguite ulteriori query.
  • L'account computer SMB creato quando viene creata la connessione Active Directory viene usato come credenziali per un'associazione LDAP di Active Directory usando SASL/GSS sulla porta 389 per cercare eventuali voci esistenti del nome dell'account dell'SPN o del computer desiderato. Se il nome dell'account SPN o del computer esiste già, viene inviato un errore. Se il nome SPN non esiste nella query LDAP, la creazione dell'account computer viene eseguita nell'unità organizzativa designata con voci per gli attributi seguenti impostati da Azure NetApp Files:
    • cn (NFS-MACHINE)
    • sAMAccountName (NFS-MACHINE$)
    • objectClass (top, person, organizationalPerson, user, computer)
    • servicePrincipalName (host/NFS-MACHINE, host/NFS-MACHINE.CONTOSO.COM, nfs/NFS-MACHINE, nfs/NFS-MACHINE.CONTOSO.COM)
    • userAccountControl (4096)
    • msDs-SupportedEncryptionTypes (AES-256_CTS_HMAC_SHA1_96)
    • dnsHostName (NFS-MACHINE.CONTOSO.COM)
  • La password dell'account computer Kerberos NFS è impostata per l'account NFS-MACHINE sulla porta 464.
  • I keyblock Kerberos (keytab) per il nome SPN NFS vengono salvati nel servizio Azure NetApp Files.
  • Viene creata una regola di mapping dei nomi statici nel servizio Azure NetApp Files per assicurarsi che l'utente radice per ogni client Kerberos NFS venga mappato alla radice quando viene usato Kerberos.
  • Un file krb5.conf viene aggiunto ai sistemi interni del servizio con le informazioni sull'area di autenticazione NFS.

Montaggi Kerberos NFS

Quando un volume di Azure NetApp Files viene montato usando le versioni di sicurezza Kerberos su NFS, viene eseguito il flusso di lavoro seguente. Per una descrizione più dettagliata di Kerberos, vedere Sommario: Servizio di autenticazione Network Kerberos (V5).

Diagramma del flusso di lavoro di montaggio Kerberos NFS.

Per i passaggi dettagliati su come viene montato un volume Kerberos NFS con Azure NetApp Files, espandere l'elenco.
  • Il client tenta un montaggio in un percorso di esportazione NFS in Azure NetApp Files e specifica la versione di sicurezza -okrb5 (o krb5i o krb5p).
  • IL DNS viene usato per formulare una richiesta per un'entità servizio NFS in Azure NetApp Files tramite record A/AAAA o PTR (a seconda di come sia stato eseguito il comando di montaggio).
  • Il client recupera un TGT dal KDC tramite una chiamata AS-REQ usando il nome dell'entità CLIENT presente nella keytab del client.
  • Il percorso di esportazione viene controllato per assicurarsi che esista nel file system.
  • La regola dei criteri di esportazione viene controllata per assicurarsi che l'accesso Kerberos sia consentito al percorso di esportazione.<
  • Il ticket di servizio NFS viene richiesto dal KDC dal client tramite una chiamata AP-REQ. Azure NetApp Files verifica la presenza di una voce valida con un tipo di crittografia valido usando il TGT dal client acquisito dal KDC.
  • Se il TGT è valido, viene emesso un ticket di servizio.
  • Il nome SPN client (ad esempio, CLIENT$@CONTOSO.COM) viene mappato all'utente radice tramite la regola di mapping dei nomi in Azure NetApp Files.
  • L'utente radice viene sottoposto a query nei database dei servizi dei nomi (file e LDAP) per l'esistenza o l'appartenenza a gruppi.
  • Viene eseguita un'associazione LDAP usando l'account del computer del server SMB per consentire una ricerca LDAP per l'utente ROOT.
  • Poiché la radice esiste sempre in Azure NetApp Files, questo non dovrebbe causare problemi, ma le query LDAP per la radice potrebbero non riuscire. Questi errori possono essere ignorati.
  • Il ticket di servizio NFS viene restituito al client e il montaggio ha esito positivo. L'utente ROOT ha accesso radice al montaggio Kerberos tramite l'entità account computer del client (visualizzabile dal client tramite il comando klist -e).
  • Azure NetApp Files aggiunge voci alla cache del contesto Kerberos per il client. Queste voci si troveranno nella cache per tutta la durata del ticket Kerberos impostato dal KDC e controllato dai criteri Kerberos.
  • NFSv4.1 invia periodicamente (ogni 20 secondi) gli aggiornamenti di un ticket Kerberos come "keepalives".

Accesso di montaggio Kerberos NFS con entità utente

Quando si accede a un montaggio Kerberos NFS di Azure NetApp Files da un utente (diverso dall'utente radice, che usa il nome SPN dell'account computer), viene eseguito il flusso di lavoro seguente.

Diagramma dell'accesso di montaggio Kerberos NFS con entità utente.

Per i passaggi dettagliati su come si accede a un volume Kerberos NFS con un utente non radice con Azure NetApp Files, espandere l'elenco.
  • L'utente accede al KDC con uno scambio di nome utente/password o tramite un file keytab per ottenere un TGT tramite una chiamata AS-REQ da usare per la raccolta di un ticket di servizio dal volume di Azure NetApp Files.
  • La regola dei criteri di esportazione viene controllata per assicurarsi che l'accesso Kerberos sia consentito al percorso di esportazione per il computer client
  • Azure NetApp Files verifica la presenza di un ticket di servizio NFS memorizzato nella cache. Se non ne esiste alcuno, il ticket di servizio NFS viene richiesto tramite una chiamata AP-REQ e il servizio controlla la presenza di una voce valida con un tipo di crittografia valido usando il TGT dal client acquisito dal KDC.
  • Se il TGT è valido, viene emesso un ticket di servizio
  • Viene eseguito il mapping del nome dell'entità utente (UPN) dell'utente tramite mapping implicito. Ad esempio, se l'UPN è user1@CONTOSO.COM, il servizio esegue una query per un utente UNIX denominato user1. Poiché l'utente UNIX non esiste nel database dei file locali in Azure NetApp Files, viene usato LDAP.
  • Viene eseguito un tentativo di associazione LDAP tramite l'account del computer del server SMB per consentire una ricerca LDAP per l'utente mappato. Viene eseguita una query DNS SRV per i record DNS Kerberos (_kerberos e _kerberos-master). Se non è possibile usare record validi, la configurazione esegue il fallback alla configurazione dell'area di autenticazione. Queste query SRV DNS KDC non sono associate a un ambito di sito.
  • I record SRV LDAP vengono sottoposti a query per i server LDAP validi. Queste sono associate a un ambito di sito.
  • Se l'utente non esiste in LDAP o LDAP non può essere sottoposto a query (il server è inattivo, la ricerca DNS ha esito negativo, l'associazione ha esito negativo, si verifica il timeout della ricerca LDAP, l'utente non esiste) il mapping ha esito negativo e l'accesso viene negato.
  • Se l'utente esiste, vengono raccolte le appartenenze a gruppi.
  • Il mapping ha esito positivo e viene emesso un ticket di servizio NFS al client (visto nei comandi klist -e). L'accesso è consentito in base alle autorizzazioni per i file nel percorso di esportazione.

Ruolo di LDAP con Kerberos in Azure NetApp Files

Azure NetApp Files si basa su LDAP per Kerberos NFS. Kerberos NFS in Azure NetApp Files richiede Kerberos per i mapping dei nomi UNIX per gli SPN utente in ingresso. Poiché Azure NetApp Files non supporta la creazione di utenti UNIX locali, LDAP è necessario per eseguire ricerche per gli utenti UNIX quando viene richiesto un mapping dei nomi.

  • Quando viene creata una connessione Active Directory, viene usato il nome di dominio di Active Directory per specificare il processo di ricerca dei server LDAP.
  • Quando è necessario un server LDAP, _ldap.domain.com viene usato per la ricerca SRV per i server LDAP.
  • Dopo aver individuato un elenco di server, il server migliore disponibile (in base al tempo di risposta ping) viene usato come server LDAP per la connessione sulla porta 389.
  • Viene tentata un'associazione LDAP usando l'account del computer SMB tramite GSS/Kerberos.
  • Se non sono presenti connessioni memorizzate nella cache o credenziali Kerberos, viene emessa una nuova richiesta per un ticket Kerberos. Le connessioni memorizzate nella cache per i server dei nomi in Azure NetApp Files sono attive per 60 secondi. In caso di inattività per più di 60 secondi, la cache di connessione viene cancellata.
  • Il DNS viene usato per trovare i KDC Kerberos appropriati tramite record SRV.
  • Se non è possibile trovare KDC tramite query DNS, viene usato il KDC specificato nel file krb5.conf per i servizi SMB.
    • Se il KDC non è raggiungibile o non è in grado di elaborare la richiesta Kerberos, l'associazione LDAP ha esito negativo. Anche la ricerca del nome ha esito negativo. L'accesso viene negato al montaggio perché non è stata eseguita alcuna autenticazione valida.
    • Se l'associazione ha esito positivo, viene eseguita una query LDAP per l'utente e le relative credenziali. Se il tempo di ricerca supera i 10 secondi, la ricerca non riesce.
  • Se la ricerca trova l'utente, il mapping ha esito positivo e l'accesso viene concesso tramite Kerberos (purché il ticket sia valido/non sia scaduto).

Indirizzi IP per l'accesso con Kerberos

Per impostazione predefinita, l'autenticazione Kerberos sfrutta la risoluzione hostname-to-IP-address per formulare il nome dell'entità servizio (SPN) usato per recuperare il ticket Kerberos. Ad esempio, quando si accede a una condivisione SMB con un percorso UNC (Universal Naming Convention), ad esempio \SMBVOLUME.CONTOSO.COM, viene eseguita una richiesta DNS per il nome di dominio completo SMBVOLUME.CONTOSO.COM e viene recuperato l'indirizzo IP del volume di Azure NetApp Files. Se non è presente alcuna voce DNS (o la voce presente è diversa da quella richiesta, ad esempio con alias/CNAMEs), non è possibile recuperare un nome SPN appropriato e la richiesta Kerberos non riesce. Di conseguenza, l'accesso al volume potrebbe non essere consentito se il metodo di autenticazione di fallback (come New Technology LAN Manager) è disabilitato.

Le voci DNS in Azure NetApp Files vengono create automaticamente tramite DNS dinamico e vengono formulate usando il nome del server SMB. Per eventuali varianti/alias al nome definito, è necessario creare un record CNAME DNS manuale e puntare alla voce DNS dinamica. Per altre informazioni, vedere Informazioni su DNS in Azure NetApp Files.

NFSv4.1 Kerberos funziona in modo analogo per il recupero di SPN, in cui le ricerche DNS sono integrate nel processo di autenticazione e possono essere usate anche per l'individuazione dell'area di autenticazione Kerberos.

Se un indirizzo IP (anziché un nome host) viene usato in una richiesta di accesso a un volume di Azure NetApp Files, una richiesta Kerberos funzionerà in modo diverso a seconda del protocollo in uso.

Comportamento Kerberos SMB con indirizzi IP e nomi DNS

Quando si usa SMB, una richiesta per un percorso UNC usando un indirizzo IP (ad esempio, \\x.x.x.x) per impostazione predefinita tenta di usare NTLM per l'autenticazione. Negli ambienti in cui NTLM non è consentito per motivi di sicurezza, una richiesta SMB che usa un indirizzo IP non è in grado di usare Kerberos o NTLM per l'autenticazione per impostazione predefinita. Di conseguenza, l'accesso al volume di Azure NetApp Files viene negato. Nelle versioni successive di Windows (a partire da Windows 10 versione 1507 e Windows Server 2016), i client Kerberos possono essere configurati per supportare i nomi host IPv4 e IPv6 negli SPN per le comunicazioni SMB per risolvere questo problema.

Comportamento Kerberos NFSv4.1 con indirizzi IP e nomi DNS

Quando si usa NFSv4.1, una richiesta di montaggio a un indirizzo IP che usa una delle opzioni di sec=[krb5/krb5i/krb5p] usa ricerche DNS inverse tramite PTR per risolvere un indirizzo IP in un nome host. Tale nome host viene quindi usato per formulare il nome SPN per il recupero del ticket Kerberos. Se si usa NFSv4.1 con Kerberos, è necessario disporre di A/AAAA e PTR per il volume di Azure NetApp Files per coprire sia il nome host che l'accesso agli indirizzi IP ai montaggi. Azure NetApp Files crea un record DNS dinamico A/AAAA. Se esiste una zona DNS inversa per tale subnet, viene creato automaticamente anche un record PTR. Per le deviazioni dalle convenzioni standard dei nomi host di Azure NetApp Files, usare i record CNAME per gli alias DNS.

Per altre informazioni, vedere Informazioni su DNS in Azure NetApp Files

  • Last updated on