Partage via

Comprendre Kerberos dans Azure NetApp Files

  • Article

Kerberos est un protocole d’authentification qui utilise une clé secrète pour valider l’identité des principaux. Les clés secrètes sont générées en prenant le mot de passe d’un principal et en le convertissant en format de clé de chiffrement hachée à l’aide d’une méthode de chiffrement acceptée par le client et le serveur (par exemple, AES). Consultez la section Terminologie Kerberos pour en savoir plus sur les termes utilisés dans ce document.

Les centres de distribution de clés (KDC, Key Distribution Center) tels que Windows Active Directory gèrent une base de données de principaux Kerberos et de leurs mots de passe hachés. Dans Kerberos, la clé secrète est la preuve d’une identité unique. Par conséquent, le KDC peut être approuvé pour authentifier n’importe quel principal auprès d’un autre principal, comme l’authentification d’un nom de principal de service client NFS (SPN) auprès d’un SPN de serveur NFS au montage. Il peut également être approuvé pour authentifier un principal d’utilisateur auprès d’un SPN de serveur NFS pour l’accès utilisateur à un point de montage NAS. Comme mesure de sécurité ajoutée, Kerberos n’envoie pas de mots de passe en texte clair pour l’authentification sur réseau.

Azure NetApp Files prend en charge l’utilisation de Kerberos pour assurer la sécurité à la volée pour les protocoles SMB et NFS.

Types de chiffrement pris en charge

Azure NetApp Files prend en charge NFS Kerberos avec des types de chiffrement spécifiques, en fonction du mode d’exploitation et de la version que vous utilisez.

Pour vous assurer qu’un client utilise le type de chiffrement approprié, vous pouvez limiter les types de chiffrement valides sur le principal d’objet situé sur le KDC (par exemple, le compte d’ordinateur) ou dans le fichier keytab créé manuellement par le client plutôt que globalement dans le fichier /etc/krb5.conf, si possible, car la gestion de nombreux fichiers krb5.conf client peut être un casse-tête en termes de gestion. La gestion centralisée de Kerberos à partir du KDC est plus évolutive dans les grands environnements d’entreprise, est plus facile à automatiser et force le client à utiliser des types de chiffrement plus forts lorsqu’il est pris en charge.

Remarque

Il est recommandé de définir l’option allow_weak_crypto sur false dans le fichier krb5.conf sur les clients. Ce paramètre empêche le paramètre enctypes moins sécurisé pour la communication Kerberos (par exemple, DES ou 3DES).

Le tableau suivant présente les types de chiffrement pris en charge pour Kerberos (SMB et NFS) pour Azure NetApp Files.

Protocol Types de chiffrement pris en charge
SMB
  • RC4-HMAC
  • AES-128
  • AES-256
NFS AES-256

Modes de sécurité NFS Kerberos pris en charge

Outre le concept de types de chiffrement, il existe également des niveaux de contrôle de sécurité et d’intégrité dans Kerberos. Selon le mode de sécurité en cours d’utilisation, ces modes de sécurité permettent d’empêcher les attaques par intercepteur en offrant un chiffrement de bout en bout pour le trafic NFS.

Dans Azure NetApp Files, ces modes de sécurité sont spécifiés sur les règles de stratégie d’exportation définies pour le volume pour NFS et définies pendant le montage NFS initial via l’option de montage sec.

Par exemple : # mount -o sec=krb5p

Remarque

Pour SMB Kerberos, les modes de sécurité pour Kerberos sont contrôlés via les paramètres de chiffrement SMB sur le partage, le renforcement UNC et les stratégies de signature/scellement SMB sur les contrôleurs de domaine.

Les modes de sécurité suivants sont pris en charge par Azure NetApp Files pour une utilisation avec NFS Kerberos :

Mode de sécurité Description
krb5 Chiffrement d’authentification uniquement.

Utilise des chaînes de noms Kerberos V5 et des noms d’utilisateur principaux au lieu des ID d’utilisateurs UNIX locaux (UID) et des ID de groupes (GID) pour authentifier les utilisateurs.
krb5i Chiffrement d’authentification et vérification de l’intégrité chiffrée.

Utilise Kerberos V5 pour l’authentification utilisateur et effectue également la vérification de l’intégrité des opérations NFS à l’aide de sommes de contrôle sécurisées pour empêcher la falsification des données et les attaques par intercepteur.
krb5p Conversation NFS entièrement chiffrée.

Utilise Kerberos V5 pour la vérification de l’authentification et de l’intégrité des utilisateurs, et chiffre tout le trafic NFS pour empêcher le reniflage de paquets. Ce paramètre est le plus sécurisé, mais il crée également la surcharge de performances la plus élevée.

Terminologie Kerberos

Cette section définit la terminologie clé utilisée dans la description des processus Kerberos. Cette section est destinée à clarifier les termes qui peuvent ne pas être familiers aux administrateurs de stockage.

Terme Définition
Centre de distribution de clés (Key Distribution Center, KDC) Le KDC est le serveur d’authentification qui inclut le service d’octroi de tickets (TGS) et le service d’authentification (AS). Les termes KDC, AS et TGS sont utilisés de façon interchangeable. Dans les environnements Microsoft, un contrôleur de domaine Active Directory est un contrôleur de domaine KDC.
Domaine (ou domaine Kerberos) Un domaine (ou domaine Kerberos) peut utiliser n’importe quelle chaîne ASCII. La norme consiste à utiliser le nom de domaine en majuscules ; par exemple, contoso.com devient le domaine CONTOSO.COM. Les domaines Kerberos sont généralement configurés dans les fichiers krb5.conf sur les clients et les serveurs.

Administrativement, chaque principal@REALM doit être unique. Pour éviter un point de défaillance unique, chaque domaine peut avoir plusieurs KDC qui partagent la même base de données (principaux et leurs mots de passe) et ont les mêmes clés principales KDC. Microsoft Windows Active Directory effectue cette opération en mode natif par le biais de la réplication Active Directory, qui a lieu toutes les 15 minutes par défaut.
Principal Le terme « principal » fait référence à chaque entité au sein d’une base de données Kerberos. Les utilisateurs, les ordinateurs et les services sont tous des principaux attribués pour l’authentification Kerberos. Chaque principal doit être unique dans la base de données Kerberos et est défini par son nom unique. Un principal peut être un nom d’utilisateur principal (UPN) ou un nom de principal de service (SPN).

Un nom principal comporte trois parties :
  • Principal : le composant principal peut être un utilisateur ou un service tel que le service NFS. Il peut également s’agir de l'« hôte » de service spécial, ce qui signifie que ce principal de service est configuré pour fournir plusieurs services réseau.
  • Instance : cette partie est facultative dans le cas d’un utilisateur. Un utilisateur peut avoir plusieurs principaux, mais chaque principal doit être unique dans le KDC. Par exemple, Fred peut avoir un principal qui est destiné à une utilisation quotidienne (fred@contoso.com) et un principal qui autorise une utilisation privilégiée telle qu’un compte sysadmin (admin-fred@contoso.com). L’instance est requise pour les principaux de service et désigne le nom de domaine complet (Fully Qualified Domain Name, FQDN) de l’hôte qui fournit le service.
  • Domaine : un domaine Kerberos est l’ensemble de principaux Kerberos inscrits dans un serveur Kerberos. Par convention, le nom du domaine est généralement identique au nom DNS, mais il est converti en lettres majuscules. Les lettres majuscules ne sont pas obligatoires, mais la convention fournit une distinction facile entre le nom DNS et le nom du domaine.
