Comment utiliser des espaces de noms DFS avec Azure Files

S’applique à : ✔️ partages de fichiers SMB

Les espaces de noms des systèmes de fichiers distribués, communément appelés espaces de noms DFS ou DFS-N, sont un rôle serveur Windows Server qui simplifie le déploiement et la maintenance des partages de fichiers SMB en production. Les espaces de noms DFS offrent une virtualisation de l’espace de noms de stockage, ce qui vous permet d’intercaler une couche d’indirection entre le chemin UNC de votre partage de fichiers et le partage de fichiers physique. Les espaces de noms DFS fonctionnent avec des partages de fichiers SMB, indépendants de l’emplacement où ces partages de fichiers sont hébergés. Vous pouvez l’utiliser avec des partages SMB hébergés sur un serveur de fichiers Windows sur site, avec ou sans Azure File Sync, des partages de fichiers Azure directement, des partages de fichiers SMB hébergés dans Azure NetApp Files ou d’autres offres tierces, et même avec des partages de fichiers hébergés dans d’autres clouds.

Au fond, les espaces de noms DFS fournissent une correspondance entre un chemin UNC convivial, comme \\contoso\shares\ProjectX, et le chemin UNC sous-jacent du partage SMB, comme \\Server01-Prod\ProjectX ou \\storageaccount.file.core.windows.net\projectx. Lorsque l’utilisateur final navigue vers son partage de fichiers, il tape le chemin UNC convivial, mais son client SMB accède au chemin SMB sous-jacent de la mappage. Vous pouvez également étendre ce concept pour prendre le contrôle d’un nom de serveur de fichiers existant, comme \\MyServer\ProjectX. Vous pouvez utiliser cette fonctionnalité pour réaliser les scénarios suivants :

• Fournissez un nom de preuve de migration pour un ensemble logique de données. Par exemple, vous pouvez mapper \\contoso\shares\Engineering à \\OldServer\Engineering. Lorsque vous terminez votre migration vers Azure Files, vous pouvez modifier la correspondance vers \\storageaccount.file.core.windows.net\engineering, de sorte que lorsqu'un utilisateur final accède au chemin UNC convivial, il soit redirigé sans interruption vers le chemin de partage de fichiers Azure.

• Établir un nom commun pour un ensemble logique de données distribuées à plusieurs serveurs situés sur différents sites physiques, par exemple via Azure File Sync. Dans cet exemple, un nom tel que \\contoso\shares\FileSyncExample est mappé sur plusieurs chemins UNC tels que \\FileSyncServer1\ExampleShare, \\FileSyncServer2\DifferentShareName, et \\FileSyncServer3\ExampleShare. Lorsque l’utilisateur accède à l’UNC convivial, il obtient une liste de chemins UNC possibles et choisit celui le plus proche de lui en fonction des définitions de site Windows Server Active Directory (AD).

• Étendez un ensemble logique de données au-delà de la taille, des E/S ou d’autres seuils de mise à l’échelle. Cette extension est utile pour les répertoires utilisateurs, où chaque utilisateur dispose de son propre dossier sur un partage réseau, ainsi que pour les espaces de partage temporaires, où les utilisateurs disposent d’un espace libre pour des données temporaires. Avec les espaces de noms DFS, vous regroupez plusieurs dossiers dans un espace de noms cohérent. Par exemple, \\contoso\shares\UserShares\user1 mappe à \\storageaccount.file.core.windows.net\user1, \\contoso\shares\UserShares\user2 mappe à \\storageaccount.file.core.windows.net\user2, et ainsi de suite.

Vous pouvez voir un exemple d’utilisation des espaces de noms DFS avec votre déploiement Azure Files dans la vidéo de présentation suivante.

Si vous avez déjà un espace de noms DFS, aucune étape particulière n’est requise pour l’utiliser avec Azure Files et File Sync. Si vous accédez à votre partage de fichiers Azure depuis les locaux, les considérations réseau normales s’appliquent. Pour plus d’informations, consultez Considérations relatives à la mise en réseau Azure Files.

