Cómo usar espacios de nombres DFS con Azure Files

Se aplica a: ✔️ recursos compartidos de archivos SMB

Espacios de nombres del sistema de archivos distribuido, conocidos comúnmente como Espacios de nombres DFS o DFS-N, es un rol de servidor de Windows Server que simplifica la implementación y el mantenimiento de los recursos compartidos de archivos SMB en producción. DFS Namespaces proporciona virtualización del espacio de nombres de almacenamiento, lo que permite proporcionar una capa de redirección entre la ruta UNC de su recurso compartido de archivos y el recurso compartido de archivos real. Los espacios de nombres DFS son compatibles con recursos compartidos de archivos SMB, sin importar dónde estén hospedados esos recursos compartidos de archivos. Puedes usarlo con recursos compartidos SMB alojados en un servidor de archivos de Windows local con o sin Azure File Sync, recursos compartidos de archivos de Azure directamente, recursos compartidos de archivos SMB alojados en Azure NetApp Files u otras ofertas de terceros, e incluso con recursos compartidos de archivos alojados en otras nubes.

En esencia, los espacios de nombres DFS proporcionan un mapeo entre una ruta UNC fácil de usar, como \\contoso\shares\ProjectX, y la ruta UNC subyacente de la parte compartida SMB, como \\Server01-Prod\ProjectX o \\storageaccount.file.core.windows.net\projectx. Cuando el usuario final navega a su archivo compartido, escribe la ruta UNC amigable, pero su cliente SMB accede a la ruta SMB subyacente del mapeo. También puedes ampliar este concepto para que tome el nombre de un servidor de archivos existente, como \\MyServer\ProjectX. Puede usar esta funcionalidad para lograr los escenarios siguientes:

• Proporcione un nombre de prueba de migración para un conjunto lógico de datos. Por ejemplo, puede asignar \\contoso\shares\Engineering a \\OldServer\Engineering. Cuando completes tu migración a Azure Files, puedes cambiar el mapeo a \\storageaccount.file.core.windows.net\engineering, de modo que cuando un usuario final acceda a la ruta UNC fácil de usar, se redirija sin problemas a la ruta de Azure para compartir archivos.

• Establecer un nombre común para un conjunto lógico de datos distribuidos a múltiples servidores en diferentes sitios físicos, como a través de Azure File Sync. En este ejemplo, un nombre como \\contoso\shares\FileSyncExample se asigna a múltiples rutas UNC como \\FileSyncServer1\ExampleShare, \\FileSyncServer2\DifferentShareName, y \\FileSyncServer3\ExampleShare. Cuando el usuario accede al UNC intuitivo, obtiene una lista de posibles rutas UNC y elige la que le queda más cercana según las definiciones de sitio de Windows Server Active Directory (AD).

• Ampliar un conjunto lógico de datos más allá de los umbrales de tamaño, E/S u otras escalas. Esta extensión es útil para directorios de usuarios, donde cada usuario tiene su propia carpeta en un recurso compartido, y para recursos compartidos temporales, donde los usuarios disponen de espacio según sus necesidades para datos temporales. Con los espacios de nombres DFS, se unen varias carpetas en un espacio de nombres cohesivo. Por ejemplo, \\contoso\shares\UserShares\user1 se asigna a \\storageaccount.file.core.windows.net\user1, \\contoso\shares\UserShares\user2 se asigna a \\storageaccount.file.core.windows.net\user2, etc.

Puede ver un ejemplo de cómo usar Espacios de nombres DFS con la implementación de Azure Files en el vídeo de introducción siguiente.

Si ya tienes un espacio de nombres DFS, no se requieren pasos especiales para usarlo con Azure Files y File Sync. Si accedes a tu recurso compartido de archivos de Azure desde las instalaciones, se aplican las consideraciones normales de red. Para más información, vea Consideraciones de redes para Azure Files.

Este artículo trata las partes de un despliegue de espacios de nombres DFS que son específicas de Azure Files. Para los conceptos subyacentes de Windows Server y el conjunto completo de procedimientos de espacios de nombres, consulte la visión general de los espacios de nombres DFS y Despliegue de espacios de nombres DFS.

Prerequisites

Para usar espacios de nombres DFS con Azure Files y File Sync, necesitas los siguientes recursos:

• Un dominio de Active Directory. Puedes alojar este dominio en cualquier lugar, como en las instalaciones, en una máquina virtual de Azure (VM) o en otra nube.

