Azure Files: Solución de problemas de autenticación basada en identidades y autorización (SMB)

En este artículo se enumeran los problemas comunes al usar recursos compartidos de archivos de SMB de Azure con autenticación basada en identidades. También se proporcionan posibles causas de estos problemas y sus resoluciones. La autenticación basada en identidades no se admite actualmente para recursos compartidos de archivos de NFS de Azure.

Al intentar ejecutar el módulo AzFilesHybrid, es posible que reciba el siguiente error:

El cliente no dispone de un privilegio requerido.

Este problema se produce porque no tiene los permisos necesarios de Active Directory (AD) para ejecutar el módulo.

Consulte los privilegios de AD o póngase en contacto con el administrador de AD para proporcionar los privilegios necesarios.

Al intentar montar un recurso compartido de archivos, puede recibir el siguiente error:

Error de sistema 5. Acceso denegado.

Si los usuarios finales acceden al recurso compartido de archivos de Azure mediante Servicios de dominio de Active Directory (AD DS) o la autenticación de Microsoft Entra Domain Services, se produce un error de acceso al recurso compartido de archivos con el error "Acceso denegado" si los permisos de nivel de recurso compartido son incorrectos.

Valide que los permisos están configurados correctamente:

• Active Directory Domain Services (AD DS), vea Asignación de permisos de nivel de recurso compartido.

  Las asignaciones de permisos de nivel de recurso compartido se admiten para grupos y usuarios que se han sincronizado desde AD DS a Identificador de Entra de Microsoft mediante Microsoft Entra Connect Sync o microsoft Entra Connect Cloud Sync. Confirme que los grupos y usuarios a los que se asignan permisos de nivel de recurso compartido no son grupos "solo en la nube" admitidos.

• Microsoft Entra Domain Services consulte Asignación de permisos de nivel de recurso compartido.

El error AadDsTenantNotFound se produce cuando intenta habilitar la autenticación de Microsoft Entra Domain Services para Azure Files en una cuenta de almacenamiento en la que Microsoft Entra Domain Services no se crea en el inquilino de Microsoft Entra de la suscripción asociada.

Habilite Microsoft Entra Domain Services en el inquilino de Microsoft Entra de la suscripción en la que se implementa la cuenta de almacenamiento. Necesita privilegios de administrador del inquilino de Microsoft Entra para crear un dominio administrado. Si no es el administrador del inquilino de Microsoft Entra, póngase en contacto con el administrador y siga las instrucciones paso a paso para crear y configurar un dominio administrado de Microsoft Entra Domain Services.

En primer lugar, asegúrese de que ha seguido los pasos para habilitar la autenticación de Azure Files AD DS.

En segundo lugar, pruebe a montar un recurso compartido de archivos de Azure con la clave de la cuenta de almacenamiento. Si el recurso compartido no se puede montar, descargue AzFileDiagnostics para ayudarle a validar el entorno en ejecución del cliente. AzFileDiagnostics puede detectar configuraciones de cliente incompatibles que pueden provocar un error de acceso de Azure Files, proporcionar instrucciones prescriptivas para la corrección automática y recopilar los seguimientos de diagnóstico.