Cet article couvre les parties d’un déploiement d’espaces de noms DFS spécifiques à Azure Files. Pour les concepts sous-jacents de Windows Server et l’ensemble complet des procédures d’espaces de noms, voir aperçu des espaces de noms DFS et Déploiement des espaces de noms DFS.

Prerequisites

Pour utiliser des espaces de noms DFS avec Azure Files et File Sync, vous avez besoin des ressources suivantes :

• Domaine Active Directory. Vous pouvez héberger ce domaine n’importe où, comme sur site, dans une machine virtuelle Azure (VM), ou dans un autre cloud.

• Un serveur membre Windows Server connecté au domaine avec le rôle serveur DFS Namespaces installé. Les espaces de noms DFS sont disponibles sur toutes les versions de Windows Server prises en charge.

  Important

  N'hébergez pas un espace de noms racine consolidé sur un contrôleur de domaine Active Directory. Prendre en charge un nom de serveur de fichiers existant nécessite un serveur membre dédié ou un cluster de basculement Windows Server.

• Un partage de fichiers SMB hébergé dans un environnement jonctué au domaine, tel qu’un partage de fichiers Azure dans un compte de stockage associé au domaine, ou un partage de fichiers sur un serveur de fichiers Windows joint au domaine avec Azure File Sync. Pour plus d’informations, voir Authentification basée sur l’identité.

• L’accessibilité réseau depuis vos clients jusqu’aux partages de fichiers SMB. Pour plus d’informations, consultez Considérations relatives à la mise en réseau pour l’accès direct.

• Droits d’administrateur de domaine, ou accès d’écriture délégué à l’attribut servicePrincipalName des comptes informatiques concernés. La procédure de reprise de nom modifie les objets Active Directory et nécessite une session avec privilèges élevés.

Installer le rôle serveur DFS Namespaces

Si vous utilisez déjà des espaces de noms DFS, passez cette étape.

Install-WindowsFeature -Name "FS-DFS-Namespace", "RSAT-DFS-Mgmt-Con"

Pour plus d’options d’installation, voir Installer des espaces de noms DFS.

Choisir un type d’espace de noms

Les espaces de noms DFS proposent deux types d’espaces de noms : basés sur le domaine et autonomes. Pour une comparaison complète, incluant les limites d’échelle, les options de disponibilité et les exigences d’Active Directory, voir Choisir un type d’espace de noms.

Pour Azure Files, le choix se résume généralement à une seule question :

• Si vous devez préserver un nom de serveur de fichiers sur site existant tel que \\MyServer\share, choisissez un espace de noms autonome et utilisez la consolidation root. Cette approche est recommandée lors de la migration des partages de fichiers vers Azure Files, car elle permet de maintenir les raccourcis de documents, les liens intégrés et les chemins UNC codés en dur après la migration. Le reste de cet article se concentre sur ce scénario.
• Pour tout autre scénario, choisissez un espace de noms basé sur un domaine.

Les espaces de noms autonomes comportent des compromis à prévoir :

• Les métadonnées de l’espace de noms sont stockées dans le registre du serveur d’espace de noms, et non dans Active Directory. Incluez la configuration de l’espace de noms dans votre stratégie de sauvegarde serveur.
• Vous ne pouvez pas ajouter plusieurs serveurs d’espace de noms à un espace de noms autonome à des fins de redondance. Pour une haute disponibilité, hébergez l’espace de noms sur un cluster de basculement Windows Server.
• Les espaces de noms autonomes prennent en charge des cibles d’échelle inférieure à celles des espaces de noms basés sur le domaine en mode Windows Server 2008.

Le chemin monté par vos utilisateurs dépend du type d’espace de noms :

Si vous choisissez un espace de noms basé sur un domaine, sautez les étapes de consolidation root. La procédure de ciblage de l’espace de noms et du dossier est la même pour les deux types. Utilisez Créer l’espace de noms et ajoutez vos partages de fichiers Azure avec DomainV2 comme type d’espace de noms.

