Vue d’ensemble de l’authentification basée sur l’identité Azure Files d’un accès SMB
Cet article explique comment vous pouvez utiliser l’authentification basée sur l’identité, localement ou dans Azure, pour activer un accès basé sur l’identité aux partages de fichiers Azure via SMB. Comme les serveurs de fichiers Windows, vous pouvez octroyer des autorisations à une identité au niveau du partage, du répertoire ou du fichier. L’activation d’une authentification basée sur l’identité sur votre compte de stockage n’engendre pas de frais de service supplémentaires.
L’authentification basée sur l’identité n’est actuellement pas prise en charge avec les partages NFS (Network File System). Toutefois, il est disponible par SMB pour les clients Windows et Linux.
Pour des raisons de sécurité, il est recommandé d’utiliser l’authentification basée sur l’identité pour accéder aux partages de fichiers plutôt que d’utiliser la clé de compte de stockage.
Important
Ne partagez jamais vos clés de compte de stockage. Utiliser plutôt l’authentification basée sur l’identité.
Fonctionnement
Les partages de fichiers Azure utilisent le protocole Kerberos pour s’authentifier auprès d’une source d’identité. Quand une identité associée à un utilisateur ou une application s’exécutant sur un client tente d’accéder à des données se trouvant dans des partages de fichiers Azure, la requête est envoyée à la source d’identité pour authentifier l’identité. Si l’authentification réussit, la source d’identité retourne un ticket Kerberos. Le client envoie alors une requête qui inclut le ticket Kerberos. Azure Files utilise ce ticket pour autoriser la requête. Le service Azure Files reçoit uniquement le ticket Kerberos, et non les informations d’identification d’accès de l’utilisateur.
Cas d’utilisation courants
L’authentification basée sur l’identité avec des partages de fichiers Azure SMB peut être utile dans plusieurs scénarios :
Remplacer des serveurs de fichiers locaux
Le remplacement de serveurs de fichiers locaux dispersés est un défi que chaque organisation rencontre dans son parcours de modernisation informatique. L’utilisation de l’authentification basée sur l’identité avec Azure Files offre une expérience de migration transparente, ce qui permet aux utilisateurs finaux de continuer à accéder à leurs données avec les mêmes informations d’identification.
Migration lift-and-shift des applications vers Azure
Quand vous transférez et déplacez des applications vers le cloud, vous souhaitez probablement conserver le même modèle d’authentification pour accéder au partage de fichiers. L’authentification basée sur l’identité élimine la nécessité de modifier votre service d’annuaire et accélère l’adoption du cloud.
Sauvegarde et récupération d’urgence (DR)
Si vous conservez votre stockage de fichiers principal localement, Azure Files est une solution de sauvegarde ou de récupération d’urgence idéale pour améliorer la continuité des activités. Vous pouvez utiliser des partages de fichiers Azure pour sauvegarder vos serveurs de fichiers, tout en conservant les listes de contrôle d’accès discrétionnaire (DACL) Windows. Pour les scénarios de récupération d’urgence, vous pouvez configurer une option d’authentification pour prendre en charge l’application d’un contrôle d’accès approprié au moment du basculement.
Choisir une source d’identité pour votre compte de stockage
Avant d’activer l’authentification basée sur l’identité sur votre compte de stockage, vous devez connaître la source d’identité que vous allez utiliser. Il est probable que vous en ayez déjà une, car la plupart des entreprises et organisations ont configuré un certain type d’environnement de domaine. Consultez votre administrateur Active Directory (AD) ou informatique pour en être sûr. Si vous n’avez pas encore de source d’identité, vous devez en configurer une avant de pouvoir activer l’authentification basée sur l’identité.
Scénarios d’authentification pris en charge
Vous pouvez activer l’authentification basée sur l’identité via SMB à l’aide de l’une des trois sources d’identité suivantes : Active Directory Domain Services (AD DS) localement, Microsoft Entra Domain Services ou Microsoft Entra Kerberos (identités hybrides uniquement). Vous ne pouvez utiliser qu’une seule source d’identité pour l’authentification d’accès aux fichiers par compte de stockage et elle s’applique à tous les partages de fichiers du compte.
AD DS localement : des clients et des machines virtuelles AD DS locaux peuvent accéder à des partages de fichiers Azure avec des informations d’identification Active Directory locales. L’environnement local AD DS doit être synchronisé avec Microsoft Entra ID à l’aide de l’application locale Microsoft Entra Connect ou d’une synchronisation cloud Microsoft Entra Connect, un agent léger qui peut être installé à partir du Centre d’administration Microsoft Entra. Pour utiliser cette méthode d’authentification, votre client doit être joint à un domaine ou disposer d’une connectivité réseau non bloquée à votre AD DS. Consultez la liste complète des conditions préalables.
Microsoft Entra Kerberos pour les identités hybrides : vous pouvez utiliser Microsoft Entra ID pour authentifier des identités utilisateur hybrides, ce qui permet aux utilisateurs finaux d’accéder aux partages de fichiers Azure sans avoir besoin d’une connectivité réseau aux contrôleurs de domaine. Cette option nécessite un déploiement AD DS existant, qui est ensuite synchronisé avec votre locataire Microsoft Entra de sorte que Microsoft Entra ID puisse authentifier vos identités hybrides. Les identités uniquement cloud ne sont actuellement pas prises en charge à l’aide de cette méthode. Consultez la liste complète des conditions préalables.
Microsoft Entra Domain Services : les machines virtuelles informatiques jointes à Microsoft Entra Domain Services peuvent accéder aux partages de fichiers Azure avec des informations d’identification Microsoft Entra. Dans cette solution, Microsoft Entra ID exécute un domaine Windows Server AD traditionnel qui est un enfant du locataire Microsoft Entra du client. Microsoft Entra Domain Services est actuellement la seule option d’authentification des identités cloud uniquement. Consultez la liste complète des conditions préalables.
Suivez les indications suivantes pour déterminer la source d’identité que vous devez choisir.
Si votre organisation dispose déjà d’une instance AD locale et n’est pas prête à déplacer des identités vers le cloud, et si vos clients, machines virtuelles et applications sont joints à un domaine ou ont une connectivité réseau non bloquée à ces contrôleurs de domaine, choisissez AD DS.
Si certains ou tous les clients ne disposent pas d’une connectivité réseau non bloquée à votre AD DS, ou si vous stockez des profils FSLogix sur des partages de fichiers Azure pour des machines virtuelles jointes à Microsoft Entra, choisissez Microsoft Entra Kerberos.
Si vous disposez d’une instance AD locale existante, mais que vous envisagez de déplacer des applications vers le cloud et souhaitez que vos identités existent à la fois localement et dans le cloud, choisissez Microsoft Entra Kerberos.
Si vous n’avez pas de source d’identité existante, si vous devez authentifier des identités cloud uniquement, ou si vous utilisez déjà Microsoft Entra Domain Services, choisissez Microsoft Entra Domain Services. Si vous n’avez pas encore déployé de service de domaine dans Azure, vous remarquerez de nouveaux frais sur votre facture Azure pour ce service.
Ajouter une source d'identité
Une fois la source d’identité choisie, vous devez l’activer sur votre compte de stockage.
AD DS
Pour l’authentification AD DS, vous devez joindre un domaine à vos machines clientes ou machines virtuelles. Vous pouvez héberger vos contrôleurs de domaine AD sur des machines virtuelles Azure ou localement. Dans les deux cas, vos clients joints à un domaine doivent disposer d’une connectivité réseau sans entrave au contrôleur de domaine : ils doivent donc se trouver dans le réseau virtuel (VNet) ou dans le réseau d’entreprise de votre service de domaine.
Le diagramme suivant illustre l’authentification AD DS locale pour l’accès aux partages de fichiers Azure sur SMB. Les services AD DS locaux doivent être synchronisés avec Microsoft Entra ID à l’aide de la synchronisation Microsoft Entra Connect ou de la synchronisation cloud Microsoft Entra Connect. Seuls les identités utilisateur hybrides, qui existent à la fois dans AD DS local et Microsoft Entra ID, peuvent être authentifiés et autorisés à accéder aux partages de fichiers Azure. Cela est dû au fait que l’autorisation au niveau du partage est configurée par rapport à l’identité représentée dans Microsoft Entra ID, alors que l’autorisation au niveau du répertoire/fichier est appliquée avec elle dans AD DS. Veillez à configurer correctement les autorisations pour le même utilisateur hybride.
Pour activer l’authentification AD DS, commencez par consulter Vue d’ensemble - Authentification locale Active Directory Domain Services via SMB pour des partages de fichiers Azure, puis Activer l’authentification AD DS pour des partages de fichiers Azure.
Kerberos Microsoft Entra pour les identités hybrides
L’activation et la configuration de Microsoft Entra ID pour l’authentification des identités utilisateur hybrides permettent aux utilisateurs de Microsoft Entra d’accéder aux partages de fichiers Azure à l’aide de l’authentification Kerberos. Cette configuration utilise Microsoft Entra ID pour émettre les tickets Kerberos permettant d’accéder au partage de fichiers avec le protocole SMB standard du secteur d’activité. Cela signifie que les utilisateurs finaux peuvent accéder à des partages de fichiers Azure sans avoir besoin d’une connectivité réseau aux contrôleurs de domaine des machines virtuelles jointes à Microsoft Entra de façon classique ou hybride. Cependant, la configuration d’autorisations au niveau des répertoires et des fichiers pour des utilisateurs ou des groupes nécessite une connectivité réseau sans entrave au contrôleur de domaine local.
Important
L’authentification Kerberos Microsoft Entra prend uniquement en charge les identités utilisateur hybrides. Elle ne prend pas en charge les identités cloud uniquement. Un déploiement AD DS traditionnel est requis et doit être synchronisé avec Microsoft Entra ID à l’aide de la synchronisation Microsoft Entra Connect ou de la synchronisation cloud Microsoft Entra Connect. Les clients doivent être joints à Microsoft Entra ou à Microsoft Entra hybride. Microsoft Entra Kerberos n’est pas pris en charge sur les clients joints à Microsoft Entra Domain Services ou joints à AD uniquement.
Pour activer l’authentification Microsoft Entra Kerberos pour des identités hybrides, consultez Activer l’authentification Microsoft Entra Kerberos pour des identités hybrides sur Azure Files.
Vous pouvez également utiliser cette fonctionnalité pour stocker des profils FSLogix sur des partages de fichiers Azure pour les machines virtuelles jointes à Microsoft Entra. Pour plus d’informations, consultez Créer un conteneur de profil avec Azure Files and Microsoft Entra ID.
Microsoft Entra Domain Services
Pour l’authentification Microsoft Entra Domain Services, vous devez activer Microsoft Entra Domain Services et joindre à un domaine les machines virtuelles à partir desquelles vous prévoyez d’accéder aux données de fichier. Votre machine virtuelle jointe à un domaine doit résider dans le même réseau virtuel que le domaine hébergé Microsoft Entra Domain Services.
Le diagramme suivant illustre le flux de travail de l’authentification Microsoft Entra Domain Services pour l’accès aux partages de fichiers Azure via SMB. Il suit un modèle similaire à l’authentification AD DS locale, mais il existe deux différences importantes :
Vous n’avez pas besoin de créer une identité dans Microsoft Entra Domain Services pour représenter le compte de stockage. Cette opération est effectuée par le processus d’activation en arrière-plan.
Tous les utilisateurs qui existent dans Microsoft Entra ID peuvent être authentifiés et autorisés. Les utilisateurs peuvent être de type cloud uniquement ou hybride. La synchronisation de Microsoft Entra ID vers Microsoft Entra Domain Services est gérée par la plateforme sans nécessiter de configuration utilisateur. Toutefois, le client doit être joint au domaine hébergé par Microsoft Entra Domain Services. Il ne peut pas être joint ou inscrit à Microsoft Entra. Microsoft Entra Domain Services ne prend pas en charge les clients non Azure (c’est-à-dire les ordinateurs portables utilisateur, les stations de travail, les machines virtuelles d’autres clouds, etc.) qui sont jointes au domaine hébergé Microsoft Entra Domain Services. Toutefois, il est possible de monter un partage de fichiers à partir d’un client non joint à un domaine en fournissant des informations d’identification explicites telles que NOM_DOMAINE\nom_utilisateur ou en utilisant le nom de domaine complet (nom_utilisateur@FQDN).
Pour activer l’authentification Microsoft Entra Domain Services, consultez Activer l’authentification Microsoft Entra Domain Services sur Azure Files.
Autorisation et contrôle d’accès
Quelle que soit la source d’identité que vous choisissez, une fois activée, vous devez configurer l’autorisation. Azure Files applique l’autorisation d’accès de l’utilisateur à la fois au niveau du partage et aux niveaux du répertoire/fichier.
Vous pouvez attribuer des autorisations au niveau du partage à des utilisateurs ou groupes Microsoft Entra managés via Azure RBAC. Avec Azure RBAC, les informations d’identification que vous utilisez pour l’accès aux fichiers doivent être disponibles ou synchronisées avec Microsoft Entra ID. Vous pouvez attribuer des rôles Azure intégrés tels que Lecteur de partage SMB de données de fichier de stockage à des utilisateurs ou groupes dans Microsoft Entra ID pour leur permettre d’accéder à un partage de fichiers.
Au niveau du répertoire/fichier, Azure Files prend en charge la conservation, l’héritage et l’application des listes de contrôle d’accès Windows. Vous pouvez choisir de conserver les ACL Windows lors de la copie de données via SMB entre votre partage de fichiers existant et vos partages de fichiers Azure. Que vous ayez l’intention ou non d’appliquer l’autorisation, vous pouvez utiliser les partages de fichiers Azure pour sauvegarder des listes de contrôle d’accès ainsi que vos données.
Configurer des autorisations au niveau du partage
Une fois la source d’identité activée sur votre compte de stockage, vous devez effectuer l’une des opérations suivantes pour accéder au partage de fichiers :
- Définir une autorisation au niveau du partage par défaut qui s’applique à tous les utilisateurs et groupes authentifiés
- Attribuer des rôles RBAC intégrés à Azure aux utilisateurs et aux groupes, ou
- Configurer des rôles personnalisés pour les identités Microsoft Entra et attribuer des droits d’accès aux partages de fichiers dans votre compte de stockage.
L’autorisation attribuée au niveau du partage permet à l’identité concernée d’obtenir l’accès au partage uniquement, mais pas au répertoire racine. Vous devez toujours configurer séparément les autorisations au niveau du répertoire et du fichier.
Remarque
Vous ne pouvez pas attribuer d’autorisations au niveau du partage aux comptes d’ordinateur (comptes de machines) à l’aide du contrôle d’accès en fonction du rôle (RBAC) Azure, car les comptes d’ordinateur ne peuvent pas être synchronisés avec une identité dans Microsoft Entra ID. Si vous souhaitez autoriser un compte d’ordinateur à accéder aux partages de fichiers Azure à l’aide de l’authentification basée sur l’identité, utilisez une autorisation de niveau partage par défaut ou envisagez d’utiliser un compte de connexion au service à la place.
Configurer des autorisations au niveau du répertoire ou du fichier
Les partages de fichiers Azure appliquent des listes de contrôle d’accès Windows standard à la fois au niveau du répertoire et du fichier, notamment au niveau du répertoire racine. La configuration des autorisations au niveau du répertoire ou du fichier est prise en charge sur SMB et REST. Montez le partage de fichiers cible à partir de votre machine virtuelle, et configurez des autorisations à l’aide de l’Explorateur de fichiers Windows, de la commande Windows icacls ou de la commande Set-ACL.
Conserver les ACL de répertoire et de fichier lors de l’importation de données dans Azure Files
Azure Files prend en charge la conservation des ACL de répertoire ou de fichier lors de la copie de données vers des partages de fichiers Azure. Vous pouvez copier des listes de contrôle d’accès (ACL) d’un répertoire ou d’un fichier vers des partages de fichiers Azure à l’aide d’Azure File Sync ou d’outils de déplacement de fichiers communs. Par exemple, vous pouvez utiliser robocopy avec l’étiquette /copy:s pour copier des données et des ACL vers un partage de fichiers Azure. Les listes de contrôle d’accès étant conservées par défaut, il n’est pas nécessaire d’activer l’authentification basée sur l’identité sur votre compte de stockage pour les conserver.
Glossaire
Vous devez comprendre certains termes clés relatifs à l’authentification basée sur l’identité Azure AD pour le partage de fichiers Azure :
Authentification Kerberos
Kerberos est un protocole d’authentification utilisé pour vérifier l’identité d’un utilisateur ou d’un hôte. Pour plus d’informations sur Kerberos, consultez Vue d’ensemble de l’authentification Kerberos.
Protocole SMB (Server Message Block)
SMB est un protocole de partage de fichier réseau standard. Pour plus d’informations sur SMB, consultez Vue d’ensemble du protocole SMB et du protocole CIFS de Microsoft.
Microsoft Entra ID
Microsoft Entra ID (anciennement Azure AD) est le service cloud de gestion des identités et des annuaires informatiques multilocataires de Microsoft. Microsoft Entra ID associe des services d’annuaires principaux, la gestion de l’accès aux applications et la protection des identités dans une même solution.
Microsoft Entra Domain Services
Microsoft Entra Domain Services fournit des services de domaine gérés, comme la jonction de domaine, les stratégies de groupe, le protocole LDAP et l’authentification Kerberos/NTLM. Ces services sont entièrement compatibles avec Active Directory Domain Services. Pour plus d’informations, consultez Microsoft Entra Domain Services.
Active Directory Domain Services (AD DS) en local
AD DS est couramment adopté par des entreprises dans des environnements locaux ou des machines virtuelles hébergées dans le cloud. Les informations d’identification AD DS sont utilisées pour le contrôle d’accès. Pour plus d’informations, voir Présentation des services de domaine Active Directory.
Contrôle d’accès en fonction du rôle Azure (Azure RBAC)
RBAC Azure permet une gestion fine des accès pour Azure. Grâce à Azure RBAC, vous pouvez gérer l’accès aux ressources en accordant aux utilisateurs les autorisations minimales dont ils ont besoin pour effectuer leur travail. Pour plus d’informations, consultez Qu’est-ce que le contrôle d’accès en fonction du rôle Azure ?
Identités hybrides
Les identités utilisateur hybrides sont des identités d’AD DS qui sont synchronisées avec Microsoft Entra ID, soit via l’application locale de synchronisation Microsoft Entra Connect, soit via la synchronisation cloud Microsoft Entra Connect, un agent léger qui peut être installé à partir du Centre d’administration Microsoft Entra.
Étape suivante
Pour plus d’informations, consultez l’article suivant :