En tercer lugar, puede ejecutar el Debug-AzStorageAccountAuth cmdlet para realizar un conjunto de comprobaciones básicas en la configuración de AD con el usuario de AD que inició sesión. Este cmdlet se admite en las versiones posteriores a AzFilesHybrid v 0.1.2. Este cmdlet se debe ejecutar con un usuario de AD que tenga permisos de propietario en la cuenta de almacenamiento de destino.

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Debug-AzStorageAccountAuth `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -Verbose

El cmdlet realiza estas comprobaciones de forma secuencial y proporciona instrucciones que seguir cuando aparezcan errores:

1. CheckADObjectPasswordIsCorrect: asegúrese de que la contraseña configurada en la identidad de AD que representa la cuenta de almacenamiento coincide con la de la clave kerb1 o kerb2 de la cuenta de almacenamiento. Si la contraseña es incorrecta, puede ejecutar Update-AzStorageAccountADObjectPassword para restablecer la contraseña.
2. CheckADObject: confirme que hay un objeto en Active Directory que representa la cuenta de almacenamiento y tiene el SPN correcto (nombre de entidad de servicio). Si SPN no se configura correctamente, ejecute el cmdlet Set-AD devuelto en el cmdlet debug para configurar SPN.
3. CheckDomainJoined: valide que la máquina cliente está unida a un dominio a AD. Si la máquina no está unida a un dominio a AD, consulte Unión de un equipo a un dominio para obtener instrucciones de unión a un dominio.
4. CheckPort445Connectivity: compruebe si el puerto 445 está abierto para la conexión SMB. Si el puerto 445 no está abierto, consulte la herramienta de solución de problemas AzFileDiagnostics para problemas de conectividad con Azure Files.
5. CheckSidHasAadUser: compruebe si el usuario de AD que ha iniciado sesión está sincronizado con el identificador de Microsoft Entra. Si desea buscar si un usuario específico de AD está sincronizado con el identificador de Entra de Microsoft, puede especificar y -UserName -Domain en los parámetros de entrada. Para un SID determinado, comprueba si hay un usuario de Microsoft Entra asociado.
6. CheckAadUserHasSid: compruebe si el usuario de AD que ha iniciado sesión está sincronizado con el identificador de Microsoft Entra. Si desea buscar si un usuario específico de AD está sincronizado con el identificador de Entra de Microsoft, puede especificar y -UserName -Domain en los parámetros de entrada. Para un usuario determinado de Microsoft Entra, comprueba su SID. Para ejecutar esta comprobación, debe proporcionar el -ObjectId parámetro , junto con el identificador de objeto del usuario de Microsoft Entra.
7. CheckGetKerberosTicket: intente obtener un vale de Kerberos para conectarse a la cuenta de almacenamiento. Si no hay un token kerberos válido, ejecute el klist get cifs/storage-account-name.file.core.windows.net cmdlet y examine el código de error para determinar la causa del error de recuperación de vales.
8. CheckStorageAccountDomainJoined: compruebe si la autenticación de AD se ha habilitado y las propiedades de AD de la cuenta se rellenan. Si no es así, habilite la autenticación de AD DS en Azure Files.
9. CheckUserRbacAssignment: compruebe si la identidad de AD tiene la asignación de roles de RBAC adecuada para proporcionar permisos de nivel de recurso compartido para acceder a Azure Files. Si no es así, configure el permiso de nivel de recurso compartido. (Se admite en la AzFilesHybrid v0.2.3 y versiones posteriores).
10. CheckUserFileAccess: compruebe si la identidad de AD tiene el permiso de directorio o archivo adecuado (ACL de Windows) para acceder a Azure Files. Si no es así, configure el permiso de nivel de directorio o archivo. Para ejecutar esta comprobación, debe proporcionar el -FilePath parámetro , junto con la ruta de acceso del archivo montado al que desea depurar el acceso. (Se admite en la AzFilesHybrid v0.2.3 y versiones posteriores).
11. CheckAadKerberosRegistryKeyIsOff: compruebe si la clave del Registro Kerberos de Microsoft Entra está desactivada. Si la clave está activada, ejecute reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 0 desde un símbolo del sistema con privilegios elevados para desactivarla y reinicie la máquina. (Compatible con AzFilesHybrid v0.2.9+ versión)

Si solo desea ejecutar una subselección de las comprobaciones anteriores, puede usar el -Filter parámetro , junto con una lista separada por comas de comprobaciones que se ejecutarán. Por ejemplo, para ejecutar todas las comprobaciones relacionadas con los permisos de nivel de recurso compartido (RBAC), use los siguientes cmdlets de PowerShell:

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Debug-AzStorageAccountAuth `
    -Filter CheckSidHasAadUser,CheckUserRbacAssignment `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -Verbose

Si tiene el recurso compartido de archivos montado en X:y si solo desea ejecutar la comprobación relacionada con los permisos de nivel de archivo (ACL de Windows), puede ejecutar los siguientes cmdlets de PowerShell:

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"
$FilePath = "X:\example.txt"

Debug-AzStorageAccountAuth `
    -Filter CheckUserFileAccess `
    -StorageAccountName $StorageAccountName `
    -ResourceGroupName $ResourceGroupName `
    -FilePath $FilePath `
    -Verbose

