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

  • Artículo

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

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

Error al ejecutar el módulo AzFilesHybrid

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

El cliente no tiene un privilegio necesario.

Causa: los permisos de AD son insuficientes

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

Solución

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

Error 5 al montar un recurso compartido de archivos de Azure

Al intentar montar un recurso compartido de archivos, es posible que reciba el siguiente error:

Error del sistema 5. Acceso denegado.

Causa: Los permisos de nivel de recurso compartido son incorrectos

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

Nota:

Este error puede deberse a problemas distintos de permisos incorrectos de nivel de recurso compartido. Para obtener información sobre otras posibles causas y soluciones, consulte Solución de problemas de conectividad y acceso Azure Files.

Solución

Valide que los permisos están configurados correctamente:

  • Servicios de dominio de Active Directory (AD DS) consulte Asignación de permisos de nivel de recurso compartido.

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

  • Servicios de dominio de Microsoft Entra consulte Asignación de permisos de nivel de recurso compartido.

Error de AadDsTenantNotFound al habilitar la autenticación de Servicios de dominio de Microsoft Entra para Azure Files "No se pueden encontrar inquilinos activos con el identificador de inquilino Microsoft Entra tenant-id"

Causa

Error AadDsTenantNotFound al intentar habilitar la autenticación de Servicios de dominio de Microsoft Entra para Azure Files en una cuenta de almacenamiento donde no se crea Servicios de dominio de Microsoft Entra en el Microsoft Entra inquilino de la suscripción asociada.

Solución

Habilite Servicios de dominio de Microsoft Entra en el inquilino 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 Servicios de dominio de Microsoft Entra.

No se pueden montar recursos compartidos de archivos de Azure con credenciales de AD

Pasos de autodiagnóstico

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