Tickets Un ticket est un ensemble temporaire d’informations d’identification qui vérifie l’identité d’un principal pour un service et contient la clé de session. Un ticket peut être un service, un ticket d’application ou un ticket d’octroi de ticket (Ticket-Granting Ticket, TGT). Les tickets sont échangés entre le client, le serveur et le KDC pour l’authentification Kerberos.
Clés secrètes Kerberos utilise un système de clés symétriques dans lequel la clé secrète est utilisée pour le chiffrement et le déchiffrement. La clé secrète est générée à partir du mot de passe Kerberos du principal avec une fonction de hachage unidirectionnel. Le KDC stocke le mot de passe de chaque principal et peut ainsi générer la clé secrète du principal. Pour les utilisateurs qui demandent un service Kerberos, la clé secrète est généralement dérivée d’un mot de passe présenté au programme kinit. Les principaux de service et de démon n’utilisent généralement pas de mot de passe. Au lieu de cela, le résultat de la fonction de hachage unidirectionnel est stocké dans un keytab.
Keytab Un keytab contient une liste de principaux et de leurs clés secrètes. Les clés secrètes d’un keytab sont souvent créées à l’aide d’un mot de passe aléatoire et sont utilisées principalement pour les principaux de service ou de démon.

Informations sur les ports réseau

Le tableau suivant couvre les ports réseau utilisés pour les communications Kerberos. Si un pare-feu réseau est en place, ces ports doivent être ouverts pour autoriser les fonctionnalités Kerberos appropriées. Vous trouverez plus d’informations sur ces ports dans le registre des numéros de port du service IANA et du protocole de transport.

Service Port
Kerberos 88 (TCP/UDP)
kpasswd 464 (TCP/UDP)
Protocole LDAP (Lightweight Directory Access Protocol) (pour les mappages de noms) 389 (TCP/UDP)
Serveur d’administration 749 (TCP/UDP)
Catalogue global (recherches utilisateur Windows) 3268 (TCP/UDP)

Valeurs d’âge du cache dans Azure NetApp Files

Le tableau suivant affiche la durée de vie d’une entrée de cache dans un volume Azure NetApp Files.

Cache Âge du cache
Connexions au serveur de noms inactives 60 secondes
Expiration du délai d'attente de requête LDAP 10 secondes
Durée de vie de l’entrée d’hôte DNS local pour KDC 24 heures
Âge du ticket Kerberos Spécifié par KDC* et/ou le client

* La valeur par défaut est de 10 heures pour les KDC Windows Active Directory
Informations d’identification de l’utilisateur 24 heures
Asymétrie du temps Kerberos 5 minutes

Configuration requise pour les environnements Kerberos fonctionnant dans Azure NetApp Files

L’authentification Kerberos dépend fortement des services externes pour des fonctionnalités appropriées. Dans Microsoft Active Directory, la plupart de ces services sont combinés en un seul serveur dans de nombreux cas. Par exemple, un contrôleur de domaine Active Directory peut traiter les dépendances Kerberos suivantes :

  • Services de synchronisation de l’heure
  • DNS
  • Distribution de clés Kerberos
  • Services de mot de passe/authentification unique
  • Services d’identité (tels que LDAP)

Lorsque vous utilisez Microsoft Active Directory natif (le seul type de contrôleur de domaine clé pris en charge actuellement par Azure NetApp Files), la plupart des dépendances externes pour Kerberos dans Azure NetApp Files sont couvertes, telles que DNS, KDC et les services de mot de passe. Dans certains cas, les services requis peuvent être hébergés en dehors du domaine Active Directory (par exemple, DNS). Dans ce cas, il est important de s’assurer que les services requis sont configurés correctement.

Azure NetApp Files a des dépendances spécifiques pour le bon fonctionnement de NFS Kerberos. Poursuivez la lecture pour plus d’informations.

Services de synchronisation de l’heure

Les services de synchronisation de l’heure sont obligatoires lors de l’utilisation de Kerberos pour l’authentification, car les mécanismes de ticket Kerberos nécessitent que les décalages entre le client et le serveur se trouvent dans une plage de 5 minutes par défaut. Si les paramètres d’heure sur le client ou le serveur dépassent cette plage de cinq minutes, l’authentification Kerberos échoue avec une erreur d’asymétrie temporelle (KRB_AP_ERR_SKEW) et l’accès au partage NAS est refusé. L’expiration du délai d’attente est une fonctionnalité de sécurité qui permet d’empêcher les « attaques par rejeu », où un attaquant peut intercepter les messages entre le KDC et le client, puis rejouer ces messages ultérieurement pour usurper l’identité d’un utilisateur authentifié. Les limites d’asymétrie temporelle permettent de réduire le risque de ces types d’attaques.

Considérations clés relatives aux problèmes de synchronisation temporelle :

Pour plus d’informations, consultez Tolérance maximale de synchronisation de l’horloge de l’ordinateur.

Systèmes de noms de domaine (DNS)

Les systèmes DNS (Domain Name Systems) sont obligatoires pour Kerberos en tant que fonctionnalité de sécurité. La résolution de nom d’hôte est utilisée pour formuler les principaux de service Kerberos utilisés pour l’authentification. Dans ce processus, les recherches directes des noms d’hôte (enregistrements A/AAAA) sont utilisées pour se connecter à des partages qui tirent parti de l’authentification Kerberos. Cette recherche directe est ensuite utilisée pour formuler le nom du principal de service (SPN) utilisé dans la requête d’authentification Kerberos. Si un SPN existant n’est pas trouvé dans le KDC, l’authentification Kerberos échoue.

Dans les environnements Windows SMB, une méthode d’authentification alternative peut être tentée (par exemple, NTLM). Toutefois, dans de nombreux cas, NTLM est désactivé pour des raisons de sécurité, ce qui entraînerait un échec d’accès au partage lorsque l’authentification Kerberos échoue. L’observateur d’événements Windows enregistre souvent la cause racine des défaillances (par exemple, des SPN dupliqués/manquants, des échecs de recherche DNS, des échecs NTLM, etc.).

En plus de la résolution SPN, DNS est fortement utilisé pour résoudre les noms d’hôte et les adresses IP pour les services de domaine, tels que LDAP, les KDC Kerberos, etc. via des enregistrements SRV. Pour plus d’informations sur DNS dans Azure NetApp Files (y compris les enregistrements SRV requis), consultez À propos de DNS dans Azure NetApp Files.

Remarque

Si une adresse IP est utilisée pour l’accès Kerberos, le comportement dépend du protocole NAS (NFS ou SMB) utilisé. Pour plus d’informations, consultez Adresses IP pour l’accès avec Kerberos.

LDAP

Le protocole LDAP (Lightweight Directory Access Protocol) tire parti des bases de données d’identité principale pour fournir une source de service de nom unifiée pour les clients et les serveurs NAS afin que tous les appareils participant s’accordent sur l’authenticité des utilisateurs, les appartenances aux groupes et les ID numériques, qui sont ensuite utilisés pour les autorisations de fichier.

Pour Kerberos, les principaux d’utilisateur et de service sont stockés avec les entrées dans les bases de données LDAP en tant qu’attributs sur les comptes principaux. Windows Active Directory prend en charge cela par défaut. Dans certains cas (par exemple, lors de la création d’alias ou de principaux de service), les utilisateurs et les ordinateurs nécessitent l’ajout ou la modification des noms de principaux de service. Vous pouvez satisfaire cette exigence à l’aide de la console MMC (Microsoft Management Console) Utilisateurs et ordinateurs Active Directory ou de PowerShell. Pour plus d’informations sur la gestion des noms de principaux de service, consultez Gestion des noms de principaux de service.

