Uso de Azure Files con varios bosques de Active Directory

Artículo
11/21/2023

Muchas organizaciones quieren usar la autenticación basada en identidades para recursos compartidos de archivos de Azure SMB en entornos que tienen varios bosques de Active Directory local Domain Services (AD DS). Se trata de un escenario común de TI, especialmente después de fusiones y adquisiciones, donde los bosques de AD de la empresa adquirida están aislados de los bosques de AD de la empresa matriz. En este artículo se explica cómo funcionan las relaciones de confianza de bosque y se proporcionan instrucciones paso a paso para la configuración y validación de varios bosques.

Importante

Si desea establecer permisos de nivel de recurso compartido para usuarios o grupos específicos de Microsoft Entra mediante el control de acceso basado en rol (RBAC) de Azure, primero debe sincronizar las cuentas de AD locales con Microsoft Entra ID mediante Microsoft Entra Connect. También puede usar un permiso de nivel de recurso compartido predeterminado.

Se aplica a

Tipo de recurso compartido de archivos	SMB	NFS
Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS
Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS
Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS

Requisitos previos

Dos controladores de dominio de AD DS con bosques diferentes y en diferentes redes virtuales (VNET)
Permisos suficientes de AD para realizar tareas administrativas (por ejemplo, Administración de dominio )
Si usa RBAC de Azure, un único servidor de sincronización de Microsoft Entra Connect debe ser accesible para ambos bosques.

Funcionamiento de las relaciones de confianza de bosque

La autenticación con AD DS local para Azure Files solo se admite con el bosque del servicio de dominio en el que está registrada la cuenta de almacenamiento. De forma predeterminada, solo se puede acceder a los recursos compartidos de archivos de Azure con las credenciales de AD DS desde un solo bosque. Si necesita acceder al recurso compartido de archivos de Azure desde un bosque diferente, debe configurar una confianza de bosque.

Una confianza de bosque es una confianza transitiva entre dos bosques de AD que permite a los usuarios de cualquiera de los dominios de un bosque autenticarse en cualquiera de los dominios del otro bosque.

Configuración de varios bosques

Para configurar una configuración de varios bosques, realizaremos los pasos siguientes:

Recopilación de información de dominio y conexiones de red virtual entre dominios
Establecimiento y configuración de una confianza de bosque
Configuración de la autenticación basada en identidades y cuentas de usuario híbridas

Recopilación de información de dominio

En este ejercicio, tenemos dos controladores de dominio de AD DS locales con dos bosques diferentes y en redes virtuales diferentes.

Bosque	Dominio	VNET
Bosque 1	onpremad1.com	DomainServicesVNet WUS
Bosque 2	onpremad2.com	vnet2/workloads

Establecimiento y configuración de una confianza

Para permitir que los clientes del Bosque 1 accedan a Azure Files recursos de dominio del Bosque 2, debemos establecer una confianza entre los dos bosques. Siga estos pasos para establecer la confianza.

Inicie sesión en una máquina unida a un dominio en Bosque 2 y abra la consola Dominios y confianzas de Active Directory.
Haga clic con el botón derecho en el dominio local onpremad2.com y, a continuación, seleccione la pestaña Confianzas.
Seleccione Nuevas confianzas para iniciar el Asistente para nueva confianza.
Especifique el nombre de dominio con el que desea crear confianza (en este ejemplo, onpremad1.com) y, a continuación, seleccione Siguiente.
En Tipo de confianza, seleccione Confianza de bosque y, a continuación, seleccione Siguiente.

Nota:

Solo se admiten las confianzas de bosque para Azure Files. No se admiten otros tipos de confianza, como las confianzas externas.
En Direction of Trust (Dirección de confianza), seleccione Two-way (Bidireccional) y, a continuación, seleccione Next (Siguiente).
En Lados de confianza, seleccione Este dominio solo y, a continuación, seleccione Siguiente.
Los usuarios del bosque especificado se pueden autenticar para usar todos los recursos del bosque local (autenticación en todo el bosque) o solo aquellos recursos que seleccione (autenticación selectiva). En Nivel de autenticación de confianza saliente, seleccione Autenticación en todo el bosque, que es la opción preferida cuando ambos bosques pertenecen a la misma organización. Seleccione Next (Siguiente).
Escriba una contraseña para la confianza y, a continuación, seleccione Siguiente. Se debe usar la misma contraseña al crear esta relación de confianza en el dominio especificado.
Debería ver un mensaje que indica que la relación de confianza se ha creado correctamente. Para configurar la confianza, seleccione Siguiente.
Confirme la confianza saliente y seleccione Siguiente.
Escriba el nombre de usuario y la contraseña de un usuario que tenga privilegios de administrador del otro dominio.

