Vue d’ensemble de l’authentification basée sur l’identité Azure Files d’un accès SMB

S’applique à : ✔️ partages de fichiers Azure SMB

Cet article explique comment utiliser l’authentification basée sur l’identité, localement ou dans Azure, pour activer l’accès basé sur l’identité aux partages de fichiers Azure via le protocole SMB (Server Message Block). 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é est prise en charge sur SMB pour les clients Windows, Linux et MacOS. Cependant, il n'est actuellement pas pris en charge avec les partages NFS (Network File System).

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é sur SMB à l’aide de l’une des trois sources d’identité : Active Directory Domain Services (AD DS) local, Microsoft Entra Domain Services ou Microsoft Entra Kerberos. 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 local : Le compte de stockage est joint aux services AD DS locaux et les identités d’AD DS peuvent accéder en toute sécurité aux partages de fichiers Azure SMB à partir d’un client joint à un domaine ou d’un client qui dispose d’une connectivité ininterrompue au contrôleur de domaine. 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. Consultez la liste complète des conditions préalables.

• Microsoft Entra Kerberos : Vous pouvez utiliser l’ID Microsoft Entra pour authentifier des identités hybrides ou cloud uniquement (préversion), ce qui permet aux utilisateurs finaux d’accéder aux partages de fichiers Azure. Si vous souhaitez authentifier des identités hybrides, vous aurez besoin d’un déploiement AD DS existant, qui est ensuite synchronisé avec votre locataire Microsoft Entra. Consultez les 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. Consultez les 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’un AD local existant, mais envisagez de déplacer des applications vers le cloud et que vous souhaitez que vos identités existent à la fois localement et dans le cloud (hybride), choisissez Microsoft Entra Kerberos.

• Si vous souhaitez authentifier des identités cloud uniquement sans utiliser de contrôleurs de domaine, choisissez Microsoft Entra Kerberos. Actuellement, cette fonctionnalité est uniquement disponible en tant que version préliminaire.

• Si vous utilisez déjà Microsoft Entra Domain Services, choisissez Microsoft Entra Domain Services comme source d’identité.

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 pouvez héberger vos contrôleurs de domaine AD sur des machines virtuelles Azure ou localement. De toute façon, vos clients doivent disposer d’une connectivité réseau non limitée au contrôleur de domaine. Ils doivent donc se trouver dans le réseau d’entreprise ou le réseau virtuel de votre service de domaine. Nous vous recommandons de joindre un domaine à vos machines clientes ou machines virtuelles afin que les utilisateurs n’aient pas à fournir d’informations d’identification explicites chaque fois qu’ils accèdent au partage.

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.

Microsoft Entra Kerberos

L’activation et la configuration de l’ID Microsoft Entra pour l’authentification des identités hybrides ou cloud uniquement (préversion) permet 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 aux partages de fichiers Azure sans nécessiter de connectivité réseau aux contrôleurs de domaine.

Le diagramme suivant représente le flux de travail de l’authentification Microsoft Entra Kerberos pour les identités hybrides (et non cloud uniquement) sur SMB.

Pour activer l’authentification Microsoft Entra Kerberos, consultez Activer l’authentification Microsoft Entra Kerberos 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.

Services de domaine Microsoft Entra

Pour l’authentification Microsoft Entra Domain Services, vous devez activer Microsoft Entra Domain Services et joindre le domaine aux machines virtuelles qui accèdent aux partages de fichiers Azure à l’aide de l’authentification Kerberos. Ces machines virtuelles doivent disposer d’une connectivité réseau au domaine managé Microsoft Entra Domain Services.

Le flux d’authentification est similaire à l’authentification AD DS locale, avec les différences suivantes :

• L’identité du compte de stockage est créée automatiquement pendant l’activation.
• Tous les utilisateurs microsoft Entra ID peuvent être authentifiés et autorisés. Les utilisateurs peuvent être de type cloud uniquement ou hybride. La synchronisation des utilisateurs à partir de l’ID Microsoft Entra vers Microsoft Entra Domain Services est gérée par la plateforme.

Conditions d’accès pour Microsoft Entra Domain Services

Pour que les clients s’authentifient à l’aide de Microsoft Entra Domain Services, les conditions suivantes doivent être remplies.

• L’authentification Kerberos nécessite que le client soit joint au domaine managé Microsoft Entra Domain Services.
• Les clients non-Azure ne peuvent pas être rattachés au domaine géré Microsoft Entra Domain Services.
• Les clients qui ne sont pas joints à un domaine peuvent toujours accéder aux partages de fichiers Azure à l’aide d’informations d’identification explicites uniquement si le client dispose d’une connectivité réseau non limitée aux contrôleurs de domaine Microsoft Entra Domain Services, par exemple par le biais d’un VPN ou d’autres connexions prises en charge.

Pour activer l’authentification Microsoft Entra Domain Services, consultez Activer l’authentification Microsoft Entra Domain Services sur Azure Files.

Voir aussi

• Vue d’ensemble du contrôle d’autorisation et d’accès Azure Files
• Vue d’ensemble de l’authentification Kerberos