Outre les noms de principal de service et les ID numériques pour l’authentification Kerberos, LDAP peut également être utilisé pour les identités d’utilisateur et de groupe UNIX, qui sont utilisées pour le mappage de noms d’identités dans Azure NetApp Files, ainsi que l’authentification initiale pour les montages Kerberos NFS via un mappage de noms d’utilisateur UNIX -> SPN. Pour plus d’informations, consultez Fonctionnement de NFS Kerberos dans Azure NetApp Files et Rôle de LDAP avec Kerberos dans Azure NetApp Files.

Fonctionnement de SMB Kerberos dans Azure NetApp Files

SMB Kerberos fonctionne séparément des services NFS Kerberos, car les comptes d’ordinateur créés pour chaque protocole ne peuvent pas partager des clés en raison du risque de modifications apportées au numéro de version de clé (kvno) dans un keytab impactant l’autre service. Par conséquent, de même que les différences naturelles dans les protocoles NAS, les flux de travail pour les services SMB pour Kerberos et NFS pour Kerberos diffèrent dans certaines fonctionnalités.

Configuration initiale des services SMB

Les services SMB dans Azure NetApp Files sont initialement configurés en configurant une connexion Active Directory, qui définit plusieurs éléments critiques pour l’interaction avec les services de domaine, notamment :

  • Serveur DNS principal (obligatoire)
  • DNS secondaire
  • Nom DNS Active Directory*
  • Nom du site Active Directory (pour la découverte du contrôleur de domaine) (obligatoire)
  • Nom du préfixe du serveur SMB
  • Unité organisationnelle (où les comptes de machine doivent être stockés dans le domaine Azure AD)
  • Activation/désactivation du chiffrement AES
  • Activation/désactivation de la signature LDAP
  • Configuration LDAP
  • Chiffrement SMB vers DC
  • Utilisateurs disposant de privilèges
  • Informations d’identification (nom d’utilisateur/mot de passe) de l’utilisateur disposant d’autorisations d’unité d’organisation

Remarque

Une seule connexion Azure Active Directory (AD) est autorisée par compte. Une fois la connexion Azure AD créée, tout nouveau volume SMB Azure NetApp Files utilise la configuration de la connexion Azure AD.

Compte d’ordinateur SMB Kerberos

Un compte d’ordinateur dans Active Directory contient des informations pertinentes pour une utilisation dans les requêtes d’authentification, y compris le nom du principal de service (SPN). Lorsque vous créez un volume SMB dans Azure NetApp Files, la configuration des connexions Active Directory est utilisée pour l’interaction dans la création d’un compte d’ordinateur pour fournir un accès sécurisé à un partage SMB via une authentification Kerberos (ou NTLM, si activé).

Des comptes de machine sont créés lorsqu’un volume SMB Azure NetApp Files est approvisionné sur une ressource back-end spécifique dans le service. Les scénarios suivants montrent différents scénarios où un compte de machine SMB peut être créé ou réutilisé dans les configurations de volume Azure NetApp Files.

Scénario Résultat
Premier nouveau volume SMB Nouveau compte d’ordinateur SMB/nom DNS
Volumes SMB suivants créés à court terme à partir du premier volume SMB Compte d’ordinateur SMB réutilisé/nom DNS (dans la plupart des cas).
Volumes SMB suivants créés beaucoup plus tard que le premier volume SMB Le service détermine si un nouveau compte d’ordinateur est nécessaire. Il est possible que plusieurs comptes d’ordinateur puissent être créés, ce qui génère plusieurs points de terminaison d’adresse IP.
Premier volume à deux protocoles Nouveau compte d’ordinateur SMB/nom DNS
Volumes à deux protocoles suivants créés à court terme à partir du premier volume à deux protocoles Compte d’ordinateur SMB/nom DNS réutilisé (dans la plupart des cas)
Les volumes à deux protocoles suivants ont été créés beaucoup plus tard que le premier volume à deux protocoles Le service détermine si un nouveau compte d’ordinateur est nécessaire. Il est possible que plusieurs comptes d’ordinateur puissent être créés, ce qui génère plusieurs points de terminaison d’adresse IP.
Premier volume SMB créé après le volume à deux protocoles Nouveau compte d’ordinateur SMB/nom DNS
Premier volume à deux protocoles créé après le volume SMB Nouveau compte d’ordinateur SMB/nom DNS

Le compte d’ordinateur SMB créé pour le volume SMB Azure NetApp Files (ou à deux protocoles) utilise une convention d’affectation de noms qui respecte la valeur maximale de 15 caractères appliquée par Active Directory. Le nom utilise la structure de [préfixe de serveur SMB spécifiée dans la configuration de connexion Azure AD]-[identificateur numérique unique].

Par exemple, si vous avez configuré vos connexions Azure AD pour utiliser le préfixe de serveur SMB « AZURE », le compte d’ordinateur SMB créé par Azure NetApp Files ressemble à « AZURE-7806 ». Ce même nom est utilisé dans le chemin UNC du partage SMB (par exemple, \AZURE-7806) et est le nom que les services DNS dynamiques utilisent pour créer l’enregistrement A/AAAA.

Remarque

Étant donné qu’un nom comme « AZURE-7806 » peut être difficile à mémoriser, il est utile de créer un enregistrement CNAME en tant qu’alias DNS pour les volumes Azure NetApp Files. Pour plus d’informations, consultez Création d’alias de serveur SMB.

Diagramme de plusieurs entrées de comptes d’ordinateur/DNS dans Azure NetApp Files.

Dans certains cas, lors de la création de plusieurs volumes SMB et/ou à deux protocoles, la configuration peut se retrouver avec plusieurs comptes d’ordinateur SMB disparates et noms DNS.

Si un espace de noms unique pour l’accès utilisateur sur les volumes est souhaité, cela peut présenter un défi dans la configuration, car un seul alias CNAME peut pointer vers un seul enregistrement hôte A/AAAA, tandis que l’utilisation de plusieurs alias d’enregistrement A/AAAA identiques peut entraîner une impossibilité d’accès aux données dans les différents comptes d’ordinateur SMB, comme il n’existe aucune garantie que le point de terminaison sélectionné par le client dans la recherche DNS contient le volume attendu en raison de la nature de tourniquet de sélection d’enregistrements DNS dans ces configurations.

Pour résoudre cette limitation, les volumes Azure NetApp Files peuvent participer en tant que cibles dans une configuration de système de fichiers DFS Microsoft, qui peut fournir un moyen d’associer plusieurs volumes SMB à un point d’entrée d’espace de noms unique.

Diagramme d’un système de fichiers DFS dans Azure NetApp Files.

Flux de travail de création du SPN Kerberos SMB

Le diagramme suivant illustre la création d’un SPN Kerberos SMB lors de la création d’un volume SMB ou à deux protocoles Azure NetApp Files. Les SPN SMB sont associés à des objets de compte d’ordinateur SMB dans le domaine. Le SPN peut être consulté et géré via les propriétés du compte d’ordinateur à l’aide de l’éditeur d’attributs dans l’affichage Avancé.

Capture d’écran des propriétés Azure-SMB.

Vous pouvez également afficher et gérer les propriétés avec la commande setspn.

Capture d’écran de la commande « setspn ».

Ce processus suit les mêmes étapes que lorsqu’un client Windows standard joint un domaine (DNS, LDAP, Kerberos, requêtes RPC sur des canaux nommés).

Diagramme du compte d’ordinateur Kerberos.