Reprendre des noms de serveurs existants avec la consolidation de la racine

En utilisant la consolidation root, un seul serveur DFS Namespaces peut répondre à plusieurs noms de serveurs de fichiers et acheminer les requêtes vers le partage approprié. Cette fonctionnalité est particulièrement utile pour l’adoption d’Azure Files, car :

• Les partages de fichiers Azure ne peuvent pas réutiliser les noms de serveurs existants sur site.
• Vous adressez les partages de fichiers Azure en utilisant le nom de domaine pleinement qualifié (FQDN) du compte de stockage. Par exemple, pour accéder au partage share dans le compte storageaccountde stockage, utilisez \\storageaccount.file.core.windows.net\share. Ce chemin peut être déroutant pour les utilisateurs finaux qui s’attendent à un nom court, comme \\MyServer\share. Azure Files prend en compte les noms de domaine personnalisés lorsque le nom du compte de stockage est le préfixe du domaine, mais sans espaces de noms DFS, vous ne pouvez pas utiliser un nom comme \\MyServer.contoso.com\share.

Vous pouvez utiliser la consolidation racine uniquement avec des espaces de noms autonomes. Si vous avez déjà un espace de noms basé sur un domaine pour vos partages de fichiers, vous n’avez pas besoin d’un espace de noms consolidé root.

Pour rendre un espace de noms racine consolidé hautement disponible, hébergez-le sur un cluster de basculement. Pour créer le cluster sous-jacent, voir Créer un cluster de basculement. Si vous adoptez cette approche, enregistrez l’alias auprès de l’objet de nom de cluster (CNO), et non auprès d’un nœud individuel.

Le schéma suivant montre un déploiement de consolidation des racines à haute disponibilité. Un Azure Load Balancer est placé devant un cluster de basculement de Windows Server composé de serveurs DFS Namespaces qui hébergent les espaces de noms consolidés à la racine, de sorte que les clients continuent à accéder aux anciens noms du serveur de fichiers après la migration de leurs partages vers Azure Files.

Prendre le contrôle d’un nom de serveur existant est un changement, pas un changement additif. Terminez les étapes suivantes dans l’ordre :

1. Activez la consolidation root sur le serveur DFS Namespaces.
2. Créez l’espace de noms et ajoutez vos partages de fichiers Azure, en utilisant un espace nommé #<old-server-name>.
3. Transférez le nom du serveur et les noms du principal de service depuis le serveur de fichiers source.
4. Créez des entrées DNS pour les noms de serveurs de fichiers existants.
5. Vérifiez l’usurpation de nom.

Activer la consolidation des racines

Depuis une session PowerShell élevée sur le serveur d’espace de noms, définissez les valeurs du registre suivantes puis redémarrez le service DFS Namespace. Le service ne lit ces valeurs qu’au démarrage ; tant qu’il ne redémarre pas, vous ne pouvez pas créer un espace de noms dont le nom commence par #.