En primer lugar, asegúrese de que ha seguido los pasos para habilitar la autenticación Kerberos de Microsoft Entra.

En segundo lugar, puede ejecutar el Debug-AzStorageAccountAuth cmdlet para realizar un conjunto de comprobaciones básicas. Este cmdlet es compatible con las cuentas de almacenamiento configuradas para la autenticación Kerberos de Microsoft Entra, en la versión AzFilesHybrid v0.3.0+.

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Debug-AzStorageAccountAuth -StorageAccountName $StorageAccountName -ResourceGroupName $ResourceGroupName -Verbose

El cmdlet realiza estas comprobaciones de forma secuencial y proporciona instrucciones que seguir cuando aparezcan errores:

1. CheckPort445Connectivity: compruebe si el puerto 445 está abierto para la conexión SMB. Si el puerto 445 no está abierto, use la herramienta de solución de problemas AzFileDiagnostics para problemas de conectividad con Azure Files.
2. CheckAADConnectivity: compruebe la conectividad de Entra. Los montajes SMB con autenticación Kerberos pueden producir un error si el cliente no puede ponerse en contacto con Entra. Si se produce un error en esta comprobación, indica que hay un error de red (quizás un firewall o un problema de VPN).
3. CheckEntraObject: confirme que hay un objeto en entra que representa la cuenta de almacenamiento y tiene el nombre de entidad de seguridad de servicio (SPN) correcto. Si el SPN no está configurado correctamente, deshabilite y vuelva a habilitar la autenticación Kerberos entra en la cuenta de almacenamiento.
4. CheckRegKey: compruebe si la clave del CloudKerberosTicketRetrieval Registro está habilitada. Esta clave del Registro es necesaria para la autenticación Kerberos entra.
5. CheckRealmMap: compruebe si el usuario ha configurado las asignaciones de dominio que unirían la cuenta a otro dominio kerberos que KERBEROS.MICROSOFTONLINE.COM.
6. CheckAdminConsent: compruebe si se ha concedido el consentimiento del administrador a la entidad de servicio Entra para los permisos de Microsoft Graph necesarios para obtener un vale kerberos.
7. CheckWinHttpAutoProxySvc: comprueba el servicio de detección automática de proxy web WinHTTP (WinHttpAutoProxySvc) necesario para la autenticación Kerberos de Microsoft Entra. Su estado debe establecerse en Running.
8. CheckIpHlpScv: comprueba si el servicio auxiliar de IP (iphlpsvc) es necesario para la autenticación Kerberos de Microsoft Entra. Su estado debe establecerse en Running.

Si solo desea ejecutar una subselección de las comprobaciones anteriores, puede usar el -Filter parámetro , junto con una lista separada por comas de comprobaciones que se ejecutarán.

Puede experimentar alguno de los síntomas que se describen a continuación al intentar configurar las ACL de Windows con el Explorador de archivos en un recurso compartido de archivos montado:

• Después de hacer clic en Editar permiso en la pestaña Seguridad, el Asistente para permisos no se carga.
• Al intentar seleccionar un nuevo usuario o grupo, la ubicación del dominio no muestra el dominio de AD DS correcto.
• Está usando varios bosques de AD y recibe el siguiente mensaje de error: "Los controladores de dominio de Active Directory necesarios para encontrar los objetos seleccionados en los dominios siguientes no están disponibles. Asegúrese de que los controladores de dominio de Active Directory están disponibles e intente seleccionar los objetos de nuevo".