Dans la plupart des cas, la connaissance approfondie des étapes détaillées n’est pas nécessaire pour les tâches d’administration quotidiennes, mais est utile pour résoudre les échecs lors de la tentative de création d’un volume SMB dans Azure NetApp Files.

Procédure détaillée

Pour obtenir des instructions détaillées sur la création d’un compte d’ordinateur SMB dans Azure NetApp Files, développez la liste.

  • La recherche DNS est effectuée à l’aide de la configuration DNS pour l’enregistrement SRV d’un KDC Kerberos. Azure NetApp Files utilise les enregistrements SRV suivants dans ses requêtes.

    • _kerberos._tcp.dc._msdcs.CONTOSO.COM
    • _kerberos._tcp.CONTOSO.COM (si la requête précédente ne retourne aucun résultat)

  • La recherche DNS est effectuée à l’aide des noms d’hôte retournés dans la requête SRV pour les enregistrements A/AAAA des KDC.

    • Une requête ping LDAP (liaison LDAP et requête RootDSE) est effectuée pour rechercher les serveurs NetLogon hérités disponibles à l’aide de la requête (&(DnsDomain=CONTOSO.COM)(NtVer=0x00000016)) avec un filtre d’attribut pour NetLogon. Les versions plus récentes du contrôleur de domaine Windows (supérieures à 2008) n’ont pas la valeur NtVer.

  • Une requête DNS est effectuée par Azure NetApp Files pour rechercher les serveurs LDAP dans le domaine à l’aide des enregistrements SRV suivants :

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

    Remarque

    Ces requêtes se produisent plusieurs fois dans le même appel sur différentes parties du processus. Les problèmes DNS peuvent créer une lenteur dans ces appels ou, avec des délais d’attente, des échecs complets. - Si les requêtes ne parviennent pas à trouver une entrée ou si les entrées trouvées ne peuvent pas être contactées, la création du volume SMB échoue. - Si les requêtes DNS réussissent, les étapes suivantes sont traitées.

  • ICMP (ping) est envoyé pour vérifier que les adresses IP retournées par DNS sont accessibles.

  • Si le test ping est bloqué sur le réseau par des stratégies de pare-feu, la requête ICMP échoue. Au lieu de cela, les pings LDAP sont utilisés.

  • Un autre test ping LDAP est effectué pour rechercher des serveurs NetLogon hérités disponibles à l’aide de la requête (&(&(DnsDomain=CONTOSO.COM)(Host=KDChostname.contoso.com))(NtVer=0x00000006)) avec le filtre d’attribut NetLogon. Les versions plus récentes du contrôleur de domaine Windows (supérieures à 2008) n’ont pas la valeur NtVer.

  • Une authentification AS-REQ est envoyée à partir du service Azure NetApp Files à l’aide du nom d’utilisateur configuré avec la connexion Active Directory.

  • Le contrôleur de domaine répond avec KRB5KDC_ERR_PREAUTH_REQUIRED, qui demande au service d’envoyer le mot de passe de manière sécurisée à l’utilisateur.

  • Un deuxième AS-REQ est envoyé avec les données de pré-authentification nécessaires pour s’authentifier auprès du KDC pour pouvoir accéder à la création du compte d’ordinateur. En cas de réussite, un ticket d’octroi de ticket (Ticket-Granting Ticket, TGT) est envoyé au service.

  • Si elle réussit, un TGS-REQ est envoyé par le service pour demander le ticket de service CIFS (cifs/kdc.contoso.com) du KDC à l’aide du TGT reçu dans AS-REP.

  • Une nouvelle liaison LDAP à l’aide du ticket de service CIFS est effectuée. Les requêtes sont envoyées à partir d’Azure NetApp Files :

    • Recherche de base RootDSE pour le nom de domaine ConfigurationNamingContext
    • Recherche OneLevel de CN=partitions dans le DN récupéré pour ConfigurationNamingContext à l’aide du filtre (&(&(objectClass=crossRef)(nETBIOSName=*))(dnsRoot=CONTOSO.COM)) pour l’attribut NETBIOSname.
    • Une recherche de base à l’aide du filtre (|(objectClass=organizationalUnit)(objectClass=container)) est effectuée sur l’unité d’organisation spécifiée dans la configuration des connexions Active Directory. Si cette valeur n’est pas spécifiée, la valeur par défaut OU=Computers est utilisée. Cela vérifie que le conteneur existe.
    • Une recherche de sous-arborescence est effectuée sur le nom de domaine de base à l’aide du filtre (sAMAccountName=ANF-XXXX$) pour vérifier si le compte existe déjà.
      • Si le compte existe, il est réutilisé.
    • Si le compte n’existe pas, il est créé, à condition que l’utilisateur dispose des autorisations nécessaires pour créer et modifier des objets dans le conteneur à l’aide d’une commande LDAP addRequest. Les attributs LDAP suivants sont définis sur le compte :
    Attribut Valeur
    CN ANF-XXXX
    sAMAccountName ANF-XXXX$
    objectClass
    • Haut
    • Personne
    • OrganizationalPerson
    • Utilisateur
    • Computer
    servicePrincipalName
    • HOST/ANF-XXXX
    • HOST/anf-xxxx.contoso.com
    • CIFS/anf-xxxx.contoso.com
    userAccountControl 4096
    operatingSystem Version NetApp
    dnsHostName ANF-XXXX.CONTOSO.COM
    • En cas d’échec de addRequest, la création du volume échoue. addRequest peut échouer en raison d’autorisations incorrectes sur l’objet conteneur.
    • Si addRequest réussit, une recherche LDAP à l’aide du filtre (sAMAccountName=ANF-XXXX$) est effectuée pour récupérer l’attribut objectSid.
    • Une conversation SMB2 « Negotiate protocol » est effectuée pour récupérer le Kerberos mechTypes pris en charge à partir du KDC.
    • Une « configuration de session » SMB2 à l’aide du SPN CIFS et la plus élevée prise en charge mechType et une « connexion à l’arborescence » à IPC$ est effectuée.
    • Un fichier SMB2 lsarpc est créé dans le partage IPC$.
    • Une liaison à DCERPC est effectuée. Le fichier lsarpc est écrit, puis lu.
    • Les requêtes LSA suivantes sont ensuite effectuées :

  • Un TGS-REQ utilisant le TGT est effectué pour récupérer le ticket pour le SPN kadmin/changepw associé au compte krbtgt.

  • Une requête KPASSWD est effectuée du service au KDC pour modifier le mot de passe du compte d’ordinateur.

  • Une requête LDAP est effectuée avec le filtre (sAMAccountName=ANF-XXXX) pour les attributs distinguishedName et isCriticalSystemObject.

  • Si le isCriticalSystemObject du compte est false (valeur par défaut), le nom de domaine récupéré est utilisé pour formuler un modifyRequest pour l’attribut msDs-SupportedEncryptionTypes. Cette valeur est définie sur 30, ce qui équivaut à DES_CBC_MD5 (2) + RC4 (4) + AES 128 (8) + AES 256 (16).

  • Un deuxième « Negotiate protocol »/échange de ticket Kerberos/« Session setup »/« Tree connect » à IPC$ est effectué. Le compte d’ordinateur du serveur SMB (ANF-XXXX$) sert de principal Kerberos.

  • Les communications NetLogon, NetrServer ReqChallenge/Authenticate2 sont terminées.

  • Un troisième « Negotiate protocol:/échange de ticket Kerberos/« Session setup »/« Tree connect » à IPC$ est effectué. Le compte d’ordinateur du serveur SMB (ANF-XXXX$) est utilisé comme principal Kerberos.

  • Les connexions lsarpc et NetLogon sont effectuées en tant que vérification finale du compte.

