Configuración de una confianza en la nube entre AD DS local y Microsoft Entra ID para acceder a Azure Files
Muchas organizaciones quieren usar la autenticación basada en identidades para los recursos compartidos de archivos de Azure SMB en entornos que abarcan active Directory Domain Services (AD DS) local y Microsoft Entra ID (anteriormente Azure Active Directory), pero no cumplen los requisitos previos necesarios de sistema operativo o dominio.
En estos escenarios, los clientes pueden habilitar la autenticación Kerberos de Microsoft Entra para identidades de usuario híbrido y, a continuación, establecer una confianza en la nube entre su identificador de AD DS local y Microsoft Entra para acceder a los recursos compartidos de archivos SMB mediante sus credenciales locales. En este artículo se explica cómo funciona una confianza en la nube y se proporcionan instrucciones de configuración y validación. También incluye pasos para rotar una clave Kerberos para su cuenta de servicio en Microsoft Entra ID y Objeto de dominio de confianza, y pasos para quitar un objeto de dominio de confianza y toda la configuración de Kerberos, si lo desea.
Este artículo se centra en la autenticación de identidades de usuario híbrido, que son identidades de AD DS locales que se sincronizan con Microsoft Entra ID mediante Microsoft Entra Connect o Sincronización en la nube de Microsoft Entra Connect. Actualmente no se admiten identidades solo en la nube para Azure Files.
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 |
Escenarios
A continuación se muestran ejemplos de escenarios en los que es posible que desee configurar una confianza en la nube:
Tiene un AD DS local tradicional, pero no puede usarlo para la autenticación porque no tiene conectividad de red impedida a los controladores de dominio.
Ha empezado a migrar a la nube, pero actualmente tiene aplicaciones que se ejecutan en AD DS local tradicional.
Algunas o todas las máquinas cliente no cumplen los requisitos del sistema operativo para la autenticación Kerberos de Microsoft Entra.
Permisos
Para completar los pasos descritos en este artículo, necesitará lo siguiente:
- Nombre de usuario y contraseña de administrador de Active Directory local
- Nombre de usuario y contraseña de la cuenta de administrador global de Microsoft Entra
Requisitos previos
Antes de implementar el flujo de autenticación basada en confianza entrante, asegúrese de que se cumplen los siguientes requisitos previos:
Requisito previo | Descripción |
---|---|
Los clientes deben ejecutar Windows 10, Windows Server 2012 o una versión superior de Windows. | |
Los clientes deben estar unidos a Active Directory (AD). El dominio debe tener un nivel funcional de Windows Server 2012 o versiones superiores. | Para determinar si el cliente se unió a AD, ejecute el comando dsregcmd: dsregcmd.exe /status |
Un inquilino de Microsoft Entra. | Un inquilino de Microsoft Entra es un límite de seguridad de identidad que está bajo el control del departamento de TI de su organización. Es una instancia de Microsoft Entra ID en la que reside información sobre una sola organización. |
Una suscripción de Azure en el mismo inquilino de Microsoft Entra que planea usar para la autenticación. | |
Una cuenta de Azure Storage en la suscripción de Azure. | Una cuenta de almacenamiento de Azure es un recurso que actúa como contenedor para agrupar todos los servicios de datos de Azure Storage, incluidos los archivos. |
Microsoft Entra Connect o Sincronización en la nube de Microsoft Entra Connect deben estar instalados. | Estas soluciones se usan en entornos híbridos donde existen identidades tanto en Microsoft Entra ID como en AD DS local. |
Habilitación de la autenticación Kerberos de Microsoft Entra
Si ya ha habilitado la autenticación Kerberos de Microsoft Entra en la cuenta de almacenamiento, puede omitir este paso y continuar con Crear y configurar el objeto de dominio de confianza Kerberos de Microsoft Entra.
La autenticación Kerberos de Microsoft Entra se puede habilitar en Azure Files para cuentas de usuario híbridas mediante Azure Portal, PowerShell o la CLI de Azure.
Siga estos pasos para habilitar la autenticación Kerberos de Microsoft Entra mediante Azure Portal.
Inicie sesión en Azure Portal y seleccione la cuenta de almacenamiento para la que quiere habilitar la autenticación Kerberos de Microsoft Entra.
En Almacenamiento de datos, seleccione Recursos compartidos de archivos.
Junto a Active Directory, seleccione el estado de configuración (por ejemplo, No configurado).
En Kerberos de Microsoft Entra, seleccione Configurar.
Active la casilla Kerberos de Microsoft Entra.
Opcional: Si quiere configurar los permisos de directorio y de nivel de archivo a través de Explorador de archivos de Windows, debe especificar el nombre de dominio y el GUID de dominio de la instancia de AD local. Puede obtener esta información del administrador del dominio o ejecutando el siguiente cmdlet de PowerShell de Active Directory desde un cliente unido a la instancia de AD local:
Get-ADDomain
. El nombre de dominio debe aparecer en la salida deDNSRoot
y el GUID de dominio debe aparecer enObjectGUID
. Si prefiere configurar los permisos de directorio y de nivel de archivo mediante icacls, puede omitir este paso. Sin embargo, si quiere usar icacls, el cliente deberá tener conectividad de red no impedida al AD local.Seleccione Guardar.
Advertencia
Si ha habilitado previamente la autenticación Kerberos de Microsoft Entra mediante pasos manuales de versión preliminar limitada para almacenar perfiles de FSLogix en Azure Files para máquinas virtuales unidas a Microsoft Entra, se establece que la contraseña de la entidad de servicio de la cuenta de almacenamiento expire cada seis meses. Una vez que expire la contraseña, los usuarios no podrán obtener vales de Kerberos para el recurso compartido de archivos. Para mitigarlo, consulte "Error: la contraseña de la entidad de servicio ha expirado en Microsoft Entra ID" en Posibles errores cuando se habilita la autenticación Kerberos de Microsoft Entra para usuarios híbridos.
Concesión de consentimiento del administrador a la nueva entidad de servicio
Después de habilitar la autenticación Kerberos de Microsoft Entra, deberá conceder de manera explícita el consentimiento del administrador a la nueva aplicación de Microsoft Entra que está registrada en el inquilino de Microsoft Entra. Esta entidad de servicio se genera automáticamente y no se usa para la autorización del recurso compartido de archivos, por lo que no realice modificaciones en la entidad de servicio que no sean las documentadas aquí. Si lo hace, podría recibir un error.
Puede configurar los permisos de API desde Azure Portal mediante estos pasos:
- Abra Microsoft Entra ID.
- En el menú de servicio, en Administrar, seleccione Registros de aplicaciones.
- Seleccione Todas las aplicaciones.
- Seleccione la aplicación con el nombre [Cuenta de almacenamiento]
<your-storage-account-name>
.file.core.windows.net. - En el menú de servicio, en Administrar, seleccione Permisos de API.
- Seleccione Conceder consentimiento del administrador para [nombre de directorio] para conceder consentimiento para los tres permisos de API solicitados (openid, profile y User.Read) para todas las cuentas del directorio.
- Seleccione Sí para confirmar la acción.
Importante
Si se conecta a una cuenta de almacenamiento mediante un punto de conexión privado o un vínculo privado con la autenticación Kerberos de Microsoft Entra, también deberá agregar el FQDN del vínculo privado a la aplicación de Microsoft Entra de la cuenta de almacenamiento. Para obtener instrucciones, consulte la entrada en nuestra guía de solución de problemas.
Deshabilitación de la autenticación multifactor en la cuenta de almacenamiento
Kerberos de Microsoft Entra no admite el uso de MFA para acceder a recursos compartidos de archivos de Azure que estén configurados con Kerberos de Microsoft Entra. Debe excluir la aplicación de Microsoft Entra que representa la cuenta de almacenamiento de las directivas de acceso condicional de MFA si se aplican a todas las aplicaciones.
La aplicación de cuenta de almacenamiento debe tener el mismo nombre que la cuenta de almacenamiento de la lista de exclusión de acceso condicional. Al buscar la aplicación de cuenta de almacenamiento en la lista de exclusión de acceso condicional, busque lo siguiente: [Cuenta de almacenamiento] <your-storage-account-name>
.file.core.windows.net.
No olvide reemplazar <your-storage-account-name>
por el valor adecuado.
Importante
Si no excluye las directivas de MFA de la aplicación de cuenta de almacenamiento, no podrá acceder al recurso compartido. Si intenta asignar el recurso compartido de archivos mediante net use
, se producirá un mensaje de error que indica "Error del sistema 1327: Las restricciones de cuenta impiden a este usuario iniciar sesión. Por ejemplo: no se permiten contraseñas en blanco, las horas de inicio de sesión están limitadas o se aplicó una restricción de directiva".
Para obtener instrucciones sobre cómo deshabilitar MFA, vea lo siguiente:
- Incorporación de exclusiones para entidades de servicio de recursos de Azure
- Creación de una directiva de acceso condicional
Asignación de permisos de nivel de recurso compartido
Al habilitar el acceso basado en identidades, para cada recurso compartido debe asignar qué usuarios y grupos tienen acceso a ese recurso compartido determinado. Una vez que se permite el acceso de un usuario o grupo a un recurso compartido, las ACL de Windows (también denominadas permisos NTFS) en los directorios y archivos individuales toman el control. Esto permite un control específico sobre los permisos, similar a un recurso compartido SMB en un servidor Windows.
Para establecer permisos de nivel de recurso compartido, siga las instrucciones de Asignación de permisos de nivel de recurso compartido a una identidad.
Configuración de permisos de directorio y de nivel de archivo
Una vez implementados los permisos de nivel de recurso compartido, puede asignar permisos de nivel de directorio o de archivo al usuario o grupo. Para ello debe usarse un dispositivo con conectividad de red no impedida a un AD local.
Para configurar los permisos de directorio y de nivel de archivo, siga las instrucciones de Configuración de permisos de directorio y de nivel de archivo a través de SMB.
Creación y configuración del objeto de dominio de confianza Kerberos de Azure AD
Para crear y configurar el objeto de dominio de confianza de Microsoft Entra Kerberos, usará el módulo de PowerShell Administración de autenticación híbrida de Azure AD. Este módulo permite a las organizaciones de identidad híbrida usar credenciales modernas para sus aplicaciones y permite a Microsoft Entra ID convertirse en el origen de confianza para la autenticación tanto en la nube como en el entorno local.
Configuración del objeto de dominio de confianza
Usará el módulo de PowerShell de administración de autenticación híbrida de Azure AD para configurar un objeto de dominio de confianza en el dominio de AD local y registrar información de confianza con Microsoft Entra ID. Esto crea una relación de confianza de entrada en la instancia de AD local, lo que permite que Microsoft Entra ID confíe en AD local.
Solo tiene que configurar el objeto de dominio de confianza una vez por dominio. Si ya lo ha hecho para el dominio, puede omitir esta sección y continuar con Configurar los clientes para recuperar vales de Kerberos.
Instalación del módulo de PowerShell para la administración de la autenticación de Azure AD local
Inicie una sesión de Windows PowerShell con la opción Ejecutar como administrador.
Use el script siguiente para instalar el módulo de PowerShell para la administración de la autenticación de Azure AD híbrido. El script:
- Habilita TLS 1.2 para la comunicación.
- Instala el proveedor de paquetes NuGet.
- Registra el repositorio PSGallery.
- Instala el módulo PowerShellGet.
- Instala el módulo de PowerShell para la administración de la autenticación de Azure AD local.
- Azure AD Hybrid Authentication Management PowerShell usa el módulo AzureADPreview, que proporciona características avanzadas de administración de Microsoft Entra.
- Para protegerse frente a conflictos de instalación innecesarios con el módulo de PowerShell de Azure AD, este comando incluye la marca de opción
-AllowClobber
.
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Install-PackageProvider -Name NuGet -Force
if (@(Get-PSRepository | ? {$_.Name -eq "PSGallery"}).Count -eq 0){
Register-PSRepository -DefaultSet-PSRepository -Name "PSGallery" -InstallationPolicy Trusted
}
Install-Module -Name PowerShellGet -Force
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
Creación del objeto de dominio de confianza
Inicie una sesión de Windows PowerShell con la opción Ejecutar como administrador.
Establezca los parámetros comunes. Personalice el script siguiente antes de ejecutarlo.
- Establezca el parámetro
$domain
en el nombre de dominio de Active Directory local. - Cuando
Get-Credential
lo solicite, escriba el nombre de usuario y la contraseña de un administrador de Active Directory local. - Establezca el parámetro
$cloudUserName
en el nombre de usuario de una cuenta con privilegios de administrador global para obtener acceso a la nube de Microsoft Entra.
Nota:
Si desea usar su cuenta de inicio de sesión de Windows actual para el acceso a Active Directory local, puede omitir el paso en el que se asignan credenciales al parámetro
$domainCred
. Si usa este enfoque, no incluya el parámetro-DomainCredential
en los comandos de PowerShell después de este paso.$domain = "your on-premesis domain name, for example contoso.com" $domainCred = Get-Credential $cloudUserName = "Azure AD user principal name, for example admin@contoso.onmicrosoft.com"
- Establezca el parámetro
Compruebe la configuración actual de Kerberos del dominio.
Ejecute el comando siguiente para comprobar la configuración actual de Kerberos del dominio:
Get-AzureAdKerberosServer -Domain $domain ` -DomainCredential $domainCred ` -UserPrincipalName $cloudUserName
Si es la primera vez que usa algún comando Kerberos de Microsoft Entra, se le pide acceso a la nube de Microsoft Entra.
- Introduzca la contraseña para su cuenta de administrador global de Microsoft Entra.
- Si la organización utiliza otros métodos de autenticación modernos, como la autenticación multifactor de Microsoft Entra o la tarjeta inteligente, siga las instrucciones que se solicitan para el inicio de sesión.
Si es la primera vez que configura las opciones de Kerberos de Microsoft Entra, el cmdlet Get-AzureAdKerberosServer mostrará información vacía, como en la salida de ejemplo siguiente:
ID : UserAccount : ComputerAccount : DisplayName : DomainDnsName : KeyVersion : KeyUpdatedOn : KeyUpdatedFrom : CloudDisplayName : CloudDomainDnsName : CloudId : CloudKeyVersion : CloudKeyUpdatedOn : CloudTrustDisplay :
Si el dominio ya admite la autenticación FIDO, el cmdlet
Get-AzureAdKerberosServer
muestra información de la cuenta de servicio de Microsoft Entra, como en la siguiente salida de ejemplo. El campoCloudTrustDisplay
devuelve un valor vacío.ID : XXXXX UserAccount : CN=krbtgt-AzureAD, CN=Users, DC=contoso, DC=com ComputerAccount : CN=AzureADKerberos, OU=Domain Controllers, DC=contoso, DC=com DisplayName : XXXXXX_XXXXX DomainDnsName : contoso.com KeyVersion : 53325 KeyUpdatedOn : 2/24/2024 9:03:15 AM KeyUpdatedFrom : ds-aad-auth-dem.contoso.com CloudDisplayName : XXXXXX_XXXXX CloudDomainDnsName : contoso.com CloudId : XXXXX CloudKeyVersion : 53325 CloudKeyUpdatedOn : 2/24/2024 9:03:15 AM CloudTrustDisplay :
Agregue el objeto de dominio de confianza.
Ejecute el cmdlet Set-AzureAdKerberosServer PowerShell para agregar el objeto de dominio de confianza. No olvide incluir el parámetro
-SetupCloudTrust
. Si no hay ninguna cuenta de servicio de Microsoft Entra, este comando crea una nueva cuenta de servicio de Microsoft Entra. Si ya hay una cuenta de servicio de Microsoft Entra, este comando solo crea el objeto de dominio de confianza solicitado.Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $cloudUserName -DomainCredential $domainCred -SetupCloudTrust
Nota:
En un bosque de varios dominios, para evitar el error LsaCreateTrustedDomainEx 0x549 al ejecutar el comando en un dominio secundario:
- Ejecute el comando en el dominio raíz (incluya el parámetro
-SetupCloudTrust
). - Ejecute el mismo comando en el dominio secundario sin el parámetro
-SetupCloudTrust
.
Después de crear el objeto de dominio de confianza, puede comprobar la configuración actualizada de Kerberos con el cmdlet
Get-AzureAdKerberosServer
de PowerShell, tal como se mostró en el paso anterior. Si el cmdletSet-AzureAdKerberosServer
se ejecutó correctamente con el parámetro-SetupCloudTrust
, el campoCloudTrustDisplay
ahora debería devolverMicrosoft.AzureAD.Kdc.Service.TrustDisplay
, como en la salida de ejemplo siguiente:ID : XXXXX UserAccount : CN=krbtgt-AzureAD, CN=Users, DC=contoso, DC=com ComputerAccount : CN=AzureADKerberos, OU=Domain Controllers, DC=contoso, DC=com DisplayName : XXXXXX_XXXXX DomainDnsName : contoso.com KeyVersion : 53325 KeyUpdatedOn : 2/24/2024 9:03:15 AM KeyUpdatedFrom : ds-aad-auth-dem.contoso.com CloudDisplayName : XXXXXX_XXXXX CloudDomainDnsName : contoso.com CloudId : XXXXX CloudKeyVersion : 53325 CloudKeyUpdatedOn : 2/24/2024 9:03:15 AM CloudTrustDisplay : Microsoft.AzureAD.Kdc.Service.TrustDisplay
Nota:
Las nubes soberanas de Azure requieren establecer la propiedad
TopLevelNames
, que se establece enwindows.net
de forma predeterminada. Las implementaciones en la nube soberana de Azure de SQL Managed Instance usan un nombre de dominio de nivel superior diferente, comousgovcloudapi.net
para Azure US Government. Establezca el objeto de dominio de confianza en ese nombre de dominio de nivel superior mediante el siguiente comando de PowerShell:Set-AzureADKerberosServer -Domain $domain -DomainCredential $domainCred -CloudCredential $cloudCred -SetupCloudTrust -TopLevelNames "usgovcloudapi.net,windows.net"
. Puede comprobar la configuración mediante el siguiente comando de PowerShell:Get-AzureAdKerberosServer -Domain $domain -DomainCredential $domainCred -UserPrincipalName $cloudUserName | Select-Object -ExpandProperty CloudTrustDisplay
.- Ejecute el comando en el dominio raíz (incluya el parámetro
Configuración de los clientes para recuperar vales de Kerberos
Identifique el identificador de inquilino de Microsoft Entra y use la directiva de grupo para configurar las máquinas cliente desde las que quiere montar o usar recursos compartidos de archivos de Azure. Debe hacerlo en todos los clientes en los que se vaya a usar Azure Files.
Configure esta directiva de grupo en los clientes como "Habilitado": Administrative Templates\System\Kerberos\Allow retrieving the Azure AD Kerberos Ticket Granting Ticket during logon
Implemente la configuración de directiva de grupo siguiente en máquinas cliente con el flujo basado en la confianza de entrada:
Edite la configuración de directiva Administrative Templates\System\Kerberos\Specify KDC proxy servers for Kerberos clients.
Seleccione Habilitado.
En Opciones, seleccione Mostrar…. Se abrirá el cuadro de diálogo Mostrar contenido.
Defina la configuración de los servidores proxy KDC mediante asignaciones, como se indica a continuación. Sustituya la cuenta empresarial de Microsoft Entra ID por el marcador de posición
your_Azure_AD_tenant_id
. Tenga en cuenta el espacio de después dehttps
y antes del/
de cierre en la asignación de valores.Nombre del valor Valor KERBEROS.MICROSOFTONLINE.COM <https login.microsoftonline.com:443: your_Azure_AD_tenant_id
/kerberos />Seleccione Aceptar para cerrar el cuadro de diálogo "Mostrar contenido".
Seleccione Aplicar en el cuadro de diálogo "Specify KDC proxy servers for Kerberos clients" (Especificar servidores proxy KDC para clientes Kerberos).
Rotación de la clave Kerberos
Puede rotar la clave Kerberos periódicamente para la cuenta de servicio de Microsoft Entra creada y el objeto de dominio de confianza con fines de administración.
Set-AzureAdKerberosServer -Domain $domain `
-DomainCredential $domainCred `
-UserPrincipalName $cloudUserName -SetupCloudTrust `
-RotateServerKey
Una vez que se rota la clave, la propagación de la clave modificada entre los servidores KDC de Kerberos tarda varias horas. Debido al tiempo que conlleva distribuir las claves, solo puede rotar una clave cada 24 horas. Si por cualquier motivo debe rotar la clave nuevamente dentro de ese plazo (por ejemplo, justo después de crear el objeto de dominio de confianza), puede agregar el parámetro -Force
:
Set-AzureAdKerberosServer -Domain $domain `
-DomainCredential $domainCred `
-UserPrincipalName $cloudUserName -SetupCloudTrust `
-RotateServerKey -Force
Eliminación del objeto de dominio de confianza
Para quitar el objeto de dominio de confianza, utilice el comando siguiente:
Remove-AzureADKerberosServerTrustedDomainObject -Domain $domain `
-DomainCredential $domainCred `
-UserPrincipalName $cloudUserName
Este comando solo quitará el objeto de dominio de confianza. Si el dominio admite la autenticación FIDO, es posible quitar el objeto de dominio de confianza a la vez que conserva la cuenta de servicio de Microsoft Entra que se necesita para el servicio de autenticación FIDO.
Eliminación de toda la configuración de Kerberos
Para quitar la cuenta de servicio de Microsoft Entra y el objeto de dominio de confianza, utilice el comando siguiente:
Remove-AzureAdKerberosServer -Domain $domain `
-DomainCredential $domainCred `
-UserPrincipalName $cloudUserName