Una vez que se supera la autenticación, se establece la confianza y debería poder ver el dominio especificado onpremad1.com en la pestaña Confianzas.

Configuración de la autenticación basada en identidades y cuentas de usuario híbridas

Una vez que se establezca la confianza, siga estos pasos para crear una cuenta de almacenamiento y un recurso compartido de archivos SMB para cada dominio, habilitar la autenticación de AD DS en las cuentas de almacenamiento y crear cuentas de usuario híbridas sincronizadas con Microsoft Entra ID.

Inicie sesión en el Azure Portal y cree dos cuentas de almacenamiento como onprem1sa y onprem2sa. Para conseguir un rendimiento óptimo, se recomienda implementar la cuenta de almacenamiento en la misma región que el cliente desde el que vaya a acceder al recurso compartido.

Nota

No es necesario crear una segunda cuenta de almacenamiento. Estas instrucciones están diseñadas para mostrar un ejemplo de cómo acceder a las cuentas de almacenamiento que pertenecen a distintos bosques. Si solo tiene una cuenta de almacenamiento, puede omitir las segundas instrucciones de configuración de la cuenta de almacenamiento.
Cree un recurso compartido de archivos de Azure SMB en cada cuenta de almacenamiento.
Sincronice el AD local con Microsoft Entra ID mediante la aplicación de sincronización de Microsoft Entra Connect.
Unión a un dominio de una máquina virtual de Azure en Bosque 1 a su AD DS local. Para información acerca de cómo unirse a un dominio, consulte Unión de un equipo a un dominio.
Habilite la autenticación de AD DS en la cuenta de almacenamiento asociada al Bosque 1, por ejemplo , onprem1sa. Esto creará una cuenta de equipo en la instancia local de AD denominada onprem1sa para representar la cuenta de Almacenamiento de Azure y unirla a la cuenta de almacenamiento al dominio onpremad1.com. Puede comprobar que la identidad de AD que representa la cuenta de almacenamiento se creó buscando en Usuarios y equipos de Active Directory para obtener onpremad1.com. En este ejemplo, verá una cuenta de equipo denominada onprem1sa.
Para crear una cuenta de usuario, vaya a Active Directory > onpremad1.com. Haga clic con el botón derecho en Usuarios, seleccione Crear, escriba un nombre de usuario (por ejemplo, onprem1user) y active la casilla Contraseña nunca expira (opcional).
Opcional: si desea usar Azure RBAC para asignar permisos de nivel de recurso compartido, debe sincronizar el usuario con el identificador de Microsoft Entra mediante Microsoft Entra Connect. Normalmente, Microsoft Entra Connect Sync se actualiza cada 30 minutos. Sin embargo, puede forzar que se sincronice inmediatamente abriendo una sesión de PowerShell con privilegios elevados y ejecutando Start-ADSyncSyncCycle -PolicyType Delta. Es posible que primero tenga que instalar el módulo ADSync mediante la ejecución Import-Module ADSync. Para comprobar que el usuario se ha sincronizado con Microsoft Entra ID, inicie sesión en Azure Portal con la suscripción de Azure asociada al inquilino de varios bosques y seleccione Microsoft Entra ID. Seleccione Administrar > usuarios y busque el usuario que agregó (por ejemplo, onprem1user). La sincronización local habilitada debe indicar Sí.
Establezca permisos de nivel de recurso compartido mediante roles RBAC de Azure o un permiso de nivel de recurso compartido predeterminado.
- Si el usuario se sincroniza con Microsoft Entra ID, puede conceder un permiso de nivel de recurso compartido (rol RBAC de Azure) al usuario onprem1user en la cuenta de almacenamiento onprem1sa para que el usuario pueda montar el recurso compartido de archivos. Para ello, vaya al recurso compartido de archivos que ha creado en onprem1sa y siga las instrucciones de Asignación de permisos de nivel de recurso compartido para grupos o usuarios específicos de Microsoft Entra.
- De lo contrario, puede usar un permiso de nivel de recurso compartido predeterminado que se aplique a todas las identidades autenticadas.