Flux de travail de connexion de partage SMB (Kerberos)

Lorsqu’un volume Azure NetApp Files est monté à l’aide de Kerberos, un échange de tickets Kerberos est utilisé pendant les requêtes de configuration de plusieurs sessions pour fournir un accès sécurisé au partage. Dans la plupart des cas, la connaissance approfondie des étapes détaillées n’est pas nécessaire pour les tâches d’administration quotidiennes. Cette connaissance est utile pour résoudre les échecs lors de tentatives d’accès à un volume SMB dans Azure NetApp Files.

Diagramme du flux de travail de connexion de partage SMB.

Pour plus d’informations sur l’accès au partage SMB dans Azure NetApp Files, développez la liste.
  • Le client tente d’accéder à un partage SMB à l’aide du chemin UNC affiché dans Azure NetApp Files. Par défaut, le chemin UNC inclut le nom du serveur SMB (par exemple ANF-XXXX)
  • DNS est interrogé pour mapper le nom d’hôte à une adresse IP
  • Une conversation SMB2 initiale « Negotiate Protocol » a lieu
    • Une requête est envoyée par le client pour découvrir quels dialectes SMB sont pris en charge par le serveur et inclut ce que le client demandeur prend en charge
    • Le serveur répond en indiquant ce qu’il prend en charge, notamment :
      • Mode de sécurité (signature ou non)
      • Version SMB
      • GUID du serveur
      • Fonctionnalités prises en charge (DFS, location, grande MTU, multicanal, handles persistants, location d’annuaires, chiffrement)
      • Taille maximale des transactions
      • Taille maximale en lecture et en écriture
      • Objet blob de sécurité (Kerberos ou NTLM)
  • Une deuxième conversation « Negotiate Protocol » SMB2 a lieu en tant que « preauthorization »/connexion
    • La requête du client inclut :
      • Hachage de préautorisation
      • Modes de sécurité pris en charge (signature ou non)
      • Fonctionnalités prises en charge (DFS, location, grande MTU, multicanal, handles persistants, location d’annuaires, chiffrement)
      • GUID client
      • Dialectes SMB pris en charge
    • Si le hachage de préautorisation est accepté, le serveur répond avec :
      • Mode de sécurité (signature ou non)
      • Fonctionnalités prises en charge (DFS, location, grande MTU, multicanal, handles persistants, location d’annuaires, chiffrement)
      • Taille maximale des transactions
      • Taille maximale en lecture et en écriture
      • Objet blob de sécurité (Kerberos ou NTLM)
      • Fonctionnalités d’intégrité et de chiffrement de préautorisation SMB
  • Si la négociation de protocole réussit, une requête « Session setup » est effectuée.
    • La configuration utilise le hachage de préautorisation à partir de la négociation de protocole.
    • La configuration informe le serveur SMB de ce que le client demandeur prend en charge, notamment :
      • StructureSize
      • Indicateur de liaison de session
      • Mode de sécurité (signature activée/obligatoire)
      • Fonctionnalités
      • Types de chiffrement Kerberos pris en charge
  • Une réponse « Session setup » est envoyée.
    • Les crédits SMB sont accordés.
    • L’ID de session est établi.
    • Les indicateurs de session sont définis (guest, null, encrypt).
    • Le type de chiffrement Kerberos est défini.
  • Une requête tree connect (connexion à l’arborescence) est envoyée par le client pour la connexion au partage SMB.
    • Les indicateurs/fonctionnalités de partage sont envoyés à partir du serveur, ainsi que des autorisations de partage.
  • La commande ioctlFSCTL_QUERY_NETWORK_INTERFACE_INFO est envoyée pour obtenir l’adresse IP du serveur SMB.
  • Le serveur SMB dans Azure NetApp Files renvoie les informations réseau, notamment : * Adresse IP * Fonctionnalité d’interface (RSS activé ou désactivé) * Nombre de files d’attente RSS * Vitesse de liaison
  • Une requête tree connect (connexion à l’arborescence) est envoyée par le client pour la connexion au partage d’administration IPC$.
    • Le partage IPC$ est une ressource qui partage les canaux nommés essentiels à la communication entre les programmes. Le partage IPC$ est utilisé pendant l’administration à distance d’un ordinateur et lors de l’affichage des ressources partagées d’un ordinateur. Vous ne pouvez pas modifier les paramètres de partage, les propriétés de partage ou les ACL du partage IPC$. Vous ne pouvez pas également renommer ni supprimer le partage IPC$.
  • Une liaison DCERPC est effectuée sur le fichier srvsvc pour établir une connexion sécurisée.
    • Le fichier est écrit avec les informations récupérées précédemment.
  • Un TGS-REQ Kerberos est émis par le client Windows au KDC pour obtenir un ticket de service (ST) pour le service SMB.
  • Une commande NetShareGetInfo est exécutée par le client SMB sur le serveur et une réponse est envoyée.
  • Le ticket de service SMB est récupéré à partir du KDC.
  • Azure NetApp Files tente de mapper l’utilisateur Windows demandant l’accès au partage à un utilisateur UNIX valide.
    • Une requête Kerberos TGS est effectuée à l’aide des informations d’identification Kerberos du serveur SMB stockées avec le keytab du serveur SMB à partir de la création initiale du serveur SMB à utiliser pour une liaison de serveur LDAP.
    • Un utilisateur UNIX mappé à l’utilisateur SMB demandant l’accès au partage est recherché sur LDAP. Si aucun utilisateur UNIX n’existe dans LDAP, l’utilisateur UNIX par défaut pcuser est utilisé par Azure NetApp Files pour le mappage de noms (les fichiers/dossiers écrits dans des volumes à deux protocoles utilisent l’utilisateur UNIX mappé comme propriétaire UNIX).
  • Une autre requête negotiate protocol/session request/tree connect est effectuée, cette fois à l’aide du SPN Kerberos du serveur SMB vers le partage IPC$ du contrôleur de domaine Active Directory.
    • Un canal nommé est établi pour le partage via srvsvc.
    • Une session NETLOGON est établie sur le partage et l’utilisateur Windows est authentifié.
  • Si les autorisations le permettent pour l’utilisateur, le partage répertorie les fichiers et dossiers contenus dans le volume.

Remarque