New-Item `
    -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs" `
    -Type Registry `
    -ErrorAction SilentlyContinue
New-Item `
    -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters" `
    -Type Registry `
    -ErrorAction SilentlyContinue
New-Item `
    -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters\Replicated" `
    -Type Registry `
    -ErrorAction SilentlyContinue
Set-ItemProperty `
    -Path "HKLM:SYSTEM\CurrentControlSet\Services\Dfs\Parameters\Replicated" `
    -Name "ServerConsolidationRetry" `
    -Type DWord `
    -Value 1

Restart-Service -Name "Dfs"

Sur un cluster de basculement, définissez les valeurs du registre sur chaque nœud puis échouez le rôle d’espace de noms regroupé afin que chaque nœud redémarre le service.

Créez l’espace de noms et ajoutez vos partages de fichiers Azure

L’unité de base de gestion des espaces de noms DFS est l’espace de noms, dont la racine est le point de départ de l’arbre. Dans \\contoso.com\Public\, la racine de l’espace de noms est Public. Dans un espace de noms, les dossiers avec cibles de dossiers pointent vers les partages de fichiers SMB qui contiennent votre contenu, et les dossiers sans cibles de dossier ajoutent structure et hiérarchie.

Pour les procédures générales de Windows Server, voir Créer un espace de noms DFS, Créer un dossier dans un espace de noms DFS, et Ajouter des cibles de dossiers. Lorsque vous ciblez des partages de fichiers Azure, gardez à l’esprit les points suivants :

• Utilisez le compte de stockage FQDN pour la cible du dossier. Pointez les cibles de dossier vers \\<storage-account>.file.core.windows.net\<share>. Azure Files prend également en charge les noms de domaine personnalisés lorsque le nom du compte de stockage constitue le préfixe du domaine, mais l’utilisation d’un tel nom pour une cible de dossier ajoute une deuxième dépendance à DNS et à Kerberos derrière chaque renvoi. Utilisez le FQDN à moins que vous ne dépendiez déjà de noms de domaine personnalisés.
• Attendez-vous à une alerte de connectivité dans la gestion DFS. Lorsque vous ajoutez une cible de dossier pour un partage de fichiers Azure, la console peut indiquer que storageaccount.file.core.windows.net n’est pas joignable. Cet avertissement est attendu. Cliquez sur Oui pour continuer.
• Les espaces de noms de consolidation racine nécessitent un préfixe #. Le nom de l’espace de noms doit correspondre au serveur que vous remplacez, précédé de #. Pour prendre le contrôle d’un serveur nommé MyServer, créez un espace de noms appelé #MyServer. L’exemple de PowerShell ajoute le préfixe pour vous. La console de gestion DFS ne le fait pas, donc tapez-le vous-même.
• Les noms de dossiers doivent correspondre aux anciens noms de partage. Un client qui ouvre \\MyServer\Finance est dirigé vers le dossier Finance dans l’espace de noms #MyServer ; les noms de dossiers doivent donc correspondre exactement aux noms des partages du serveur source.

# Variables
$namespace = "MyServer"                   # Namespace root name. For root consolidation, use the
                                          # name of the file server you're replacing.
$type = "Standalone"                      # "Standalone" for a stand-alone namespace, or "DomainV2"
                                          # for a domain-based namespace (Windows Server 2008 mode).
$takeOverName = $true                     # Set to $false if you aren't using root consolidation.
$shareName = "Finance"                    # Folder name within the namespace. For root consolidation,
                                          # match the share name on the source file server exactly.
$targetUNC = "\\storageaccount.file.core.windows.net\finance"

# Root consolidation namespaces must be prefixed with "#".
if ($takeOverName -and $type -eq "Standalone" -and $namespace -notlike "#*") {
    $namespace = "#$namespace"
}

$dfsnServer = $env:ComputerName
$namespaceServer = if ($type -like "Domain*") {
    Get-CimInstance -ClassName "Win32_ComputerSystem" | `
        Select-Object -ExpandProperty Domain
} else { $dfsnServer }

# Create the SMB share that backs the namespace root. Read-only access matches the DFS Management
# default, because this share serves referrals rather than data.
$smbSharePath = "C:\DFSRoots\$namespace"
if (!(Test-Path -Path $smbSharePath)) {
    New-Item -Path $smbSharePath -ItemType Directory | Out-Null
}
New-SmbShare -Name $namespace -Path $smbSharePath -ReadAccess "Everyone"

# Create the namespace root.
Import-Module -Name DFSN
$namespacePath = "\\$namespaceServer\$namespace"
New-DfsnRoot -Path $namespacePath -TargetPath "\\$dfsnServer\$namespace" -Type $type

# Create the folder and point it at the Azure file share.
New-DfsnFolder -Path "$namespacePath\$shareName" -TargetPath $targetUNC

# Verify the namespace root and folder target.
Get-DfsnRoot -Path $namespacePath
Get-DfsnFolderTarget -Path "$namespacePath\$shareName"