Repita los pasos del 4 al 8 para el dominio onpremad2.com (cuenta de usuario onprem2sa/user onprem2user) de Bosque2. Si tiene más de dos bosques, repita los pasos de cada bosque.

Configuración de permisos de directorio y de nivel de archivo (opcional)

En un entorno de varios bosques, use la utilidad de línea de comandos icacls para configurar los permisos de nivel de archivo y directorio para los usuarios de ambos bosques. Consulte Configuración de ACL de Windows con icacls.

Si se produce un error de icacls con un error de acceso denegado, siga estos pasos para configurar los permisos de nivel de archivo y directorio montando el recurso compartido con la clave de la cuenta de almacenamiento.

Elimine el montaje del recurso compartido existente: net use * /delete /y

Vuelva a montar el recurso compartido mediante la clave de la cuenta de almacenamiento:

net use <driveletter> \\storageaccount.file.core.windows.net\sharename /user:AZURE\<storageaccountname> <storageaccountkey>

Establezca los permisos de icacls para el usuario de Forest2 en la cuenta de almacenamiento unida a Forest1 desde el cliente de Forest1.

Nota

No se recomienda usar Explorador de archivos para configurar las ACL en un entorno de varios bosques. Aunque los usuarios que pertenecen al bosque unido a un dominio a la cuenta de almacenamiento pueden tener permisos de nivel de archivo o directorio establecidos a través del Explorador de archivos, no funcionará para los usuarios que no pertenecen al mismo bosque unido a un dominio a la cuenta de almacenamiento.

Configurar sufijos de dominio

Como se explicó anteriormente, la forma en que Azure Files registra en AD DS es casi igual que un servidor de archivos normal, donde crea una identidad (de forma predeterminada, una cuenta de equipo, también podría ser una cuenta de inicio de sesión de servicio) que representa la cuenta de almacenamiento en AD DS para la autenticación. La única diferencia es que el nombre de entidad de seguridad de servicio registrado de la cuenta de almacenamiento finaliza en file.core.windows.net, que no coincide con el sufijo del dominio. Debido al sufijo de dominio diferente, deberá configurar una directiva de enrutamiento de sufijos para habilitar la autenticación de varios bosques.

Dado que el sufijo file.core.windows.net es el sufijo de todos los recursos de Azure Files en lugar de un sufijo para un dominio de AD específico, el controlador de dominio del cliente no sabe a qué dominio reenviar la solicitud y, por tanto, producirá un error en todas las solicitudes en las que el recurso no se encuentre en su propio dominio.

Por ejemplo, cuando los usuarios de un dominio del Bosque 1 quieren llegar a un recurso compartido de archivos con la cuenta de almacenamiento registrada en un dominio del Bosque 2, esto no funcionará automáticamente porque la entidad de servicio de la cuenta de almacenamiento no tiene un sufijo que coincida con el sufijo de ningún dominio del Bosque 1.

Para configurar sufijos de dominio, emplee uno de los métodos siguientes:

Modifique el sufijo de la cuenta de almacenamiento y agregue un registro CNAME (recomendado: funcionará con dos o más bosques)
Agregue el sufijo de nombre personalizado y regla de enrutamiento (no funcionará con más de dos bosques)

Modifique el sufijo del nombre de la cuenta de almacenamiento y añada un registro CNAME

Para resolver el problema de enrutamiento de dominio, modifique el sufijo del nombre de la cuenta de almacenamiento asociado al recurso compartido de archivos de Azure y agregue un registro CNAME para enrutar el nuevo sufijo al punto de conexión de la cuenta de almacenamiento. Con esta configuración, los clientes unidos a un dominio pueden acceder a las cuentas de almacenamiento unidas a cualquier bosque. Esto funciona para entornos que tienen dos o más bosques.