Azure NetApp Files ajoute des entrées au cache de contexte Kerberos pour le client. Ces entrées résident dans le cache pendant la durée de vie du ticket Kerberos (définie par le KDC et contrôlée par la stratégie Kerberos.

Création d’alias de serveur SMB

Quand Azure NetApp Files crée un serveur SMB à l’aide d’une convention d’affectation de noms de [préfixe de serveur SMB spécifié dans la configuration de connexion Azure AD]-[identificateur numérique unique]. (Pour plus d’informations sur l’identificateur numérique unique, consultez Compte d’ordinateur Kerberos SMB). Cette mise en forme signifie que les noms de serveurs SMB ne sont pas définis de manière conviviale. Par exemple, le nom « SMB-7806 » est plus difficile à mémoriser que « AZURE-FILESHARE ».

En raison de ce comportement, les administrateurs peuvent préférer créer des noms d’alias conviviaux pour les volumes Azure NetApp Files. Cela nécessite de pointer un nom canonique DNS (CNAME) vers l’enregistrement DNS A/AAAA existant dans le serveur.

Lorsqu’un CNAME est créé et utilisé dans les requêtes de chemin d'accès UNC (par exemple, \\AZURE-FILESHARE au lieu de \\SMB-7806), DNS redirige la requête CNAME (AZURE-FILESHARE.contoso.com) vers l’enregistrement A/AAAA approprié (SMB-7806.contoso.com), qui est utilisé dans la récupération du SPN Kerberos (cifs/SMB-7806). Cela permet à Kerberos d’accéder au partage SMB lors de l’utilisation du nom alias.

Si un enregistrement DNS A/AAAA est créé (par exemple, AZURE-FILESHARE.contoso.com) et tente d’être utilisé comme alias, les requêtes Kerberos échouent. L’échec est dû à l'utilisation d'un SPN construit pour l'authentification auprès du partage (cifs/AZURE-FILESHARE) qui ne correspond pas au SPN Kerberos associé au serveur SMB (cifs/SMB-7806). L’échec peut être résolu si un autre SPN est créé et ajouté au compte d’ordinateur du serveur SMB (par exemple, cifs/AZURE-FILESHARE).

Fonctionnalités de serveur SMB prises en charge dans Azure NetApp Files

Lorsque la requête SMB « negotiate protocol » est effectuée, le serveur SMB Azure NetApp Files est interrogé pour prendre en charge des fonctionnalités spécifiques. Le tableau suivant présente les fonctionnalités interrogées et la réponse retournée à partir d’un volume SMB Azure NetApp Files lorsqu’une requête Session Setup/Tree connect est effectuée.

Fonctionnalité SMB Pris en charge par Azure NetApp Files ?
Cible DFS Oui
Bail Oui
MTU élevée Oui
SMB multicanal Oui
Handles persistants SMB Oui
Bail de répertoire Non
Chiffrement SMB Oui (si activé)

Fonctionnalités et propriétés de partage SMB prises en charge dans Azure NetApp Files

Pendant l’accès au partage SMB, une requête « tree connect » est effectuée et les fonctionnalités et propriétés de partage SMB prises en charge sont interrogées par le client sur le serveur Azure NetApp Files. Le tableau suivant présente les fonctionnalités de partage interrogées et la réponse retournée à partir d’un volume SMB Azure NetApp Files, comme indiqué dans une capture de paquets.

Fonctionnalité de partage SMB Pris en charge par Azure NetApp Files ?
Disponible en continu (CA) Oui, pour des charges de travail spécifiques* (si activé)
Scale-out Non
Cluster Non
Asymétrique Non
Rediriger vers le propriétaire Non

* Voir Activer la disponibilité continue sur les volumes SMB existants pour les charges de travail prises en charge.

Le tableau suivant présente les propriétés de partage interrogées et la réponse retournée par un volume SMB Azure NetApp Files.

Fonctionnalité de partage SMB Pris en charge par Azure NetApp Files ?
Cible DFS Oui
Racine DFS Non
Restreindre les ouvertures exclusives Non
Suppression partagée forcée Non
Autoriser la mise en cache d’espace de noms Non
Énumération basée sur l’accès Oui (si activé)
Forcer le verrouillage oplock de niveau II Non
Activer le hachage V1 Non
Activer le hachage v2 Non
Chiffrement requis Oui (si activé)
Communication à distance d’identité Non
E/S compressées Non
Transport isolé Non

Fonctionnement de NFS Kerberos dans Azure NetApp Files

NFS Kerberos fonctionne séparément des services SMB, car les comptes d’ordinateur créés pour chaque protocole ne peuvent pas partager des clés en raison du risque de modifications apportées au numéro de version de clé (kvno) dans un keytab affectant l’autre service. Par conséquent, les flux de travail pour les services SMB pour Kerberos et NFS pour Kerberos diffèrent dans certaines fonctionnalités.

Configuration initiale du domaine Kerberos

Le domaine NFS Kerberos est configuré lorsque les informations du domaine Kerberos sont renseignées dans le portail Azure NetApp Files sous la page des connexions Active Directory.

Capture d’écran de la configuration du domaine Kerberos.

Le nom du serveur Azure AD et l’adresse IP KDC sont utilisés pour se connecter aux services du KDC Azure AD lors de la création du compte d’ordinateur initial. Le service Azure NetApp Files tire parti des informations de domaine existantes pour remplir le reste de la configuration du domaine. Par exemple :

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

Lorsque le domaine Kerberos NFS est configuré, une entrée d’hôte local est ajoutée au service avec le KDC spécifié dans la configuration. Lorsque le domaine est modifié, l’entrée des hôtes locaux est également modifiée dans le service.

Diagramme de la configuration du domaine Kerberos.

Cette entrée d’hôte local agit en tant que « dernier recours » si une panne se produit sur le KDC spécifié dans la configuration du domaine et l’échec d’interrogation des KDC redondants via DNS.

Remarque

Si le KDC Kerberos dans le domaine Kerberos doit être mis hors service (par exemple, pour les mises à niveau ou la désaffectation d’un serveur), il est recommandé de configurer le domaine pour utiliser un KDC qui n’est pas en cours de maintenance pour éviter les pannes.

Création initiale du compte d’ordinateur/SPN

Lorsque Kerberos est activé sur un volume Azure NetApp Files, un compte d’ordinateur/principal nommé NFS-{SMB-server-name} est créé dans le domaine dans l’unité d’organisation spécifiée dans les connexions Active Directory (unité d’organisation). Les noms de comptes d’ordinateur sont tronqués après 15 caractères.

Remarque

Lors de l’ajout de clients Linux avec des noms d’hôte supérieurs à 15 caractères dans un domaine Active Directory, leurs SPN de compte d’ordinateur Kerberos sont tronqués. Par exemple, un client Linux MORE-THAN-FIFTEEN a le nom de compte d’ordinateur MORE-THAN-FIFT$, qui devient le SPN MORE-THAN-FIFT$@CONTOSO.COM. Lorsque DNS recherche un nom d’hôte client, il trouve le nom le plus long et tente d’utiliser ce nom dans une requête SPN ( MORE-THAN-FIFTEEN@CONTOSO.COM). Étant donné que ce SPN n’existe pas, le client tente d’utiliser le SPN suivant dans le keytab dans la requête (généralement hôte/nom d’hôte). Seuls les noms de comptes d’ordinateur fonctionnent en mode natif avec NFS Kerberos Azure NetApp Files. Par conséquent, vérifiez que les noms d’hôtes du client Linux utilisés pour NFS Kerberos avec Azure NetApp Files ne dépassent pas 15 caractères. Sinon, si vous souhaitez utiliser le SPN de l’hôte/du nom d’hôte, configurez un utilisateur UNIX dans LDAP avec le nom d’utilisateur « host ». Cette configuration fournit un mappage de noms krb-unix pour le SPN.

Dans Azure NetApp Files, les blocs de clés Kerberos (ou entrées keytab) sont ajoutés au service avec le SPN du service NFS (nfs/nfs-server-name.contoso.com@CONTOSO.COM). Plusieurs entrées sont créées : une pour chaque type de chiffrement pris en charge. Dans Azure NetApp Files, seul le type de chiffrement AES-256 est pris en charge pour NFS Kerberos.

Dans la plupart des cas, le fait de connaître ces étapes en profondeur n’est pas nécessaire pour les tâches d’administration quotidiennes, mais sont utiles pour résoudre les échecs lors de la tentative de création d’un volume NFS Kerberos dans Azure NetApp Files.

Flux de travail de création du SPN NFS Kerberos

Le diagramme suivant montre comment un SPN NFS est créé lorsqu’un volume NFS ou à deux protocoles Azure NetApp Files est créé avec Kerberos activé. Dans la plupart des cas, la connaissance approfondie des étapes détaillées n’est pas nécessaire pour les tâches d’administration quotidiennes, mais est utile pour résoudre les échecs lors de la tentative de création d’un volume SMB dans Azure NetApp Files.

Diagramme du flux de travail de création du SPN NFS Kerberos.

Pour obtenir des instructions détaillées sur la création d’un SPN NFS Kerberos avec Azure NetApp Files, développez la liste.
  • Informations d’identification d’administrateur transmises à KDC spécifiées dans la configuration du domaine à l’aide du nom d’utilisateur fourni pour une utilisation dans la connexion Active Directory : l’utilisateur doit avoir l’autorisation d’afficher/de créer des objets dans l’unité d’organisation spécifiée.
  • Les serveurs DNS spécifiés dans la configuration de connexion Active Directory Azure NetApp Files sont interrogés par Azure NetApp Files pour les enregistrements de service Kerberos (SRV) dans les formats suivants :
    • Requête URI pour _kerberos.CONTOSO.COM
    • Requête SRV pour _kerberos-master._udp. CONTOSO.COM
    • Requête SRV pour _kerberos-master._tcp. CONTOSO.COM

Remarque

Ces requêtes se produisent plusieurs fois dans le même appel sur différentes parties du processus. Les problèmes DNS peuvent ralentir ces appels ou entraîner des échecs. Ces enregistrements n’apparaissent pas par défaut dans les déploiements Active Directory et doivent être créés manuellement.

  • Si les requêtes ne parviennent pas à trouver une entrée ou si les entrées trouvées ne peuvent pas être contactées ou utilisées comme contrôleur de domaine principal, une requête d’enregistrement A utilisant le nom de domaine trouvé dans la configuration du domaine Kerberos NFS est utilisée comme dernier recours pour se connecter au KDC sur le port 88.
  • Pendant la configuration de NFS Kerberos, une entrée hôte statique pour le KDC spécifié est ajoutée au fichier hôte local en tant que sauvegarde si les recherches DNS échouent.
  • S’il existe une entrée DNS mise en cache pour le domaine, elle est utilisée. Dans le cas contraire, l’entrée de fichier local est utilisée. Les entrées DNS mises en cache sont actives tant que la durée de vie (TTL) est configurée pour l’enregistrement DNS. L’entrée de fichier local est configurée avec une durée de vie de 86 400 secondes (24 heures). La configuration ns-switch pour les recherches d’hôte dans Azure NetApp Files utilise d’abord des fichiers, puis DNS. Lorsque l’entrée locale est trouvée, aucune autre requête n’est effectuée.
  • Le compte d’ordinateur SMB créé lors de la création de la connexion Active Directory est utilisé comme informations d’identification pour une liaison LDAP Active Directory à l’aide de SASL/GSS sur le port 389 pour rechercher les entrées existantes du nom du SPN ou du compte d’ordinateur souhaité. Si le nom du SPN ou du compte d’ordinateur existe déjà, une erreur est envoyée. Si le SPN n’existe pas dans la requête LDAP, la création du compte d’ordinateur est effectuée dans l’unité d’organisation désignée avec des entrées pour les attributs suivants définis par 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)
  • Le mot de passe du compte d’ordinateur Kerberos NFS est défini pour le compte NFS-MACHINE sur le port 464.
  • Les keyblocks Kerberos (keytabs) pour le SPN NFS sont enregistrés sur le service Azure NetApp Files.
  • Une règle de mappage de noms statique est créée sur le service Azure NetApp Files pour garantir que l’utilisateur racine de chaque client Kerberos NFS est mappé à la racine quand Kerberos est utilisé.
  • Un fichier krb5.conf est ajouté aux systèmes internes du service avec les informations du domaine NFS.