Confirmez que l’espace de noms se résout via le nom propre du serveur avant de continuer. L’ancien nom de serveur ne fonctionne pas encore ; il commence à fonctionner après les deux étapes suivantes.

Test-Path -Path "\\CloudDFSN\#MyServer\Finance"

Si le chemin ne se résout pas, vérifiez que le client peut accéder directement au partage de fichiers Azure à \\<storage-account>.file.core.windows.net\<share>. DFS Namespaces ne renvoie qu’une référence, donc tout problème de réseau ou d’authentification avec le partage sous-jacent apparaît ici. Pour plus d’informations, consultez Considérations relatives à la mise en réseau pour l’accès direct.

Transférer le nom du serveur et les noms du principal du service

La consolidation root permet au serveur DFS Namespaces de répondre au nom de l’ancien serveur de fichiers, mais deux autres éléments doivent être vrais avant qu’un client puisse s’authentifier à ce nom :

• Le serveur SMB sur le serveur d’espace de noms doit accepter une connexion établie vers un nom autre que son propre nom d’ordinateur.
• Kerberos doit associer cifs/MyServer au compte qui traite la requête. Si ce nom principal de service (SPN) est toujours enregistré sur le compte informatique du serveur de fichiers désactivé, les clients reçoivent un ticket pour le mauvais compte. La connexion échoue alors avec « Le nom du compte cible est incorrect » ou revient silencieusement en NTLM.

Le netdom computername commandement gère les deux exigences. Il enregistre l’ancien nom comme un nom informatique alternatif sur le serveur d’espace de noms, ce qui ajoute le nom à l’attribut du msDS-AdditionalDnsHostName serveur et enregistre les SPN correspondants HOST/<alias> . Un HOST SPN couvre implicitement un ensemble de classes de service qui inclut cifs, de sorte qu’une demande client pour cifs/MyServer se résout au compte du serveur de l’espace de noms. Pour la liste complète des classes de service, voir setspn.

Ne remplacez pas un enregistrement construit setspn à la main par netdom. L’enregistrement cifs/MyServer sur le compte du serveur d’espace de noms configure Kerberos mais pas le serveur SMB, et le service d’annuaire rejette les SPN qui ne proviennent pas des noms propres du compte cible. Pour plus d’informations, voir l’accès au partage de serveur de fichiers SMB est infructueux via l’alias DNS CNAME.

1. Coupez le serveur de fichiers source. Le serveur source et le serveur DFS Namespaces ne peuvent pas tous deux répondre au même nom. Éteignez le serveur plutôt que de le retirer du domaine.

2. Désactivez le compte informatique source. Dans Utilisateurs et ordinateurs Active Directory, cliquez droit sur l’objet ordinateur et sélectionnez Désactiver le compte. Pour faire de même depuis PowerShell sur une machine avec le module Active Directory installé, exécutez :

   $oldServer = "MyServer"
   Disable-ADAccount -Identity ($oldServer + '$')
   

3. Supprimez les SPN du compte d’ordinateur source. Désactiver un compte ne supprime pas ses SPN. Les enregistrements laissés sur l’ancien compte bloquent l’étape suivante, car le même nom ne peut pas être enregistré sur deux comptes. Les SPN dupliqués sont une cause documentée de KDC_ERR_PRINCIPAL_NOT_UNIQUE. Pour plus d’informations, voir Kerberos génère une erreur KDC_ERR_S_PRINCIPAL_UNKNOWN ou KDC_ERR_PRINCIPAL_NOT_UNIQUE. Listez ce qui est enregistré, puis supprimez les entrées HOST et cifs :

   setspn -L MyServer
   setspn -D HOST/MyServer MyServer
   setspn -D HOST/MyServer.contoso.com MyServer
   

   Supprimez toutes les entrées explicites cifs/ de la même manière. Si setspn -L affiche d’autres classes de service telles que TERMSRV ou MSSQLSvc, l’ancien nom est encore utilisé pour autre chose que SMB. Résolvez cette dépendance avant de continuer.