En segundo lugar, intente montar el recurso compartido de archivos de Azure con la clave de cuenta de almacenamiento. Si el recurso compartido no se puede montar, descargue AzFileDiagnostics para ayudarle a validar el entorno de ejecución del cliente. AzFileDiagnostics puede detectar configuraciones de cliente incompatibles que podrían provocar un error de acceso para Azure Files, proporcionar instrucciones prescriptivas sobre 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 ha iniciado sesión. Este cmdlet se admite en la versión posterior de AzFilesHybrid v0.1.2+. Debe ejecutar este cmdlet con un usuario de AD que tenga permiso 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 en secuencia y proporciona instrucciones para los 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 el SPN no está configurado correctamente, ejecute el Set-AD cmdlet devuelto en el cmdlet de depuración para configurar el SPN.
  3. CheckDomainJoined: valide que la máquina cliente está unida a un dominio a AD. Si el equipo no está unido a un dominio a AD, consulte Unión de un equipo a un dominio para obtener instrucciones sobre la unión a un dominio.
  4. CheckPort445Connectivity: compruebe que 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 ver los problemas de conectividad con Azure Files.
  5. CheckSidHasAadUser: compruebe que el usuario de AD que ha iniciado sesión esté sincronizado con Microsoft Entra ID. Si desea buscar si un usuario de AD específico está sincronizado con Microsoft Entra ID, puede especificar y -UserName-Domain en los parámetros de entrada. Para un SID determinado, comprueba si hay un usuario Microsoft Entra asociado.
  6. CheckAadUserHasSid: compruebe que el usuario de AD que ha iniciado sesión esté sincronizado con Microsoft Entra ID. Si desea buscar si un usuario de AD específico está sincronizado con Microsoft Entra ID, puede especificar y -UserName-Domain en los parámetros de entrada. Para un usuario Microsoft Entra determinado, comprueba su SID. Para ejecutar esta comprobación, debe proporcionar el -ObjectId parámetro junto con el identificador de objeto del usuario 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 se ha habilitado la autenticación de AD y se rellenan las propiedades de AD de la cuenta. 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 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. (Compatible con AzFilesHybrid v0.2.3 o versiones posteriores)
  10. CheckUserFileAccess: compruebe si la identidad de AD tiene el permiso de directorio o archivo (ACL de Windows) adecuado 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. (Compatible con AzFilesHybrid v0.2.3 o 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, a continuación, reinicie el equipo. (Compatible con AzFilesHybrid v0.2.9 y versiones posteriores)

Si solo quiere 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 van a ejecutar. 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 solo quiere 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

No se pueden configurar permisos de nivel de directorio o archivo (ACL de Windows) con Windows Explorador de archivos

Síntoma

Puede experimentar uno de los síntomas que se describen a continuación al intentar configurar las ACL de Windows con 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.
  • Usa varios bosques de AD y recibe el siguiente mensaje de error: "Los controladores de dominio de Active Directory necesarios para buscar los objetos seleccionados en los siguientes dominios no están disponibles. Asegúrese de que los controladores de dominio de Active Directory están disponibles e intente volver a seleccionar los objetos."

Solución

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

Errores al ejecutar Join-AzStorageAccountForAuth cmdlet

Error: "El servicio de directorio no pudo asignar un identificador relativo"

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

Error: "No se pueden enlazar parámetros posicionales porque no se han dado nombres"

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

Azure Files compatibilidad local con la autenticación de AD DS para el cifrado Kerberos AES-256

Azure Files admite el cifrado Kerberos AES-256 para la autenticación de AD DS a partir del módulo AzFilesHybrid v0.2.2. AES-256 es el método de cifrado recomendado y es el método de cifrado predeterminado que comienza en el módulo AzFilesHybrid v0.2.5. Si ha habilitado la autenticación de AD DS con una versión de módulo inferior a v0.2.2, tendrá que descargar el módulo AzFilesHybrid más reciente y ejecutar powerShell a continuación. Si aún no ha habilitado la autenticación de AD DS en la cuenta de almacenamiento, siga estas instrucciones.

Importante

Si anteriormente usaba el cifrado RC4 y actualizaba la cuenta de almacenamiento para usar AES-256, debería ejecutar klist purge en el cliente y, a continuación, volver a montar el recurso compartido de archivos para obtener nuevos vales de Kerberos con AES-256.

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

Update-AzStorageAccountAuthForAES256 -ResourceGroupName $ResourceGroupName -StorageAccountName $StorageAccountName

Como parte de la actualización, el cmdlet girará 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.

La identidad de usuario que anteriormente tenía la asignación de roles Propietario o Colaborador sigue teniendo acceso a la clave de la cuenta de almacenamiento

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 cuenta de almacenamiento permite el acceso total a los datos de la cuenta de almacenamiento, incluidos los recursos compartidos de archivos, los contenedores de blobs, las tablas y las colas, y el acceso limitado a las operaciones de administración de Azure Files a través de las API de administración heredadas expuestas a través de 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 a través de claves de cuenta de almacenamiento guardadas.

Solución 1

Puede solucionar este problema fácilmente girando las claves de la cuenta de almacenamiento. Se recomienda girar las claves de una en una, cambiando el acceso de una a otra a medida que se giran. Hay dos tipos de claves compartidas que proporciona la cuenta de almacenamiento: las claves de 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 Windows Server Active Directory para Windows Server Active Directory Escenarios.

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

Vaya a la cuenta de almacenamiento deseada en el Azure Portal. En la tabla de contenido de la cuenta de almacenamiento deseada, seleccione Claves de acceso en el encabezado Seguridad y redes . En el panel Clave de acceso , seleccione Girar clave encima de la clave deseada.

Captura de pantalla que muestra el panel

Establecer los permisos de API en una aplicación recién creada

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

  1. Abra Microsoft Entra ID.
  2. Seleccione Registros de aplicaciones en el panel izquierdo.
  3. Seleccione Todas las aplicaciones en el panel derecho.
  4. Seleccione la aplicación con el nombre coincidente [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 de administrador para "DirectoryName".

Posibles errores al habilitar Microsoft Entra autenticación Kerberos para usuarios híbridos

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

Error: concesión del consentimiento del administrador deshabilitado

En algunos casos, Microsoft Entra administrador puede deshabilitar la capacidad de conceder consentimiento al administrador para Microsoft Entra aplicaciones. A continuación se muestra la captura de pantalla del aspecto que puede tener en la Azure Portal.

Captura de pantalla que muestra la hoja

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, seleccione Administrador de aplicaciones en la nube.

Error: "Error en la solicitud a Azure AD Graph con el código BadRequest"

Causa 1: Una directiva de administración de aplicaciones impide que se creen credenciales

Al habilitar Microsoft Entra autenticación Kerberos, es posible que se produzca este error si se cumplen las condiciones siguientes:

  1. Usa la característica beta/preview de las directivas de administración de aplicaciones.
  2. Usted (o el administrador) ha 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 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.

Causa 2: Ya existe una aplicación para la cuenta de almacenamiento

También puede encontrar este error si previamente ha habilitado Microsoft Entra autenticación Kerberos mediante pasos de versión preliminar limitada manuales. Para eliminar la aplicación existente, el cliente o su administrador de TI pueden ejecutar el siguiente script. Al ejecutar este script, se quitará la antigua aplicación creada manualmente y se permitirá que la nueva experiencia cree y administre automáticamente 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
}

Error: la contraseña de la entidad de servicio ha expirado en Microsoft Entra ID

Si previamente ha habilitado Microsoft Entra autenticación Kerberos mediante pasos de versión preliminar limitada manuales, la contraseña de la entidad de servicio de la cuenta de almacenamiento 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 las necesitará durante la reconfiguración si desea configurar permisos de directorio y de nivel de archivo mediante Windows Explorador de archivos. Si no guardó las propiedades de dominio, puede configurar los 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. Vuelva a configurar Microsoft Entra Kerberos mediante el Azure Portal

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

Error 1326: el nombre de usuario o la contraseña son incorrectos al usar private link

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

Causa

Esto se debe a que el cliente SMB ha intentado usar Kerberos pero ha producido un error, por lo que vuelve a usar 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 de Kerberos para la cuenta de almacenamiento porque el FQDN del vínculo privado no está registrado en ninguna aplicación Microsoft Entra existente.

Solución

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 identificador necesarioUris al objeto de aplicación mediante el Azure Portal siguiendo estos pasos.

  1. Abra Microsoft Entra ID.

  2. Seleccione Registros de aplicaciones en el panel izquierdo.

  3. Seleccione Todas las aplicaciones.

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

  5. Seleccione Manifiesto en el panel izquierdo.

  6. Copie y pegue el contenido existente para que tenga 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:

    "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 para lo siguiente:

    "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 nuevo identificadorUris.

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

  10. Vuelva a intentar montar el recurso compartido.

Error AADSTS50105

La solicitud se interrumpió por 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 específicamente acceso (asignado) a la aplicación. El usuario que ha iniciado sesión '{EmailHidden}' está bloqueado porque no es un 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.

Causa

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

Solución

No seleccione Asignación necesaria para Microsoft Entra aplicación 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.

Vea también

Ponte en contacto con nosotros para obtener ayuda

Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.