• Un servidor miembro de Windows Server unido al dominio con el rol de servidor DFS Namespaces instalado. Espacios de nombres DFS está disponible en todas las versiones compatibles de Windows Server.

  Importante

  No alojes un espacio de nombres consolidado raíz en un controlador de dominio de Active Directory. Tomar el control de un nombre de servidor de archivos existente requiere un servidor miembro dedicado o un clúster de conmutación por error de Windows Server.

• Un recurso compartido de archivos SMB alojado en un entorno unido al dominio, como un recurso compartido de archivos Azure en una cuenta de almacenamiento unido al dominio, o un recurso compartido en un servidor de archivos Windows unido al dominio con Azure File Sync. Para más información, véase Autenticación basada en identidad.

• La accesibilidad de la red desde tus clientes hasta los compartidos de archivos de la SMB. Para obtener más información, consulte Consideraciones de redes para el acceso directo.

• Derechos de administrador de dominio, o acceso delegado de escritura al servicePrincipalName atributo de las cuentas de ordenador afectadas. El procedimiento de reasignación del nombre modifica los objetos de Active Directory y requiere una sesión con privilegios elevados.

Instalación del rol de servidor Espacios de nombres DFS

Si ya usas espacios de nombres DFS, sáltate este paso.

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

Para más opciones de instalación, consulta Instalar espacios de nombres DFS.

Elegir un tipo de espacio de nombres

Los espacios de nombres DFS proporcionan dos tipos de espacios de nombres: basados en dominio y independientes. Para una comparación completa, incluyendo límites de escala, opciones de disponibilidad y requisitos de Active Directory, consulte Elegir un tipo de espacio de nombres.

Para Azure Files, la elección suele reducirse a una sola pregunta:

• Si necesitas preservar un nombre de servidor de archivos local existente como \\MyServer\share, elige un espacio de nombres independiente y usa la consolidación raíz. Este enfoque se recomienda cuando migras los compartidos de archivos a Azure Files, porque mantiene funcionando los accesos directos de documentos, enlaces incrustados y rutas UNC codificadas después de la migración. El resto de este artículo se centra en este escenario.
• Para cualquier otro escenario, elige un espacio de nombres basado en dominio.

Los espacios de nombres independientes conllevan contrapartidas que deben tenerse en cuenta:

• Los metadatos del espacio de nombres se almacenan en el registro del servidor de espacio de nombres, no en Active Directory. Incluye la configuración del espacio de nombres en tu estrategia de copia de seguridad del servidor.
• No puedes agregar varios servidores de espacio de nombres a un espacio de nombres independiente con fines de redundancia. Para una alta disponibilidad, hospede el espacio de nombres en un clúster de conmutación por error de Windows Server.
• Los espacios de nombres independientes soportan objetivos de menor escala que los espacios de nombres basados en dominio en el modo Windows Server 2008.

La ruta que montan los usuarios depende del tipo de espacio de nombres:

Si elegiste un espacio de nombres basado en un dominio, omite las etapas de consolidación de raíz. El espacio de nombres y el procedimiento de destino de carpeta es el mismo para ambos tipos. Use Crear el espacio de nombres y agregar los recursos compartidos de archivos de Azure con DomainV2 como tipo de espacio de nombres.

Tomar el control de los nombres de servidor existentes mediante consolidación raíz

Mediante la consolidación de raíces, un único servidor de DFS Namespaces puede responder a varios nombres de servidor de archivos y dirigir las solicitudes al recurso compartido correspondiente. Esta capacidad es especialmente útil para adoptar Azure Files, porque:

• Los archivos compartidos de Azure no pueden reutilizar nombres de servidores existentes en las instalaciones.
• Se accede a los recursos compartidos de archivos de Azure mediante el nombre de dominio completo (FQDN) de la cuenta de almacenamiento. Por ejemplo, para acceder a compartir share en la cuenta storageaccountde almacenamiento, utiliza \\storageaccount.file.core.windows.net\share. Ese camino puede resultar confuso para los usuarios finales que esperan un nombre corto, como \\MyServer\share. Azure Files soporta nombres de dominio personalizados cuando el nombre de la cuenta de almacenamiento es el prefijo de dominio, pero sin espacios de nombres DFS no puedes usar un nombre como \\MyServer.contoso.com\share.

Solo puedes usar la consolidación de raíz con espacios de nombres independientes. Si ya tienes un espacio de nombres basado en dominio para tus compartidos de archivos, no necesitas un espacio de nombres consolidado raíz.

Para que un espacio de nombres consolidado de raíz tenga alta disponibilidad, alójelo en un clúster de conmutación por error. Para construir el clúster subyacente, véase Crear un clúster de conmutación por error. Si adoptas este enfoque, registra el alias en el objeto nombre del clúster (CNO), no en un nodo individual.