Montages NFS Kerberos

Lorsqu’un volume Azure NetApp Files est monté à l’aide de versions de sécurité Kerberos sur NFS, le flux de travail suivant est effectué. Pour obtenir une présentation plus détaillée de Kerberos, consultez Résumé du service d’authentification réseau Kerberos (V5).

Diagramme du flux de travail de montage NFS Kerberos.

Pour obtenir des instructions détaillées sur la façon dont un volume NFS Kerberos est monté avec Azure NetApp Files, développez la liste.
  • Le client tente un montage sur un chemin d’exportation NFS dans Azure NetApp Files et spécifie la saveur de sécurité -okrb5 (ou krb5i ou krb5p).
  • DNS est utilisé pour formuler une requête de principal de service NFS auprès d’Azure NetApp Files via un enregistrement A/AAAA ou PTR (selon la façon dont la commande de montage (mount) a été émise).
  • Le client récupère un TGT à partir du KDC par le biais d’un appel AS-REQ à l’aide du nom du principal CLIENT trouvé dans le keytab du client.
  • Le chemin d’exportation est vérifié pour s’assurer qu’il existe dans le système de fichiers.
  • La règle de stratégie d’exportation est vérifiée pour vous assurer que l’accès Kerberos est autorisé au chemin d’exportation.<
  • Le ticket de service NFS est demandé à partir du KDC par le client via un appel AP-REQ. Azure NetApp Files vérifie le keytab d’une entrée valide avec un type de chiffrement valide à l’aide du TGT du client acquis à partir du KDC.
  • Si le TGT est valide, un ticket de service est émis.
  • Le SPN client (par exemple, CLIENT$@CONTOSO.COM) est mappé à l’utilisateur racine via la règle de mappage de noms dans Azure NetApp Files.
  • L’utilisateur racine est interrogé dans les bases de données des services de noms (fichiers et LDAP) pour l’existence/l’appartenance aux groupes.
  • Une liaison LDAP à l’aide du compte d’ordinateur serveur SMB est effectuée pour autoriser une recherche LDAP pour l’utilisateur racine.
  • Étant donné que la racine existe toujours dans Azure NetApp Files, cela ne doit pas poser de problème, mais les requêtes LDAP pour la racine peuvent échouer. Ces échecs peuvent être ignorés.
  • Le ticket de service NFS est retourné au client et le montage réussit. L’utilisateur racine dispose d’un accès racine au montage Kerberos par le biais du principal du compte d’ordinateur du client (visible avec la commande klist -e à partir du client).
  • Azure NetApp Files ajoute des entrées au cache de contexte Kerberos pour le client. Ces entrées résident dans le cache pendant la durée de vie du ticket Kerberos défini par le KDC et contrôlées par la stratégie Kerberos.
  • NFSv4.1 régulièrement (toutes les 20 secondes) envoie des mises à jour d’actualisation de ticket Kerberos en tant que « keepalives ».

Accès au montage Kerberos NFS avec des principaux d’utilisateur

Lorsqu’un montage NFS Kerberos Azure NetApp Files est accessible par un utilisateur (autre que l’utilisateur racine, qui utilise le SPN du compte d’ordinateur), le flux de travail suivant est effectué.

Diagramme de l’accès au montage NFS Kerberos avec des principaux d’utilisateur.