4. Ajoutez l’ancien nom comme nom d’ordinateur alternatif sur le serveur d’espace de noms. Exécutez netdom depuis une invite de commande surélevée sur le serveur d’espace de noms. Pour un seul serveur DFS Namespaces, ciblez le compte informatique de ce serveur. Pour un espace de noms autonome clusterisé, il faut cibler l’objet nom du cluster (CNO), et non les comptes individuels de nœuds. netdom livré avec les outils AD DS dans Remote Server Administration Tools ; installe RSAT-AD-Tools si la commande n’est pas disponible.

   netdom computername CloudDFSN.contoso.com /add:MyServer.contoso.com
   

   Spécifiez les deux noms comme des noms de domaine pleinement qualifiés. netdom enregistre les HOST/MyServer SPN et HOST/MyServer.contoso.com sur le compte cible et ajoute le nom à l’attribut du msDS-AdditionalDnsHostName compte, ce qui permet au serveur SMB d’accepter les connexions faites à l’ancien nom.

   Vérifiez le résultat. Le /verify commutateur vérifie qu’un enregistrement DNS et un SPN existent pour chaque nom enregistré :

   netdom computername CloudDFSN.contoso.com /enumerate:AlternateNames
   netdom computername CloudDFSN.contoso.com /verify
   

   Si netdom signale que le nom est déjà utilisé, c’est qu’il est toujours enregistré ailleurs dans la forêt. Localisez l’objet en conflit avant de continuer :

   setspn -T contoso -F -Q */MyServer
   

   Si le seul objet retourné est le compte informatique source que vous avez modifié à l’étape précédente, la suppression ne s’est pas encore reproduite vers le contrôleur de domaine que vous interrogez. Attendez que la réplication converge, ou relancez les commandes sur l’émulateur PDC.

Créer des entrées DNS pour les noms de serveurs de fichiers existants

Pour que les espaces de noms DFS répondent aux noms existants des serveurs de fichiers, créez des enregistrements d’alias (CNAME) qui pointent les anciens noms de serveurs de fichiers vers le serveur DFS Namespaces. La procédure exacte dépend du serveur DNS utilisé par votre organisation. Les étapes suivantes utilisent le serveur DNS inclus avec Windows Server.

# Variables
$oldServer = "MyServer"
$dfsnServer = "CloudDFSN"
$domain = Get-CimInstance -ClassName "Win32_ComputerSystem" | `
    Select-Object -ExpandProperty Domain

# Create CNAME record
Import-Module -Name DnsServer
Add-DnsServerResourceRecordCName `
    -Name $oldServer `
    -HostNameAlias "$dfsnServer.$domain" `
    -ZoneName $domain

Vérifiez la prise de contrôle du nom

Testez depuis un client relié au domaine, connecté en tant qu’utilisateur avec des permissions sur le partage de fichiers Azure cible. Ne testez pas depuis le serveur DFS Namespaces lui-même, car une connexion de boucle n’utilise pas le même chemin d’authentification qu’un client distant.