El siguiente diagrama muestra un despliegue de consolidación de raíz de alta disponibilidad. Un Azure Load Balancer encabeza un clúster de conmutación por error de Windows Server formado por servidores de espacios de nombres DFS que hospedan los espacios de nombres consolidados de raíz, de modo que los clientes sigan llegando a los nombres retirados de servidores de archivos después de que sus recursos compartidos se trasladen a Azure Files.

Asumir un nombre de servidor existente implica una transición, no un cambio aditivo. Completar las siguientes etapas en orden:

1. Activa la consolidación raíz en el servidor DFS Namespaces.
2. Crea el espacio de nombres y añade tus recursos compartidos de archivos de Azure, con un espacio de nombres llamado #<old-server-name>.
3. Transfiere el nombre del servidor y los nombres principales del servicio desde el servidor de archivos de origen.
4. Crea entradas DNS para los nombres de servidores de archivos existentes.
5. Verifica la apropiación del nombre.

Activar la consolidación de raíz

Desde una sesión de PowerShell con privilegios elevados en el servidor de espacios de nombres, configure los siguientes valores del registro y, a continuación, reinicie el servicio Espacios de nombres DFS. El servicio solo lee estos valores al iniciar; hasta que no se reinicia, no puedes crear un espacio de nombres cuyo nombre comience con #.

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"

En un clúster de conmutación por error, establece los valores del registro en cada nodo y luego falla el rol de espacio de nombres agrupado para que cada nodo reinicie el servicio.

Crea el espacio de nombres y añade tus recursos compartidos de archivos de Azure

La unidad básica de gestión para los espacios de nombres DFS es el espacio de nombres, cuya raíz es el punto de partida del árbol. En \\contoso.com\Public\, la raíz del espacio de nombres es Public. Dentro de un espacio de nombres, las carpetas con destinos de carpeta apuntan a los archivos compartidos SMB que contienen tu contenido, y las carpetas sin destinos de carpeta añaden estructura y jerarquía.

Para los procedimientos generales de Windows Server, véase Crear un espacio de nombres DFS, Crear una carpeta en un espacio DFS y Añadir destinos de carpeta. Al usar recursos compartidos de archivos de Azure, ten en cuenta los siguientes puntos:

• Usa la cuenta de almacenamiento FQDN como destino de carpeta. Apunte los destinos de carpeta a \\<storage-account>.file.core.windows.net\<share>. Azure Files también admite nombres de dominio personalizados cuando el nombre de la cuenta de almacenamiento es el prefijo de dominio, pero usar uno como destino de carpeta añade un segundo DNS y dependencia de Kerberos detrás de cada referencia. Usa el FQDN a menos que ya dependas de nombres de dominio personalizados.
• Espera una alerta de conectividad en DFS Management. Cuando añades un destino de carpeta para un archivo compartido de Azure, la consola puede informar que storageaccount.file.core.windows.net no se puede contactar. Se espera esta advertencia. Seleccione Sí para continuar.
• Los espacios de nombres de consolidación de raíz necesitan el prefijo #. El nombre del espacio de nombres debe coincidir con el del servidor que estás reemplazando, precedido de #. Para tomar el control de un servidor llamado MyServer, crea un espacio de nombres llamado #MyServer. El ejemplo de PowerShell añade el prefijo para ti. La consola de gestión DFS no lo hace, así que escríbelo tú mismo.
• Los nombres de las carpetas deben coincidir con los nombres de los recursos compartidos anteriores. Un cliente que abre \\MyServer\Finance accede a la carpeta Finance en el espacio de nombres #MyServer, por lo que los nombres de las carpetas deben coincidir exactamente con los nombres de recurso compartido del servidor de origen.

# 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"

Confirma que el espacio de nombres se resuelve a través del propio nombre del servidor antes de continuar. El nombre antiguo del servidor aún no funciona; empieza a funcionar después de las dos siguientes etapas.

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

Si la ruta no se resuelve, verifica que el cliente pueda acceder directamente al recurso compartido de archivos de Azure en \\<storage-account>.file.core.windows.net\<share>. DFS Namespaces solo devuelve una referencia, así que cualquier problema de red o autenticación con el recurso compartido subyacente aparece aquí. Para obtener más información, consulte Consideraciones de redes para el acceso directo.

Transfiere el nombre del servidor y los nombres principales del servicio

La consolidación raíz permite que el servidor DFS Namespaces responda al nombre del antiguo servidor de archivos, pero deben ser ciertas otras dos cosas antes de que un cliente pueda autenticarse con ese nombre:

• El servidor SMB en el servidor de espacio de nombres debe aceptar una conexión realizada a un nombre distinto al nombre de su propio ordenador.
• Kerberos debe resolver cifs/MyServer como la cuenta que da servicio a la solicitud. Si ese nombre principal de servicio (SPN) sigue registrado en la cuenta informática del servidor de archivos desactivado, los clientes reciben un ticket por la cuenta equivocada. La conexión falla entonces con "El nombre de la cuenta objetivo es incorrecto" o vuelve silenciosamente a NTLM.

El netdom computername comando gestiona ambos requisitos. Registra el nombre antiguo como un nombre alternativo de equipo en el servidor del espacio de nombres, lo que añade el nombre al atributo msDS-AdditionalDnsHostName del servidor y registra los SPN HOST/<alias> correspondientes. Un SPN de HOST cubre implícitamente un conjunto de clases de servicio que incluye cifs, por lo que una solicitud de cliente para cifs/MyServer se resuelve en la cuenta del servidor de espacio de nombres. Para la lista completa de clases de servicio, véase setspn.

No sustituyas un registro creado manualmente setspn por netdom. Registrar cifs/MyServer en la cuenta del servidor de espacio de nombres configura Kerberos, pero no el servidor SMB, y el servicio de directorio rechaza los SPN que no se derivan de los propios nombres de la cuenta de destino. Para obtener más información, consulte El acceso al recurso compartido del servidor de archivos SMB no funciona a través del alias DNS CNAME.

1. Apaga el servidor de archivos de origen. El servidor de origen y el servidor de espacios de nombres DFS no pueden responder ambos al mismo nombre. Apaga el servidor en vez de eliminarlo del dominio.

2. Desactiva la cuenta del ordenador de origen. En Usuarios y equipos de Active Directory, haz clic derecho en el objeto ordenador y selecciona Desactivar cuenta. Para hacer lo mismo desde PowerShell en un equipo con el módulo Active Directory instalado, ejecuta:

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

3. Elimina los SPN de la cuenta del ordenador de origen. Desactivar una cuenta no elimina sus SPNs. Los registros que se dejan en la cuenta antigua bloquean el siguiente paso, porque el mismo nombre no puede registrarse en dos cuentas. Los SPN duplicados son una causa documentada de KDC_ERR_PRINCIPAL_NOT_UNIQUE. Para obtener más información, consulte Kerberos genera el error KDC_ERR_S_PRINCIPAL_UNKNOWN o KDC_ERR_PRINCIPAL_NOT_UNIQUE. Enumera lo que está registrado y luego elimina las entradas HOST y cifs:

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

   Elimina cualquier entrada explícita cifs/ de la misma manera. Si setspn -L muestra otras clases de servicio como TERMSRV o MSSQLSvc, el nombre antiguo sigue sirviendo a algo distinto a SMB. Resuelve esa dependencia antes de continuar.

4. Añade el nombre antiguo como nombre alternativo de ordenador en el servidor de espacio de nombres. Ejecuta netdom desde un símbolo elevado en el servidor de espacio de nombres. Para un único servidor de DFS Namespaces, dirígete a la cuenta de equipo de ese servidor. Para un espacio de nombres independiente agrupado en clúster, diríjase al objeto de nombre de clúster (CNO), no a las cuentas de nodo individuales. netdom se incluye con las herramientas AD DS en Remote Server Administration Tools; instala RSAT-AD-Tools si el comando no está disponible.

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

   Especifica ambos nombres como dominios totalmente cualificados. netdom registra los SPN HOST/MyServer y HOST/MyServer.contoso.com en la cuenta de destino y añade el nombre al atributo msDS-AdditionalDnsHostName de la cuenta, lo que permite al servidor SMB aceptar conexiones realizadas con el nombre antiguo.

   Compruebe el resultado. El /verify switch comprueba que existan un registro DNS y un SPN para cada nombre registrado:

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

   Si netdom informa de que el nombre ya está en uso, significa que aún está registrado en otra parte del bosque. Localiza el objeto en conflicto antes de continuar:

   setspn -T contoso -F -Q */MyServer
   

   Si el único objeto que se devuelve es la cuenta del ordenador de origen que editaste en el paso anterior, la eliminación aún no se ha replicado en el controlador de dominio que consultas. Espera a que la replicación converja, o reejecuta los comandos contra el emulador PDC.

Crear entradas DNS para nombres de servidores de archivos existentes