En nuestro ejemplo, tenemos los dominios onpremad1.com y onpremad2.com, y tenemos onprem1sa y onprem2sa como cuentas de almacenamiento asociadas a recursos compartidos de archivos de Azure SMB en los dominios respectivos. Estos dominios se encuentran en bosques diferentes que confían entre sí para acceder a los recursos de los bosques de los demás. Queremos permitir el acceso a ambas cuentas de almacenamiento de clientes que pertenecen a cada bosque. Para ello, es necesario modificar los sufijos de SPN de la cuenta de almacenamiento:

onprem1sa.onpremad1.com -> onprem1sa.file.core.windows.net

onprem2sa.onpremad2.com -> onprem2sa.file.core.windows.net

Esto permitirá a los clientes montar el recurso compartido con net use \\onprem1sa.onpremad1.com porque los clientes de onpremad1 o onpremad2 sabrán buscar onpremad1.com encontrar el recurso adecuado para esa cuenta de almacenamiento.

Para usar este método, complete los pasos siguientes:

Asegúrese de que ha establecido confianza entre los dos bosques y ha configurado la autenticación basada en identidades y las cuentas de usuario híbridas, como se describe en las secciones anteriores.
Modifique el SPN de la cuenta de almacenamiento mediante la herramienta setspn. Para encontrar <DomainDnsRoot>, ejecute el siguiente comando de PowerShell de Active Directory: (Get-AdDomain).DnsRoot
```
setspn -s cifs/<storage-account-name>.<DomainDnsRoot> <storage-account-name>
```
Agregue una entrada CNAME mediante el Administrador DNS de Active Directory y siga los pasos siguientes para cada cuenta de almacenamiento del dominio al que está unida la cuenta de almacenamiento. Si usa un punto de conexión privado, agregue la entrada CNAME para asignarla al nombre del punto de conexión privado.
1. Abra el Administrador DNS de Active Directory.
2. Vaya a su dominio (por ejemplo, onpremad1.com).
3. Vaya a "Zonas de búsqueda directa".
4. Seleccione el nodo denominado después del dominio (por ejemplo, onpremad1.com) y haga clic con el botón derecho en Nuevo alias (CNAME).
5. En el nombre del alias, escriba el nombre de la cuenta de almacenamiento.
6. Para el nombre de dominio completo (FQDN), escriba <storage-account-name>.<domain-name>, como mystorageaccount.onpremad1.com.
7. Para el FQDN del host de destino, escriba <storage-account-name>.file.core.windows.net
8. Seleccione Aceptar.

Ahora, desde clientes unidos a un dominio, debería poder usar cuentas de almacenamiento unidas a cualquier bosque.

Nota:

Asegúrese de que la parte de nombre de host del FQDN coincide con el nombre de la cuenta de almacenamiento, como se ha descrito anteriormente. De lo contrario, recibe un error de acceso denegado: "La sintaxis de nombre de archivo, nombre de directorio o etiqueta de volumen es incorrecta". Un seguimiento de red mostrará STATUS_OBJECT_NAME_INVALID (0xc0000033) mensaje durante la configuración de la sesión de SMB.

Agregar sufijo de nombre personalizado y regla de enrutamiento

Si ya ha modificado el sufijo del nombre de la cuenta de almacenamiento y ha agregado un registro CNAME como se describe en la sección anterior, puede omitir este paso. Si prefiere no realizar cambios en DNS ni modificar el sufijo de nombre de la cuenta de almacenamiento, puede configurar una regla de enrutamiento de sufijos de Bosque 1 a Bosque 2 para un sufijo personalizado de file.core.windows.net.

Nota

La configuración del enrutamiento de sufijos de nombres no afecta a la capacidad de acceder a los recursos del dominio local. Solo es necesario permitir que el cliente reenvíe la solicitud al dominio que coincida con el sufijo cuando el recurso no se encuentre en su propio dominio.

En primer lugar, agregue un nuevo sufijo personalizado en Bosque 2. Asegúrese de que tiene los permisos administrativos adecuados para cambiar la configuración y de que ha establecido la confianza entre los dos bosques. A continuación, siga estos pasos:

Inicie sesión en una máquina o máquina virtual que esté unida a un dominio en el bosque 2.
Abra la consola Dominios y confianzas de Active Directory.
Haga clic con el botón derecho en Dominios y confianzas de Active Directory.
Seleccione Propiedades y luego seleccione Añadir.
Agregue el sufijo "file.core.windows.net" como sufijo de UPN.
Seleccione Aplicar y, después, Aceptar para cerrar el asistente.

A continuación, agregue la regla de enrutamiento de sufijos en el Bosque 1 para que se redirija al Bosque 2.

Inicie sesión en una máquina o máquina virtual que esté unida a un dominio en el Bosque 1.
Abra la consola Dominios y confianzas de Active Directory.
Haga clic con el botón derecho en el dominio desde el cual quiera acceder al recurso compartido de archivos, haga clic en la pestaña Confianzas y seleccione el dominio del Bosque 2 en las confianzas de salida.
Seleccione Propiedades y, a continuación, Enrutamiento de sufijo de nombre.
Compruebe si aparece el sufijo "*.file.core.windows.net". Si no es así, seleccione Actualizar.
Seleccione "*.file.core.windows.net", y Habilitar y Aplicar.

Valide que la confianza funciona

Ahora validaremos que la confianza funciona ejecutando el comando klist para mostrar el contenido de la caché de credenciales de Kerberos y la tabla de claves.

Inicie sesión en una máquina o máquina virtual que esté unida a un dominio en el bosque 1 y abra un símbolo del sistema de Windows.
Para mostrar la caché de credenciales de la cuenta de almacenamiento unida a un dominio en el Bosque 2, ejecute uno de los siguientes comandos:
- Si usó el sufijo Modify storage account name (Modificar el sufijo de la cuenta de almacenamiento) y agregar el método de registro CNAME , ejecute: klist get cifs/onprem2sa.onpremad2.com
- Si usó el método agregar sufijo de nombre personalizado y regla de enrutamiento, ejecute: klist get cifs/onprem2sa.file.core.windows.net
Debería ver una salida similar a la siguiente. La salida klist variará ligeramente en función del método que usó para configurar los sufijos de dominio.

Client: onprem1user @ ONPREMAD1.COM
Server: cifs/onprem2sa.file.core.windows.net @ ONPREMAD2.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 11/22/2022 18:45:02 (local)
End Time: 11/23/2022 4:45:02 (local)
Renew Time: 11/29/2022 18:45:02 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x200 -> DISABLE-TGT-DELEGATION
Kdc Called: onprem2.onpremad2.com

Inicie sesión en una máquina o máquina virtual que esté unida a un dominio en el Bosque 2 y abra un símbolo del sistema de Windows.
Para mostrar la caché de credenciales de la cuenta de almacenamiento unida a un dominio en el Bosque 1, ejecute uno de los siguientes comandos:
- Si usó el sufijo Modify storage account name (Modificar el sufijo de la cuenta de almacenamiento) y agregar el método de registro CNAME , ejecute: klist get cifs/onprem1sa.onpremad1.com
- Si usó el método agregar sufijo de nombre personalizado y regla de enrutamiento, ejecute: klist get cifs/onprem1sa.file.core.windows.net
Debería ver una salida similar a la siguiente. La salida klist variará ligeramente en función del método que usó para configurar los sufijos de dominio.

Client: onprem2user @ ONPREMAD2.COM
Server: krbtgt/ONPREMAD2.COM @ ONPREMAD2.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 11/22/2022 18:46:35 (local)
End Time: 11/23/2022 4:46:35 (local)
Renew Time: 11/29/2022 18:46:35 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x1 -> PRIMARY
Kdc Called: onprem2

Client: onprem2user @ ONPREMAD2.COM    
Server: cifs/onprem1sa.file.core.windows.net @ ONPREMAD1.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 11/22/2022 18:46:35 (local)
End Time: 11/23/2022 4:46:35 (local)
Renew Time: 11/29/2022 18:46:35 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x200 -> DISABLE-TGT-DELEGATION
Kdc Called: onpremad1.onpremad1.com

Si ve la salida anterior, ha terminado. Si no lo hace, siga estos pasos para proporcionar sufijos UPN alternativos para que la autenticación de varios bosques funcione.