Pour obtenir des instructions détaillées sur l’accès à un volume NFS Kerberos avec un utilisateur non racine avec Azure NetApp Files, développez la liste.
  • L’utilisateur se connecte au KDC avec un échange de nom d’utilisateur/mot de passe ou via un fichier keytab pour obtenir un TGT via un appel AS-REQ à utiliser pour collecter un ticket de service à partir du volume Azure NetApp Files.
  • La règle de stratégie d’exportation est vérifiée pour s’assurer que l’accès Kerberos est autorisé au chemin d’exportation de l’ordinateur client
  • Azure NetApp Files recherche un ticket de service NFS mis en cache. S’il n’existe aucun ticket de service NFS, le ticket de service NFS est demandé via un appel AP-REQ et le service vérifie le keytab pour une entrée valide avec un type de chiffrement valide à l’aide du TGT du client acquis à partir du KDC
  • Si le TGT est valide, un ticket de service est émis
  • Le nom d’utilisateur principal de l’utilisateur (UPN) est mappé via le mappage implicite. Par exemple, si l’UPN est user1@CONTOSO.COM, le service interroge un utilisateur UNIX nommé user1. Étant donné que cet utilisateur UNIX n’existe pas dans la base de données de fichiers locales dans Azure NetApp Files, LDAP est utilisé.
  • Une liaison LDAP à l’aide du compte d’ordinateur du serveur SMB est tentée d’autoriser une recherche LDAP pour l’utilisateur mappé. Une requête SRV DNS est effectuée pour les enregistrements DNS Kerberos (_kerberos et _kerberos-master). Si aucun enregistrement valide ne peut être utilisé, la configuration revient à la configuration du domaine. Ces requêtes SRV DNS KDC ne sont pas délimitées au site.
  • Les enregistrements SRV LDAP sont interrogés pour les serveurs LDAP valides. Il s’agit d’une étendue de site.
  • Si l’utilisateur n’existe pas dans LDAP ou si LDAP ne peut pas être interrogé (le serveur est arrêté, la recherche DNS échoue, la liaison échoue, la recherche LDAP expire, l’utilisateur n’existe pas), le mappage échoue et l’accès est refusé.
  • Si l’utilisateur existe, les appartenances aux groupes sont collectées.
  • Le mappage réussit et un ticket de service NFS est émis au client (vu dans les commandes klist -e). L’accès est autorisé en fonction des autorisations de fichier sur le chemin d’exportation.

Rôle LDAP avec Kerberos dans Azure NetApp Files

Azure NetApp Files s’appuie sur LDAP pour NFS Kerberos. NFS Kerberos dans Azure NetApp Files nécessite Kerberos pour les mappages de noms UNIX pour les noms utilisateur entrants. Étant donné qu’Azure NetApp Files ne prend pas en charge la création d’utilisateurs UNIX locaux, LDAP est nécessaire pour effectuer des recherches pour les utilisateurs UNIX lorsqu’un mappage de noms est demandé.

  • Lorsqu’une connexion Azure AD est créée, le nom de domaine Active Directory est utilisé pour spécifier le processus de recherche de serveurs LDAP.
  • Quand un serveur LDAP est nécessaire, _ldap.domain.com est utilisé pour la recherche SRV pour les serveurs LDAP.
  • Une fois qu’une liste de serveurs est découverte, le meilleur serveur disponible (basé sur le temps de réponse ping) est utilisé comme serveur LDAP pour la connexion sur le port 389.
  • Une liaison LDAP est tentée à l’aide du compte d’ordinateur SMB via GSS/Kerberos.
  • S’il n’y a pas de connexion mise en cache ou d’informations d’identification Kerberos, une nouvelle requête de ticket Kerberos est émise. Les connexions mises en cache pour les serveurs de noms dans Azure NetApp Files sont actives pendant 60 secondes. Si elle est inactive pendant plus de 60 secondes, le cache de connexion est effacé.
  • DNS est utilisé pour rechercher les KDC Kerberos appropriés via des enregistrements SRV.
  • Si aucun KDC n’est trouvé via une requête DNS, le KDC spécifié dans le fichier krb5.conf pour les services SMB est utilisé.
    • Si ce KDC est inaccessible ou ne peut pas traiter la requête Kerberos, la liaison LDAP échoue. La recherche de noms échoue également. L’accès est refusé au montage, car aucune authentification valide n’a eu lieu.
    • Si la liaison réussit, une requête LDAP est effectuée pour l’utilisateur et ses informations d’identification. Si le temps de recherche dépasse 10 secondes, la recherche échoue.
  • Si la recherche trouve l’utilisateur, le mappage réussit et l’accès est accordé via Kerberos (à condition que le ticket soit valide/n’ait pas expiré).

Adresses IP pour l’accès avec Kerberos

Par défaut, l’authentification Kerberos s’appuie sur la résolution du nom d’hôte en adresse IP pour formuler le nom de principal du service (SPN) utilisé pour récupérer le ticket Kerberos. Par exemple, lors de l’accès à un partage SMB avec un chemin d’accès UNC (Universal Naming Convention) tel que \SMBVOLUME.CONTOSO.COM, une requête DNS est émise pour le nom de domaine complet SMBVOLUME.CONTOSO.COM, et l’adresse IP du volume Azure NetApp Files est récupérée. S’il n’y a pas d’entrée DNS présente (ou si l’entrée actuelle est différente de ce qui est demandé, par exemple avec des alias/CNAME), il est impossible de récupérer un SPN approprié et la requête Kerberos échoue. Par conséquent, l’accès au volume peut être interdit si la méthode d’authentification de secours (par exemple, New Technology LAN Manager) est désactivée.

Les entrées DNS dans Azure NetApp Files sont créées automatiquement à l’aide du DNS dynamique et sont formulées à l’aide du nom du serveur SMB. Pour toutes les variantes/alias du nom défini, un enregistrement CNAME DNS manuel doit être créé et pointé vers l’entrée DNS dynamique. Pour plus d'informations, consultez Comprendre DNS dans Azure NetApp Files.

NFSv4.1 Kerberos fonctionne de manière similaire pour la récupération SPN, où les recherches DNS sont une partie intégrante du processus d’authentification et peuvent également être utilisées pour la découverte de domaine Kerberos.

Si une adresse IP est utilisée (plutôt qu’un nom d’hôte) dans une requête d’accès à un volume Azure NetApp Files, une requête Kerberos fonctionne différemment en fonction du protocole utilisé.

Comportement SMB Kerberos avec des adresses IP et des noms DNS

Lors de l’utilisation de SMB, une requête de chemin d'accès UNC utilisant une adresse IP (par exemple, \\x.x.x.x) tente par défaut d’utiliser NTLM pour l’authentification. Dans les environnements où NTLM n’est pas autorisé pour des raisons de sécurité, une requête SMB utilisant une adresse IP n’est pas en mesure d’utiliser Kerberos ni NTLM pour l’authentification par défaut. Par conséquent, l’accès au volume Azure NetApp Files est refusé. Dans les versions ultérieures de Windows (à compter de Windows 10 version 1507 et Windows Server 2016), les clients Kerberos peuvent être configurés pour prendre en charge les noms d’hôte IPv4 et IPv6 dans les noms d’hôtes dans les SPN pour la communication SMB afin de contourner ce problème.

Comportement Kerberos NFSv4.1 avec des adresses IP et des noms DNS

Lorsque vous utilisez NFSv4.1, une requête de montage vers une adresse IP à l’aide de l’une des options sec=[krb5/krb5i/krb5p] utilise des recherches DNS inversées via PTR pour résoudre une adresse IP en nom d’hôte. Ce nom d’hôte est ensuite utilisé pour formuler le SPN pour la récupération de ticket Kerberos. Si vous utilisez NFSv4.1 avec Kerberos, vous devez disposer d’un A/AAAA et d’un PTR pour le volume Azure NetApp Files pour couvrir à la fois l’accès par nom d’hôte et adresse IP aux montages. Azure NetApp Files crée un enregistrement A/AAAA DNS dynamique. Si une zone DNS inversée existe pour ce sous-réseau, un enregistrement PTR est créé automatiquement également. Pour les écarts par rapport aux conventions de nom d’hôte Azure NetApp Files standard, utilisez des enregistrements CNAME pour les alias DNS.

Pour plus d'informations, consultez Comprendre DNS dans Azure NetApp Files