1. Confirmez que l’enregistrement du nom alternatif s’est répliqué sur chaque contrôleur de domaine. Le centre de distribution de clés du client n'est pas nécessairement le contrôleur de domaine que vous avez modifié, et les répliques Active Directory ne sont pas garanties d'être cohérentes à un moment donné :

   $oldServer = "MyServer"
   $dfsnServer = "CloudDFSN"
   Get-ADDomainController -Filter * | ForEach-Object {
       $spns = (Get-ADComputer -Identity $dfsnServer -Properties servicePrincipalName `
           -Server $_.HostName).servicePrincipalName
       [pscustomobject]@{
           DomainController = $_.HostName
           HasHostSpn       = [bool]($spns -contains "HOST/$oldServer")
       }
   }
   

   Si un contrôleur de domaine signale False, la réplication n’est pas complète. Attendez et vérifiez à nouveau avant de continuer, car un client qui s’authentifie via ce contrôleur de domaine échoue toujours.

2. Confirmez que l’ancien nom du serveur pointe désormais vers le serveur d’espaces de noms DFS :

   Resolve-DnsName -Name "MyServer" -Type CNAME
   

3. Ouvrez le partage via l’ancien nom et confirmez que vous voyez le contenu du partage de fichiers Azure :

   Test-Path -Path "\\MyServer\Finance"
   Get-ChildItem -Path "\\MyServer\Finance"
   

4. Confirmez que la session a été authentifiée avec Kerberos plutôt que de revenir à NTLM en vérifiant qu’un ticket a été émis pour l’ancien nom :

   klist
   

   Cherchez un ticket dont le champ serveur est cifs/MyServer. Kerberos délivre ce ticket pour le compte du serveur d’espace de noms, car l’enregistrement HOST/MyServer couvre la classe de service cifs. Si aucun ticket n’existe, les causes les plus courantes sont que l’enregistrement du nom alternatif n’a pas été reproduit vers le contrôleur de domaine utilisé par le client, qu’une inscription a été laissée sur le compte désactivé, ou qu’un doublon existe ailleurs dans la forêt.

Si les modifications DNS ou Kerberos ne s’appliquent pas immédiatement, videz les caches côté client et réessayez :

ipconfig /flushdns
klist purge

Vider les caches clients n’aide pas si le changement sous-jacent n’a pas encore été répliqué. Si une nouvelle tentative échoue toujours, vérifiez à nouveau la convergence de la réplication à l’étape 1 avant de changer quoi que ce soit d’autre.

Énumération basée sur l’accès (ABE)

L’énumération basée sur l’accès masque les fichiers et dossiers auxquels l’utilisateur n’a pas la permission d’accéder. Dans les espaces de noms DFS, l’activation de l’ABE sur un espace de noms s’applique uniquement aux dossiers DFS-N de cet espace de noms. Pour contrôler l’énumération du contenu d’un dossier cible, activez ABE sur le partage de fichiers cible lui-même. ABE exige que tous les serveurs d’espaces de noms fonctionnent sous Windows Server 2008 ou une version ultérieure, et les espaces de noms basés sur le domaine doivent utiliser le mode Windows Server 2008. Pour plus de détails, voir Activer l’énumération basée sur l’accès sur un espace de noms.

Comme vous ne pouvez pas activer ABE sur un partage de fichiers Azure, utiliser ABE pour contrôler la visibilité des fichiers et dossiers dans un partage SMB Azure n'est pas un scénario supporté. Cette limitation existe parce que DFS-N fonctionne par référence plutôt que comme un proxy devant la cible du dossier. Lorsqu’un utilisateur tape \\mydfsnserver\share, le client PME reçoit la référence \\mydfsnserver\share => \\server123\share et la monte directement, de sorte que le serveur DFS-N n’est plus dans le chemin des données.

ABE ne fonctionne que lorsque le serveur DFS-N héberge le niveau de la hiérarchie que vous souhaitez filtrer, avant la redirection. Les deux dispositions suivantes fonctionnent, car les noms de dossiers par utilisateur résident dans l’espace de noms du serveur DFS-N :

• \\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\contosouser1
• \\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\users\contosouser1, où contosouser1 est un sous-dossier du partage users.

Si chaque utilisateur est un sous-dossier après la redirection, ABE ne fonctionne pas, car les dossiers par utilisateur ne sont jamais énumérés par le serveur DFS-N :

• \\DFSServer\SomePath\users => \\SA.file.core.windows.net\users

Voir aussi

• Configuration de l’accès au partage de fichiers : considérations relatives à l’authentification basée sur l’identité et à la mise en réseau pour l’accès direct.
• Vue d’ensemble des espaces de noms DFS
• Déploiement d’espaces de noms DFS
• Choisir un type d’espace de noms
• Netdom Computername
• setspn
• L’accès au partage du serveur de fichiers SMB est infructueux via l’alias DNS CNAME
• Créer un cluster de basculement