Se recomienda configurar permisos de nivel de directorio o archivo mediante icacls en lugar de usar el Explorador de archivos de Windows.

Este error puede producirse si un controlador de dominio que contiene el rol FSMO del maestro de RID no está disponible o si se quitó del dominio y se restauró a partir de una copia de seguridad. Confirme que todos los controladores de dominio están en ejecución y se encuentran disponibles.

Es más probable que este error se desencadene mediante un error de sintaxis en el Join-AzStorageAccountforAuth comando . Compruebe el comando si hay errores de ortográficos o sintaxis y compruebe que está instalada la versión más reciente del módulo AzFilesHybrid (https://github.com/Azure-Samples/azure-files-samples/releases).

Azure Files admite el cifrado Kerberos AES-256 para la autenticación de AD DS comenzando con el módulo AzFilesHybrid v0.2.2. AES-256 es el método de cifrado recomendado, y es el método de cifrado predeterminado a partir del módulo AzFilesHybrid v0.2.5. Si ha habilitado la autenticación de AD DS con una versión del módulo inferior a v0.2.2, deberá descargar el módulo AzFilesHybrid más reciente y ejecutar el cmdlet de PowerShell siguiente. Si aún no ha habilitado la autenticación AD DS en su cuenta de almacenamiento, siga esta guía.

$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"

Update-AzStorageAccountAuthForAES256 -ResourceGroupName $ResourceGroupName -StorageAccountName $StorageAccountName

Como parte de la actualización, el cmdlet rotará las claves Kerberos, lo que es necesario para cambiar a AES-256. No es necesario volver a girar a menos que quiera volver a generar ambas contraseñas.

Los roles Propietario y Colaborador de la cuenta de almacenamiento conceden la capacidad de enumerar las claves de la cuenta de almacenamiento. La clave de la cuenta de almacenamiento permite el acceso completo a los datos de la cuenta de almacenamiento, incluidos recursos compartidos de archivos, contenedores de blobs, tablas y colas, y acceso limitado a las operaciones de administración de Azure Files mediante las API de administración heredadas expuestas en la API FileREST. Si va a cambiar las asignaciones de roles, debe tener en cuenta que los usuarios que se quitan de los roles Propietario o Colaborador pueden seguir manteniendo el acceso a la cuenta de almacenamiento mediante las claves de la cuenta de almacenamiento guardadas.

Puede solucionar este problema fácilmente mediante la rotación de las claves de la cuenta de almacenamiento. Se recomienda rotar las claves de una en una y cambiar el acceso de una a la otra a medida que se rotan. Hay dos tipos de claves compartidas que proporciona la cuenta de almacenamiento: las claves de la cuenta de almacenamiento, que proporcionan acceso de superadministrador a los datos de la cuenta de almacenamiento, y las claves Kerberos, que funcionan como un secreto compartido entre la cuenta de almacenamiento y el controlador de dominio de Active Directory de Windows Server para escenarios de Windows Server Active Directory.

Para rotar las claves Kerberos de una cuenta de almacenamiento, consulte Actualizar la contraseña de la identidad de la cuenta de almacenamiento en AD DS.

Después de habilitar la autenticación Kerberos de Microsoft Entra, deberá conceder explícitamente el consentimiento del administrador a la nueva aplicación de Microsoft Entra registrada en el inquilino de Microsoft Entra para completar la configuración. Puede configurar los permisos de API desde Azure Portal mediante estos pasos.

1. Abra Microsoft Entra ID.
2. En el panel izquierdo, seleccione Registros de aplicaciones.
3. Select Todas las aplicaciones en el panel derecho.
4. Seleccione la aplicación con el nombre [Cuenta de almacenamiento] $storageAccountName.file.core.windows.net.
5. Seleccione Permisos de API en el panel izquierdo.
6. Seleccione Agregar permisos en la parte inferior de la página.
7. Seleccione Conceder consentimiento del administrador para "DirectoryName".

Es posible que encuentre los siguientes errores al habilitar la autenticación Kerberos de Microsoft Entra para las cuentas de usuario híbridas.

En algunos casos, el administrador de Microsoft Entra puede deshabilitar la capacidad de conceder consentimiento del administrador a las aplicaciones de Microsoft Entra. A continuación se muestra la captura de pantalla de cómo se vería en Azure Portal.

Si este es el caso, pida al administrador de Microsoft Entra que conceda el consentimiento del administrador a la nueva aplicación de Microsoft Entra. Para buscar y ver los administradores, seleccione roles y administradores y, a continuación, Administrador de aplicaciones en la nube.

Al habilitar la autenticación Kerberos de Microsoft Entra, podría producirse este error si se cumplen las condiciones siguientes:

1. Está usando la característica en vista previa o beta de las directivas de administración de aplicaciones.
2. Usted (o el administrador) han establecido una directiva para todo el inquilino que:
   • No tiene ninguna fecha de inicio o tiene una fecha de inicio antes del 1 de enero de 2019.
   • Establece una restricción en las contraseñas de la entidad de servicio, que no permite contraseñas personalizadas o establece una duración máxima de contraseña de menos de 365,5 días.

Actualmente no hay ninguna solución alternativa para este error.

También puede producirse este error si ha habilitado previamente la autenticación Kerberos de Microsoft Entra a través de los pasos manuales de versión preliminar limitada. Para eliminar la aplicación existente, el cliente o el administrador de TI pueden ejecutar el siguiente script. Cuando se ejecute este script, se quitará la aplicación antigua que se creó de manera manual y se permitirá que la nueva experiencia cree automáticamente y administre la aplicación recién creada. Después de iniciar la conexión a Microsoft Graph, inicie sesión en la aplicación Herramientas de línea de comandos de Microsoft Graph en el dispositivo y conceda permisos a la aplicación.

$storageAccount = "exampleStorageAccountName"
$tenantId = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"
Install-Module Microsoft.Graph
Import-Module Microsoft.Graph
Connect-MgGraph -TenantId $tenantId -Scopes "User.Read","Application.Read.All"

$application = Get-MgApplication -Filter "DisplayName eq '${storageAccount}'"
if ($null -ne $application) {
   Remove-MgApplication -ObjectId $application.ObjectId
}

Si ha habilitado previamente la autenticación Kerberos de Microsoft Entra a través de pasos de versión preliminar limitada manuales, la contraseña de la entidad de servicio de la cuenta de almacenamiento está establecida para expirar 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 mitigar esto, tiene dos opciones: rotar la contraseña de la entidad de servicio en Microsoft Entra cada seis meses o seguir estos pasos para deshabilitar Microsoft Entra Kerberos, eliminar la aplicación existente y volver a configurar Microsoft Entra Kerberos.

Asegúrese de guardar las propiedades de dominio (domainName y domainGUID) antes de deshabilitar Microsoft Entra Kerberos, ya que los necesitará durante la reconfiguración si desea configurar permisos de directorio y nivel de archivo mediante Windows Explorador de archivos. Si no guardó las propiedades de dominio, todavía puede configurar permisos de nivel de directorio o archivo mediante icacls como solución alternativa.

1. Deshabilitar Microsoft Entra Kerberos
2. Eliminación de la aplicación existente
3. Volver a configurar Microsoft Entra Kerberos a través de Azure Portal

Una vez que haya reconfigurado Microsoft Entra Kerberos, la nueva experiencia creará automáticamente y administrará la aplicación recién creada.

Si se conecta a una cuenta de almacenamiento a través de un punto de conexión privado o vínculo privado mediante la autenticación Kerberos de Microsoft Entra, al intentar montar un recurso compartido de archivos a través net use de u otro método, se solicita al cliente las credenciales. Es probable que el usuario escriba sus credenciales, pero las credenciales se rechazan.

Esto se debe a que el cliente SMB intentó usar Kerberos pero falló, por lo que recurre al uso de la autenticación NTLM, y Azure Files no admite el uso de la autenticación NTLM para las credenciales de dominio. El cliente no puede obtener un vale kerberos en la cuenta de almacenamiento porque el FQDN del vínculo privado no está registrado en ninguna aplicación de Microsoft Entra existente.

La solución consiste en agregar el FQDN privateLink a la aplicación Microsoft Entra de la cuenta de almacenamiento antes de montar el recurso compartido de archivos. Puede agregar el identifierUris requerido al objeto de la aplicación mediante Azure Portal siguiendo estos pasos.

1. Abra Microsoft Entra ID.

2. En el panel izquierdo, seleccione Registros de aplicaciones.

3. Seleccione Todas las aplicaciones.

4. Seleccione la aplicación con el nombre [Cuenta de almacenamiento] $storageAccountName.file.core.windows.net.

5. Seleccione Manifiesto en el panel izquierdo.

6. Copie y pegue el contenido existente para tener una copia duplicada.

7. Edite el manifiesto JSON. Para cada <storageAccount>.file.core.windows.net entrada, agregue una entrada correspondiente <storageAccount>.privatelink.file.core.windows.net . Por ejemplo, si el manifiesto tiene el siguiente valor para identifierUris:

   JSON

   "identifierUris": [
       "api://<tenantId>/HOST/<storageaccount>.file.core.windows.net",
       "api://<tenantId>/CIFS/<storageaccount>.file.core.windows.net",
       "api://<tenantId>/HTTP/<storageaccount>.file.core.windows.net",
       "HOST/<storageaccount>.file.core.windows.net",
       "CIFS/<storageaccount>.file.core.windows.net",
       "HTTP/<storageaccount>.file.core.windows.net"
   ],
   

   A continuación, debe editar el identifierUris campo en lo siguiente:

   JSON

   "identifierUris": [
       "api://<tenantId>/HOST/<storageaccount>.file.core.windows.net",
       "api://<tenantId>/CIFS/<storageaccount>.file.core.windows.net",
       "api://<tenantId>/HTTP/<storageaccount>.file.core.windows.net",
       "HOST/<storageaccount>.file.core.windows.net",
       "CIFS/<storageaccount>.file.core.windows.net",
       "HTTP/<storageaccount>.file.core.windows.net",
   
       "api://<tenantId>/HOST/<storageaccount>.privatelink.file.core.windows.net",
       "api://<tenantId>/CIFS/<storageaccount>.privatelink.file.core.windows.net",
       "api://<tenantId>/HTTP/<storageaccount>.privatelink.file.core.windows.net",
       "HOST/<storageaccount>.privatelink.file.core.windows.net",
       "CIFS/<storageaccount>.privatelink.file.core.windows.net",
       "HTTP/<storageaccount>.privatelink.file.core.windows.net"
   ],
   

8. Revise el contenido y seleccione Guardar para actualizar el objeto de aplicación con el identifierUris nuevo.

9. Actualice las referencias DNS internas para que apunten al vínculo privado.

10. Vuelva a intentar montar el recurso compartido.

La solicitud se interrumpió con el siguiente error AADSTS50105:

El administrador ha configurado la aplicación "Nombre de aplicación empresarial" para bloquear a los usuarios a menos que se les conceda acceso (asignado) específicamente a la aplicación. El usuario que ha iniciado sesión '{EmailHidden}' está bloqueado porque no es miembro directo de un grupo con acceso ni tiene acceso asignado directamente por un administrador. Póngase en contacto con el administrador para asignar acceso a esta aplicación.

Si configura la "asignación necesaria" para la aplicación empresarial correspondiente, no podrá obtener un vale kerberos y los registros de inicio de sesión de Microsoft Entra mostrarán un error aunque los usuarios o grupos estén asignados a la aplicación.

No seleccione Asignación necesaria para la aplicación Microsoft Entra para la cuenta de almacenamiento porque no rellenamos los derechos en el vale kerberos que se devuelve al solicitante. Para obtener más información, vea Error AADSTS50105: el usuario que ha iniciado sesión no está asignado a un rol para la aplicación.