Comprendre les instructions relatives à la conception et à la planification de site Active Directory Domain Services pour Azure NetApp Files
Une conception et une planification adéquates des Active Directory Domain Services (AD DS) sont essentielles pour les architectures de solution qui utilisent des volumes Azure NetApp Files. Les fonctionnalités Azure NetApp Files telles que les volumes SMB, les volumes de double protocole et les volumes Kerberos NFSv4.1 sont conçues pour être utilisées avec AD DS.
Cet article apporte des recommandations pour vous aider à développer une stratégie de déploiement AD DS pour Azure NetApp Files. Avant de lire cet article, vous devez avoir une bonne compréhension du fonctionnement d’AD DS au niveau fonctionnel.
Identifier les exigences AD DS pour Azure NetApp Files
Avant de déployer des volumes Azure NetApp Files, vous devez identifier les exigences d’intégration AD DS pour Azure NetApp Files pour vous assurer que Azure NetApp Files est bien connecté à AD DS. Une intégration AD DS incorrecte ou incomplète avec Azure NetApp Files peut entraîner des interruptions ou des pannes d’accès client pour les volumes SMB, double protocole ou Kerberos NFSv4.1.
Scénarios d’authentification pris en charge
Azure Netapp Files prend en charge l’authentification basée sur l’identité sur le protocole SMB via les méthodes suivantes.
- Authentification AD DS : les machines Windows jointes à AD DS peuvent accéder aux partages Azure NetApp Files avec des informations d’identification Active Directory sur SMB. Votre client doit pouvoir visualiser votre instance AD DS. Si AD DS est déjà configuré localement ou sur une machine virtuelle dans Azure, et que vos appareils sont joints à votre domaine AD DS, vous devez utiliser AD DS pour l’authentification des partages de fichiers Azure NetApp Files.
- Authentification Microsoft Entra Domain Services : les machines virtuelles informatiques Windows jointes à Microsoft Entra Domain Services peuvent accéder aux partages de fichiers Azure NetApp Files avec les informations d’identification Microsoft Entra Domain Services. Dans cette solution, Microsoft Entra Domain Services exécute un domaine Windows Server AD traditionnel pour le client.
- Kerberos Microsoft Entra pour les identités hybrides : l’utilisation de Microsoft Entra ID pour authentifier des identités utilisateur hybrides permet aux utilisateurs de Microsoft Entra d’accéder aux partages de fichiers Azure NetApp Files à l’aide de l’authentification Kerberos. Cela signifie que vos utilisateurs finaux peuvent accéder à des partages de fichiers Azure NetApp Files sans avoir besoin d’une visibilité sur les contrôleurs de domaine des machines virtuelles Windows ou Linux jointes à Microsoft Entra de façon classique ou hybride. Les identités uniquement cloud ne sont pas prises en charge actuellement.
- Authentification Kerberos AD pour les clients Linux : les clients Linux peuvent utiliser l’authentification Kerberos sur SMB pour Azure NetApp Files à l’aide d’AD DS.
Configuration requise pour le réseau
Les volumes Azure NetApp Files SMB, double protocole et Kerberos NFSv4.1 nécessitent une connectivité réseau fiable et à faible latence (moins de 10 ms de RTT) aux contrôleurs de domaine AD DS. Une mauvaise connectivité réseau ou une latence réseau élevée entre Azure NetApp Files et les contrôleurs de domaine AD DS peuvent entraîner des interruptions d’accès client ou des dépassements des délais d’attente du client.
Vérifiez que vous répondez aux exigences suivantes concernant la topologie et les configurations réseau :
- Vérifiez qu’une topologie de réseau prise en charge pour Azure NetApp Files est utilisée.
- Vérifiez que les contrôleurs de domaine AD DS disposent d’une connectivité réseau à partir du sous-réseau délégué Azure NetApp Files hébergeant les volumes Azure NetApp Files.
- Le peering des topologies de réseau virtuel appairées avec des contrôleurs de domaine AD DS doit être configuré correctement pour prendre en charge Azure NetApp Files avec la connectivité réseau du contrôleur de domaine AD DS.
- Les groupes de sécurité réseau (NSG) et les pare-feu de contrôleurs de domaine AD DS doivent disposer de règles configurées de manière appropriée pour prendre en charge la connectivité d’Azure NetApp Files à AD DS et DNS.
- Vérifiez que la latence est inférieure à 10 ms de RTT entre Azure NetApp Files et les contrôleurs de domaine AD DS.
Les ports réseau requis sont les suivants :
| Service | Port | Protocole |
|---|---|---|
| Services web AD | 9389 | TCP |
| DNS* | 53 | TCP |
| DNS* | 53 | UDP |
| ICMPv4 | S/O | Réponse à écho |
| Kerberos | 464 | TCP |
| Kerberos | 464 | UDP |
| Kerberos | 88 | TCP |
| Kerberos | 88 | UDP |
| LDAP | 389 | TCP |
| LDAP | 389 | UDP |
| LDAP | 389 | TLS |
| LDAP | 3268 | TCP |
| Nom NetBIOS | 138 | UDP |
| SAM/LSA | 445 | TCP |
| SAM/LSA | 445 | UDP |
*DNS s’exécutant sur un contrôleur de domaine AD DS
Configuration requise du DNS
Les volumes Azure NetApp Files SMB, double protocole et Kerberos NFSv4.1 nécessitent un accès fiable aux services DNS (Domain Name System) et à des enregistrements DNS à jour. Une mauvaise connectivité réseau entre les serveurs Azure NetApp Files et DNS peut entraîner des interruptions d’accès client ou des dépassements des délais d’attente du client. Des enregistrements DNS incomplets ou incorrects pour AD DS ou Azure NetApp Files peuvent entraîner des interruptions d’accès client ou des dépassements des délais d’attente du client.
Azure NetApp Files prend en charge l’utilisation de serveurs DNS intégrés Active Directory ou de serveurs DNS autonomes.
Vérifiez que vous répondez aux exigences suivantes concernant les configurations DNS :
- Si vous utilisez des serveurs DNS autonomes :
- Vérifiez que les serveurs DNS disposent d’une connectivité réseau vers le sous-réseau délégué Azure NetApp Files hébergeant les volumes Azure NetApp Files.
- Vérifiez que les ports réseau UDP 53 et TCP 53 ne sont pas bloqués par des pare-feu ou des groupes de sécurité réseau.
- Vérifiez que les enregistrements SRV inscrits par le service d’ouverture de session AD DS Net ont été créés sur les serveurs DNS.
- Vérifiez que les enregistrements PTR des contrôleurs de domaine AD DS utilisés par Azure NetApp Files ont été créés sur les serveurs DNS dans le même domaine que votre configuration Azure NetApp Files.
- Azure NetApp Files ne supprime pas automatiquement les enregistrements de pointeur (PTR) associés aux entrées DNS lorsqu’un volume est supprimé. Les enregistrements PTR sont utilisés pour les recherches DNS inversées, qui mappent les adresses IP aux noms d’hôte. Ils sont généralement managés par l’administrateur du serveur DNS. Lorsque vous créez un volume dans Azure NetApp Files, vous pouvez l’associer à un nom DNS. Toutefois, la gestion des enregistrements DNS, y compris les enregistrements PTR, est en dehors de l’étendue d’Azure NetApp Files. Azure NetApp Files offre la possibilité d’associer un volume à un nom DNS pour faciliter l’accès, mais il ne gère pas les enregistrements DNS associés à ce nom. Si vous supprimez un volume dans Azure NetApp Files, les enregistrements DNS associés (tels que les enregistrements A pour le transfert de recherches DNS) doivent être gérés et supprimés du serveur DNS ou du service DNS que vous utilisez.
- Azure NetApp Files prend en charge les mises à jour DNS dynamiques standard et sécurisées. Si vous avez besoin de mises à jour DNS dynamiques sécurisées, vérifiez que les mises à jour sécurisées sont configurées sur les serveurs DNS.
- Si les mises à jour DNS dynamiques ne sont pas utilisées, vous devez créer manuellement un enregistrement A et un enregistrement PTR pour les comptes d’ordinateur AD DS créés dans l’Unité d’organisation AD DS (spécifiée dans la connexion AD Azure NetApp Files) pour prendre en charge la signature LDAP Azure NetApp Files, LDAP sur TLS, SMB, double protocole ou les volumes Kerberos NFSv4.1.
- Pour les topologies AD DS complexes ou volumineuses, les stratégies DNS ou la hiérarchisation de sous-réseaux DNS peuvent être nécessaires pour prendre en charge les volumes NFS compatibles LDAP.
Exigences relatives à la source de temps
Azure NetApp Files utilise time.windows.com en tant que source de temps. Vérifiez que les contrôleurs de domaine utilisés par Azure NetApp Files sont configurés pour utiliser time.windows.com ou une autre source de temps racine stable (couche 1) précise. S’il existe une asymétrie de plus de cinq minutes entre Azure NetApp Files et votre client ou les contrôleurs de domaine AD DS, l’authentification échoue et l’accès aux volumes Azure NetApp Files peut également échouer.
Déterminez les services AD DS à utiliser avec Azure NetApp Files
Azure NetApp Files prend en charge à la fois Active Directory Domain Services (AD DS) et Microsoft Entra Domain Services pour les connexions AD. Avant de créer une connexion AD, vous devez décider s’il faut utiliser AD DS ou Microsoft Entra Domain Services.
Pour plus d’informations, consultez Comparer les Active Directory Domain Services autogérés, Microsoft Entra ID et les Microsoft Entra Domain Services gérés.
Considérations liées à Active Directory Domain Services
Vous devez utiliser Active Directory Domain Services (AD DS) dans les scénarios suivants :
- Vous avez des utilisateurs AD DS hébergés dans un domaine AD DS local qui ont besoin d’accéder à des ressources Azure NetApp Files.
- Vous avez des applications hébergées partiellement localement et partiellement dans Azure qui ont besoin d’accéder à des ressources Azure NetApp Files.
- Vous n’avez pas besoin de l’intégration de Microsoft Entra Domain Services avec un locataire Microsoft Entra dans votre abonnement, ou Microsoft Entra Domain Services est incompatible avec vos exigences techniques.
Remarque
Azure NetApp Files ne prend pas en charge l’utilisation des contrôleurs de domaines en lecture seul (RODC) AD DS.
Si vous choisissez d’utiliser AD DS avec Azure NetApp Files, suivez les instructions du Guide d’extension d’AD DS dans l’architecture Azure et vérifiez que vous répondez aux exigences de réseau et DNS d’Azure NetApp Files pour AD DS.
Considérations relatives à Microsoft Entra Domain Services
Microsoft Entra Domain Services est un domaine AD DS managé qui est synchronisé avec votre locataire Microsoft Entra. Les principaux avantages de l’utilisation de Microsoft Entra Domain Services sont les suivants :
- Microsoft Entra Domain Services est un domaine autonome. Par conséquent, il n’est pas nécessaire de configurer la connectivité réseau entre Azure et local.
- Assure une expérience simplifiée de déploiement et de gestion.
Vous devez utiliser Microsoft Entra Domain Services dans les scénarios suivants :
- Il n’est pas nécessaire d’étendre AD DS d’un environnement local dans Azure pour fournir l’accès aux ressources Azure NetApp Files.
- Vos stratégies de sécurité n’autorisent pas l’extension d’AD DS local dans Azure.
- Vous n’avez pas de connaissances solides sur AD DS. Microsoft Entra Domain Services peut améliorer la probabilité d’obtenir de bons résultats avec Azure NetApp Files.
Si vous choisissez d’utiliser Microsoft Entra Domain Services avec Azure NetApp Files, consultez la documentation de Microsoft Entra Domain Services pour obtenir des conseils sur l’architecture, le déploiement et la gestion. Assurez-vous également de répondre aux exigences réseau et DNS d’Azure NetApp Files.
Concevoir une topologie de site AD DS à utiliser avec Azure NetApp Files
Une conception appropriée pour la topologie de site AD DS est essentielle pour toute architecture de solution qui implique des volumes Azure NetApp Files SMB, protocole double ou Kerberos NFSv4.1.
Une mauvaise topologie ou configuration de site AD DS peut entraîner les comportements suivants :
- Échec de création de volumes Azure NetApp Files SMB, protocole double ou Kerberos NFSv4.1
- Échec de modification de la configuration de la connexion ANF AD
- Mauvaises performances des requêtes client LDAP
- Problèmes d’authentification
Une topologie de site AD DS pour Azure NetApp Files est une représentation logique du réseau Azure NetApp Files. La conception d’une topologie de site AD DS pour Azure NetApp Files implique la planification du placement du contrôleur de domaine, la conception de sites, l’infrastructure DNS et les sous-réseaux pour garantir une bonne connectivité entre le service Azure NetApp Files, les clients de stockage Azure NetApp Files et les contrôleurs de domaine AD DS.
En plus de plusieurs contrôleurs de domaine attribués au site AD DS configuré dans le Nom du site AD Azure NetApp Files, un ou plusieurs sous-réseaux peuvent être attribués au site Azure NetApp Files AD DS.
Remarque
Il est essentiel que tous les contrôleurs de domaine et sous-réseaux attribués au site AD DS Azure NetApp Files soient bien connectés (latence RTT inférieure à 10 ms) et accessibles par les interfaces réseau utilisées par les volumes Azure NetApp Files.
Si vous utilisez des fonctionnalités réseau Standard, vous devriez vous assurer que les règles concernant les itinéraires définis par l’utilisateur (UDR) ou les groupes de sécurité réseau (NSG) ne bloquent pas la communication réseau d’Azure NetApp Files avec les contrôleurs de domaine AD DS attribués au site AD DS Azure NetApp Files.
Si vous utilisez des appliances virtuelles réseau ou des pare-feux (comme Palo Alto Networks ou Fortinet), ils doivent être configurés pour ne pas bloquer le trafic réseau entre Azure NetApp Files et les contrôleurs de domaine AD DS et les sous-réseaux attribués au site AD DS Azure NetApp Files.
Utilisation des informations de site AD DS Azure NetApp Files
Azure NetApp Files utilise le nom de site AD configuré dans les connexions Active Directory pour découvrir quels contrôleurs de domaine sont présents pour prendre en charge l’authentification, la jointure de domaines, les requêtes LDAP et les opérations de ticket Kerberos.
Détection de contrôleur de domaine AD DS
Azure NetApp Files lance la détection de contrôleur de domaine toutes les quatre heures. Azure NetApp Files interroge l’enregistrement de ressource du service DNS spécifique au site (SRV) pour déterminer quels contrôleurs de domaine se trouvent dans le site AD DS spécifié dans le champ Nom du site AD de la connexion Azure NetApp Files AD. La détection du serveur du contrôleur de domaine Azure NetApp Files vérifie l’état des services hébergés sur les contrôleurs de domaine (tels que Kerberos, LDAP, Net Logon et LSA) et sélectionne le contrôleur de domaine optimal pour les demandes d’authentification.
Les enregistrements de ressources du service DNS (SRV) pour le site AD DS spécifié dans le champ Nom du site AD de la connexion Azure NetApp Files AD doivent contenir la liste des adresses IP des contrôleurs de domaine AD DS qui seront utilisés par Azure NetApp Files. Vous pouvez vérifier la validité de l’enregistrement de ressource (SRV) DNS à l’aide de l’utilitaire nslookup.
Remarque
Si vous apportez des modifications aux contrôleurs de domaine sur le site AD DS utilisé par Azure NetApp Files, attendez au moins quatre heures entre le déploiement de nouveaux contrôleurs de domaine AD DS et la mise hors service des contrôleurs de domaine AD DS existants. Ce temps d’attente permet à Azure NetApp Files de détecter les nouveaux contrôleurs de domaine AD DS.
Vérifiez que les enregistrements DNS obsolètes associés au contrôleur de domaine AD DS mis hors service sont supprimés du DNS. Cela garantit qu’Azure NetApp Files ne tentera pas de communiquer avec le contrôleur de domaine hors service.
Détection de serveur LDAP AD DS
Un processus de détection distinct pour les serveurs LDAP AD DS se produit lorsque LDAP est activé pour un volume Azure NetApp Files NFS. Lorsque le client LDAP est créé sur Azure NetApp Files, Azure NetApp Files interroge l’enregistrement de ressource du service de domaine AD DS (SRV) pour obtenir la liste de tous les serveurs LDAP AD DS dans le domaine et non les serveurs LDAP AD DS affectés au site AD DS spécifié dans la connexion AD.
Pour les topologies AD DS volumineuses ou complexes, vous devrez peut-être implémenter des stratégies DNS ou des hiérarchies de sous-réseaux DNS pour vous assurer que les serveurs LDAP AD DS affectés au site AD DS spécifiés dans la connexion AD sont retournés.
Vous pouvez également remplacer le processus de découverte de serveur LDAP AD DS en spécifiant jusqu’à deux serveurs AD préférés pour le client LDAP.
Important
Si Azure NetApp Files ne peut pas atteindre un serveur LDAP AD DS détecté lors de la création du client LDAP Azure NetApp Files, la création du volume activé LDAP échoue.
Conséquences d’une configuration incorrecte ou incomplète du nom du site AD
Une topologie ou une configuration de site AD DS incorrecte ou incomplète peut entraîner des échecs de création de volume, des problèmes liés aux requêtes clientes, des échecs d’authentification et des échecs de modification des connexions Azure NetApp Files AD.
Important
Le champ Nom du site AD est requis pour créer une connexion AD Azure NetApp Files. Le site AD DS défini doit exister et être correctement configuré.
Azure NetApp Files utilise le site AD DS pour découvrir les contrôleurs de domaine et les sous-réseaux affectés au site AD DS défini dans Nom du site AD. Tous les contrôleurs de domaine affectés au site AD DS doivent disposer d’une bonne connectivité réseau à partir des interfaces de réseau virtuel Azure utilisées par ANF, et être accessibles. Les machines virtuelles contrôleurs de domaine AD DS affectées au site AD DS qui sont utilisées par Azure NetApp Files doivent être exclues des stratégies de gestion des coûts qui arrêtent les machines virtuelles.
Si Azure NetApp Files n’est pas en mesure d’atteindre les contrôleurs de domaine attribués au site AD DS, le processus de détection du contrôleur de domaine interroge le domaine AD DS pour obtenir une liste de tous les contrôleurs de domaine. La liste des contrôleurs de domaine retournés par cette requête est une liste non triée. Par conséquent, Azure NetApp Files peut essayer d’utiliser des contrôleurs de domaine qui ne sont pas accessibles ou correctement connectés, ce qui peut entraîner des échecs de création de volume, des problèmes avec les requêtes des clients, des échecs d’authentification et de modification des connexions AD Azure NetApp Files.
Vous devez mettre à jour la configuration du site AD DS chaque fois que de nouveaux contrôleurs de domaine sont déployés dans un sous-réseau affecté au site AD DS utilisé par la connexion AD Azure NetApp Files. Vérifiez que les enregistrements SRV DNS du site reflètent les modifications apportées aux contrôleurs de domaine affectés au site AD DS utilisé par Azure NetApp Files. Vous pouvez vérifier la validité de l’enregistrement de ressource (SRV) DNS à l’aide de l’utilitaire nslookup.
Remarque
Azure NetApp Files ne prend pas en charge l’utilisation des contrôleurs de domaines en lecture seul (RODC) AD DS. Pour empêcher Azure NetApp Files d’utiliser un RODC, ne configurez pas le champ Nom du site AD des connexions AD avec un RODC.
Exemple de configuration de topologie de site AD DS pour Azure NetApp Files
Une topologie de site AD DS est une représentation logique du réseau où Azure NetApp Files est déployé. Dans cette section, l’exemple de scénario de configuration pour la topologie de site AD DS vise à montrer une conception de site AD DS de base pour Azure NetApp Files. Il ne s’agit pas du seul moyen de concevoir une topologie de réseau ou de site AD pour Azure NetApp Files.
Important
Pour les scénarios qui impliquent des topologies AD DS ou de réseau complexes, demandez à un CSA Microsoft Azure d’examiner la mise en réseau Azure NetApp Files et la conception du site AD.
Le diagramme suivant illustre un exemple de topologie de réseau : sample-network-topology.png 
Dans l’exemple de topologie de réseau, un domaine AD DS local (anf.local) est étendu dans un réseau virtuel Azure. Le réseau local est connecté au réseau virtuel Azure à l’aide d’un circuit Azure ExpressRoute.
Le réseau virtuel Azure comprend quatre sous-réseaux : sous-réseau de passerelle, sous-réseau Azure Bastion, sous-réseau AD DS et sous-réseau délégué Azure NetApp Files. Les contrôleurs de domaine AD DS redondants joints au domaine anf.local sont déployés dans le sous-réseau AD DS. Le sous-réseau AD DS est affecté à la plage d’adresses IP 10.0.0.0/24.
Azure NetApp Files ne peut utiliser qu’un seul site AD DS pour déterminer quels contrôleurs de domaine seront utilisés pour l’authentification, les requêtes LDAP et Kerberos. Dans l’exemple de scénario, deux objets de sous-réseau sont créés et affectés à un site appelé ANF à l’aide de l’utilitaire Sites et services Active Directory. Un objet de sous-réseau est mappé au sous-réseau AD DS (10.0.0.0/24) et l’autre objet de sous-réseau est mappé au sous-réseau délégué ANF (10.0.2.0/24).
Dans l’outil Sites et services Active Directory, vérifiez que les contrôleurs de domaine AD DS déployés dans le sous-réseau AD DS sont affectés au site ANF :
Pour créer l’objet de sous-réseau qui mappe vers le sous-réseau AD DS dans le réseau virtuel Azure, cliquez avec le bouton droit sur le conteneur Sous-réseaux dans l’utilitaire Sites et services Active Directory, puis sélectionnez Nouveau sous-réseau....
Dans la boîte de dialogue Nouvel objet - Sous-réseau, la plage d’adresses IP 10.0.0.0/24 du sous-réseau AD DS est entrée dans le champ Préfixe. Sélectionnez ANF comme objet de site pour le sous-réseau. Sélectionnez OK pour créer l’objet de sous-réseau et l’affecter au site ANF.
Pour vérifier que le nouvel objet de sous-réseau est affecté au site approprié, cliquez avec le bouton droit sur l’objet de sous-réseau 10.0.0.0/24, puis sélectionnez Propriétés. Le champ Site doit afficher l’objet de site ANF :
Pour créer l’objet de sous-réseau qui mappe vers le sous-réseau délégué Azure NetApp Files dans le réseau virtuel Azure, cliquez avec le bouton droit sur le conteneur Sous-réseaux dans l’utilitaire Sites et services Active Directory, puis sélectionnez Nouveau sous-réseau....
Considérations relatives à la réplication interrégion
La réplication interrégion Azure NetApp Files vous permet de répliquer des volumes Azure NetApp Files d’une région vers une autre région pour prendre en charge les exigences de continuité d’activité et de récupération d’urgence (BC/DR).
Les volumes Azure NetApp Files SMB, protocole double et Kerberos NFSv4.1 prennent en charge la réplication interrégion. La réplication de ces volumes nécessite les éléments suivants :
- Un compte NetApp créé à la fois dans la région source et celle de destination.
- Une connexion Azure NetApp Files Active Directory dans le compte NetApp créé dans les régions source et de destination.
- Contrôleurs de domaine AD DS déployés et en cours d’exécution dans la région de destination.
- Réseau Azure NetApp Files, DNS et conception de site AD DS adéquats déployés dans la région de destination pour assurer une bonne communication réseau d’Azure NetApp Files avec les contrôleurs de domaine AD DS dans la région de destination.
- Connexion Active Directory dans la région de destination configurée pour utiliser les ressources DNS et de site AD dans la région de destination.
Étapes suivantes
- Créer et gérer des connexions Active Directory
- Modifier des connexions Active Directory
- Activer l’authentification LDAP AD DS pour les volumes NFS
- Créer un volume SMB
- Créer un volume à deux protocoles
- Erreurs pour les volumes SMB et double protocole
- Accéder aux volumes SMB à partir de machines virtuelles Windows jointes à Microsoft Entra