Para que los espacios de nombres DFS respondan a nombres de servidores de archivos existentes, crea registros de alias (CNAME) que apunten los nombres antiguos de servidores de archivos al servidor de espacios de nombres DFS. El procedimiento exacto depende del servidor DNS que utilice tu organización. Los siguientes pasos utilizan el servidor DNS incluido con 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

Verifica la apropiación del nombre

Prueba desde un cliente unido al dominio, iniciando sesión como usuario con permisos en el recurso compartido de archivos de Azure objetivo. No pruebes desde el propio servidor de espacios de nombres DFS, porque una conexión de bucle no usa la misma ruta de autenticación que usa un cliente remoto.

1. Confirmar que el registro de nombre alternativo se haya replicado en todos los controladores de dominio. El centro de distribución de claves del cliente no es necesariamente el controlador de dominio que cambiaste, y las réplicas de Active Directory no están garantizadas para ser consistentes en ningún momento:

   $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 algún controlador de dominio informa False, la replicación no está completa. Espera y revisa de nuevo antes de continuar, porque un cliente que se autentica a través de ese controlador de dominio sigue fallando.

2. Confirma que el nombre antiguo del servidor ahora se resuelve al servidor DFS Namespaces:

   Resolve-DnsName -Name "MyServer" -Type CNAME
   

3. Abre el recurso compartido con el nombre antiguo y confirma que ves el contenido del recurso compartido de archivos de Azure:

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

4. Confirma que la sesión se autenticó con Kerberos en lugar de volver a NTLM comprobando que se emitió un ticket con el nombre antiguo:

   klist
   

   Busca un ticket cuyo campo de servidor sea cifs/MyServer. Kerberos emite este ticket contra la cuenta del servidor de espacio de nombres porque el HOST/MyServer registro cubre la clase de cifs servicio. Si no existe tal ticket, las causas más comunes son que el registro de nombre alternativo no se replicó en el controlador de dominio que usa el cliente, que se dejó un registro en la cuenta deshabilitada, o que existe un duplicado en otra parte del bosque.

Si los cambios en DNS o Kerberos no entran en vigor inmediatamente, borra las cachés del lado del cliente y vuelve a intentarlo:

ipconfig /flushdns
klist purge

Borrar las cachés del cliente no ayuda si el cambio subyacente aún no se ha replicado. Si un reintento sigue fallando, vuelve a comprueba la convergencia de replicación en el paso 1 antes de cambiar cualquier otra cosa.

Enumeración basada en acceso (ABE)

La enumeración basada en acceso oculta archivos y carpetas a los que el usuario no tiene permiso para acceder. En los espacios de nombres DFS, habilitar ABE en un espacio de nombres solo se aplica a las carpetas DFS-N de ese espacio de nombres. Para controlar la enumeración del contenido de una carpeta de destino, activa ABE en el propio recurso compartido de archivos. ABE requiere que todos los servidores de espacios de nombres ejecuten Windows Server 2008 o posterior, y los espacios de nombres basados en dominio deben usar el modo Windows Server 2008. Para más detalles, véase Habilitar la enumeración basada en acceso en un espacio de nombres.

Como no puedes habilitar ABE en un recurso compartido de archivos de Azure, usar ABE para controlar la visibilidad de archivos y carpetas dentro de un recurso compartido de SMB en Azure no es un escenario compatible. Esta limitación existe porque DFS-N funciona por referencia en lugar de como un proxy delante del destino de la carpeta. Cuando un usuario escribe \\mydfsnserver\share, el cliente SMB recibe la referencia \\mydfsnserver\share => \\server123\share y monta esta última directamente, de modo que el servidor DFS-N ya no está en la ruta de datos.

ABE solo funciona cuando el servidor DFS-N aloja el nivel de la jerarquía que quieres filtrar, antes de la redirección. Ambos diseños siguientes funcionan, porque los nombres de las carpetas por usuario están en el espacio de nombres del servidor DFS-N:

• \\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\contosouser1
• \\DFSServer\users\contosouser1 => \\SA.file.core.windows.net\users\contosouser1, donde contosouser1 es una subcarpeta del users share.

Si cada usuario es una subcarpeta después de la redirección, ABE no funciona, porque las carpetas de cada usuario nunca son enumeradas por el servidor DFS-N:

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

Consulte también

• Configuración del acceso al recurso compartido de archivos: consideraciones sobre la autenticación basada en identidades y redes para el acceso directo.
• Introducción a los espacios de nombres DFS
• Implementar espacios de nombres DFS
• Elegir un tipo de espacio de nombres
• netdom computername
• setspn
• El acceso al recurso compartido del servidor de archivos SMB no funciona a través de un alias CNAME de DNS
• Crear un clúster de conmutación por error