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

Applies to: ✔️ recursos de compartición de archivos SMB de Azure

Resumen

En este artículo se enumeran los problemas comunes al usar la autenticación basada en identidades con recursos compartidos de archivos de Azure SMB y se proporcionan posibles causas y resoluciones. Use esta guía para diagnosticar y corregir errores de autenticación, problemas de permisos y problemas de configuración de Kerberos.

Error al ejecutar el módulo AzFilesHybrid

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

El cliente no dispone de un privilegio requerido.

Causa: Los permisos de AD no son suficientes

Este problema se produce porque no tiene los permisos necesarios 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 Azure

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

Error de 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 la autenticación basada en identidades, el acceso al recurso compartido de archivos produce un error "Acceso denegado" si los permisos de nivel de recurso compartido son incorrectos.

Nota:

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

Solución

Valide que los permisos están configurados correctamente. Consulte Asignar permisos a nivel de recurso compartido.

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

Causa

El error AadDsTenantNotFound se produce al intentar habilitar la autenticación de Microsoft Entra Domain Services para Azure Files en una cuenta de almacenamiento en la que no se han creado los servicios de dominio de Microsoft Entra en el inquilino de Microsoft Entra de la suscripción asociada.

Solución

Habilite Microsoft Entra Domain Services 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 de Microsoft Entra Domain Services.

Error: todos los URI recién agregados deben contener un dominio comprobado por el inquilino, un identificador de inquilino o un identificador de aplicación.

Causa

Este error se produce durante la configuración de la autenticación basada en identidades para Azure Files cuando se agrega un URI de redirección o URI de identificador que no cumple los requisitos de seguridad de la aplicación de Microsoft Entra ID.

Microsoft Entra ID aplica restricciones en los URI de identificador de aplicación y los URI de redirección. Los URI recién agregados deben hacer referencia a uno de los siguientes valores:

  • Un dominio personalizado comprobado por el inquilino
  • Identificador de inquilino de Microsoft Entra
  • Identificador de la aplicación (cliente)

Si un URI usa un dominio no comprobado, un .local nombre de host o una dirección URL arbitraria que no está asociada al inquilino, la directiva de inquilino predeterminada bloquea la solicitud.

Microsoft Entra ID aplica este comportamiento y no es específico del servicio Azure Files.

Para obtener más información, consulte:

Solución

Al configurar el registro de aplicaciones o la autenticación basada en identidades para Azure Files, asegúrese de que cualquier URI de redirección o URI de identificador usa uno de los formatos admitidos:

  • Uso de un dominio personalizado comprobado por el inquilino
  • Uso del identificador de inquilino de Microsoft Entra
  • Uso del identificador de aplicación (cliente)

No use dominios no comprobados, .local nombres de host ni direcciones URL arbitrarias, ya que la directiva de inquilinato de Microsoft Entra ID rechaza estos valores. Si no está seguro de qué dominios se comprueban en el inquilino, revise la sección Nombres de dominio personalizados en el Centro de administración de Microsoft Entra o póngase en contacto con el administrador de inquilinos.

No se pueden montar comparticiones de archivos de Azure con credenciales de AD

Pasos de autodiagnóstico

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

En segundo lugar, pruebe montar la compartición 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 podrían provocar errores de acceso para Azure Files, proporcionar instrucciones prescriptivas sobre la corrección automática y recopilar los seguimientos de diagnóstico.

En tercer lugar, ejecute 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 AzFilesHybrid v0.1.2+.

  1. Inicie sesión en Azure PowerShell interactivamente como un usuario de AD que tenga permiso de propietario en la cuenta de almacenamiento de destino:

    Connect-AzAccount

  2. Ejecute el Debug-AzStorageAccountAuth cmdlet :

    $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 clave kerb1 o kerb2 de la cuenta de almacenamiento. Si la contraseña es incorrecta, ejecute Update-AzStorageAccountADObjectPassword para restablecer la contraseña.
  2. CheckADObject: confirme que hay un objeto en el Active Directory que representa la cuenta de almacenamiento y tiene el SPN correcto (nombre de entidad de servicio). Si el SPN no se configura correctamente, ejecute el cmdlet Set-AD devuelto en el cmdlet de depuración para configurar el SPN.
  3. CheckDomainJoined: Verifique que la máquina cliente esté unida a un dominio de AD. Si su máquina no está unida a un dominio de AD, consulte Unir 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 ver los problemas de conectividad con Azure Files.
  5. CheckSidHasAadUser: compruebe si el usuario de AD que ha iniciado sesión está sincronizado con Microsoft Entra ID. Para buscar si un usuario específico de AD está sincronizado con Microsoft Entra ID, especifique el -UserName y -Domain en los parámetros de entrada. Para un SID determinado, comprueba si hay un usuario Microsoft Entra ID asociado.
  6. CheckAadUserHasSid: compruebe si el usuario de AD que ha iniciado sesión está sincronizado con Microsoft Entra ID. Para buscar si un usuario específico de AD está sincronizado con Microsoft Entra ID, especifique el -UserName y -Domain en los parámetros de entrada. Para un usuario de Microsoft Entra ID determinado, comprueba su SID. Para ejecutar esta comprobación, proporcione el parámetro -ObjectId, junto con el identificador de objeto del usuario de Microsoft Entra ID.
  7. CheckGetKerberosTicket: intente obtener un vale de Kerberos para conectarse a la cuenta de almacenamiento. Si no hay ningún token de Kerberos válido, ejecute el cmdlet klist get cifs/storage-account-name.file.core.windows.net y examine el código de error para determinar la causa del error al recuperar el vale.
  8. CheckStorageAccountDomainJoined: Compruebe si la autenticación de AD está habilitada y las propiedades de AD de la cuenta están rellenadas. Si no es así, enable 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 compartición. (Compatible con AzFilesHybrid v0.2.3+)
  10. CheckUserFileAccess: compruebe si la identidad de AD tiene el permiso de directorio o archivo adecuado (Windows ACL) para acceder a Azure Files. Si no es así, configure el permiso de nivel de directorio o archivo. Para ejecutar esta comprobación, proporcione 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+)
  11. CheckKerberosTicketEncryption: compruebe si la cuenta de almacenamiento está configurada para aceptar el tipo de cifrado usado por el vale kerberos. (Compatible con AzFilesHybrid v0.2.5+)
  12. CheckChannelEncryption: compruebe si la cuenta de almacenamiento está configurada para aceptar el tipo de cifrado de canal SMB usado por el cliente. (Compatible con AzFilesHybrid v0.2.5+)
  13. CheckDomainLineOfSight: compruebe si el cliente tiene conectividad de red no impedida al controlador de dominio. (Compatible con AzFilesHybrid v0.2.5+)
  14. CheckDefaultSharePermission: compruebe si el permiso de nivel de recurso compartido predeterminado está configurado. (Compatible con AzFilesHybrid v0.2.5+)
  15. 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 luego reinicie su equipo. (Compatible con AzFilesHybrid v0.2.9+)

Si desea ejecutar una subselección de las comprobaciones anteriores, use 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 a nivel de archivo (ACL de Windows), ejecute 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 montar comparticiones de archivos de Azure con Microsoft Entra Kerberos

Pasos de autodiagnóstico

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

En segundo lugar, ejecute el Debug-AzStorageAccountAuth cmdlet para realizar un conjunto de comprobaciones básicas. Este cmdlet admite cuentas de almacenamiento configuradas para la autenticación Kerberos de Microsoft Entra, a partir de AzFilesHybrid v0.3.0+.

  1. Inicie sesión en Azure PowerShell interactivamente como un usuario de AD que tenga permiso de propietario en la cuenta de almacenamiento de destino:

    Connect-AzAccount

  2. Ejecute el Debug-AzStorageAccountAuth cmdlet :

    $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: comprueba 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: comprueba 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: confirma que hay un objeto en Entra que representa la cuenta de almacenamiento y que 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 de Entra Kerberos en la cuenta de almacenamiento.
  4. CheckRegKey: comprueba si la clave del CloudKerberosTicketRetrieval Registro está habilitada. Esta clave del Registro es necesaria para la autenticación Kerberos de Entra.
  5. CheckRealmMap: Comprueba si el usuario ha configurado alguna asignación de reinos que vincule la cuenta a otro reino Kerberos distinto de KERBEROS.MICROSOFTONLINE.COM.
  6. CheckAdminConsent: Comprueba si a la entidad de servicio de Entra se le ha concedido consentimiento de administrador para los permisos de Microsoft Graph necesarios para obtener un vale de 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. Por motivos de seguridad, puede deshabilitar opcionalmente la detección automática de proxy web (WPAD) mediante claves del Registro. Sin embargo, no deshabilite todo el servicio WinHttpAutoProxySvc, ya que se encarga de muchas otras funciones, incluidas las solicitudes del proxy del Centro de distribución de claves Kerberos (KDC Proxy).
  8. CheckIpHlpScv: Comprueba el servicio auxiliar de IP (iphlpsvc), necesario para la autenticación Kerberos de Microsoft Entra. Su estado debe establecerse en Running.
  9. CheckFiddlerProxy: Comprueba si existe un proxy de Fiddler que impide la autenticación Kerberos de Microsoft Entra.
  10. CheckEntraJoinType: comprueba si la máquina está unida a un dominio Entra o a un dominio híbrido de Entra. Es un requisito previo para la autenticación Kerberos de Microsoft Entra.

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

Se produce un error en el montaje en Azure Files cuando se usa Entra Kerberos debido a tipos de cifrado Kerberos no admitidos

Al montar un recurso compartido de archivos de Azure mediante la autenticación Kerberos de Microsoft Entra, la operación de montaje falla. La recopilación de registros puede indicar que no se puede descifrar el ticket de servicio Kerberos. También puede encontrar que la siguiente clave del Registro está configurada: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\SupportedEncryptionTypes

Causa

Si configura la clave del Registro SupportedEncryptionTypes con un valor que no incluye AES, Windows solo permite los tipos de cifrado especificados en la máscara de bits. Por ejemplo, el valor 0x7 indica que el cliente solo admite los siguientes tipos de cifrado Kerberos:

  • DES_CBC_CRC
  • DES_CBC_MD5
  • RC4_HMAC

Dado que Microsoft Entra Kerberos siempre cifra los tickets de servicio con AES-256 (AES256-CTS-HMAC-SHA1-96), los montajes fallan si AES no está incluido entre los tipos de cifrado admitidos para la cuenta o la máquina.

Nota:

El cifrado AES está habilitado de forma predeterminada en los sistemas operativos Windows modernos. Si no se configura la clave de registro SupportedEncryptionTypes, Windows negocia automáticamente AES si está disponible.

Solución

Para montar correctamente los recursos compartidos de archivos de Azure con Microsoft Entra Kerberos, incluya AES-256 entre los tipos de cifrado admitidos.

Use una de las siguientes opciones:

Si no ha restringido deliberadamente los tipos de cifrado:

  1. Elimine la clave del Registro: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\SupportedEncryptionTypes
  2. Reinicie el equipo.

Después del reinicio, vuelva a intentar montar el recurso compartido de archivos.

Sugerencia

Al eliminar la clave, se restaura el comportamiento predeterminado de Windows, lo que permite a Active Directory negociar automáticamente AES para los tickets de Kerberos.

Opción 2: Habilitar explícitamente AES-256 mediante la directiva de grupo

Si su organización requiere tipos de cifrado Kerberos configurados explícitamente:

  1. Presione Win + R, escriba gpedit.mscy seleccione Entrar.
  2. Vaya a: Directivas de equipo local > Configuración del equipo > Windows Settings > Security Settings > Local Policies > Security Options
  3. Open Network Security: configure los tipos de cifrado permitidos para Kerberos.
  4. Habilite los siguientes tipos de cifrado:
    • AES256_HMAC_SHA1
    • AES128_HMAC_SHA1 (opcional)
  5. Aplique el cambio y reinicie el equipo.

Después del reinicio, vuelva a intentar montar el recurso compartido de archivos.

Importante

Entra Kerberos requiere AES256_HMAC_SHA1 para montar correctamente recursos compartidos de archivos Azure. Se produce un error en las configuraciones de solo RC4 o DES. Para más información sobre las claves del Registro, consulte Descifrado de la selección de tipos de cifrado Kerberos admitidos.

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

Síntoma

Es posible que experimente uno de los siguientes síntomas al intentar configurar Windows ACL mediante 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 Active Directory Domain Services correcto (AD DS).
  • 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".

Solución

En lugar de usar el Explorador de archivos, configure los permisos de nivel de directorio o archivo mediante icacls.

No se puede ver UserPrincipalName (UPN) de un archivo o propietario de directorio en el Explorador de archivos

Síntoma

El Explorador de archivos muestra el identificador de seguridad (SID) de un propietario de archivo o directorio, pero no el UPN.

Causa

El Explorador de archivos llama a una API RPC directamente al servidor (Azure Files) para traducir el SID a un UPN. Azure Files no admite esta API, por lo que no se muestra el UPN.

Solución

En un cliente unido a un dominio, use el siguiente comando de PowerShell para ver todos los elementos de un directorio y su propietario, incluido el UPN:

Get-ChildItem <Path> | Get-ACL | Select Path, Owner

Errores al ejecutar el cmdlet Join-AzStorageAccountForAuth

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

Este error se produce si un controlador de dominio que ostenta el rol FSMO de maestro RID no está disponible o se eliminó 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 disponibles.

Error: "No se pueden enlazar los parámetros de posición porque no se proporcionaron nombres".

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 ortográficos o de sintaxis y compruebe que está instalada la versión más reciente del módulo AzFilesHybrid .

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 de Propietario y Colaborador de la cuenta de almacenamiento otorgan 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, incluidas las comparticiones de archivos, blobs, tablas y colas. También proporciona 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, tenga en cuenta que los usuarios que va a quitar de los roles Propietario o Colaborador pueden seguir teniendo 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 mediante la rotación de las claves de la cuenta de almacenamiento. Gire las claves una a la vez, cambiando el acceso de uno a otro a medida que los gira. La cuenta de almacenamiento proporciona dos tipos de claves compartidas: 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 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 portal de Azure. 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 Rotar clave para la clave deseada.

Captura de pantalla que muestra el panel Clave de acceso.

Configure los permisos de la API en la aplicación recién creada

Después de habilitar Microsoft Entra autenticación Kerberos, debe 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 el portal Azure 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 que coincida con [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".

Posibles errores al habilitar la autenticación Kerberos de Microsoft Entra

Es posible que encuentre los siguientes errores al habilitar la autenticación Kerberos de Microsoft Entra.

Error: Concesión de consentimiento de administrador deshabilitada

En algunos casos, el administrador de Microsoft Entra puede deshabilitar la capacidad de otorgar consentimiento del administrador en las aplicaciones de Microsoft Entra. A continuación se muestra una captura de pantalla del aspecto que se muestra en el portal de Azure.

Captura de pantalla que muestra el panel Permisos configurados con una advertencia de que algunas acciones podrían estar deshabilitadas debido a sus permisos.

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

Error: "La solicitud a Microsoft Graph falló con el código BadRequest"

Causa 1: Una directiva de administración de aplicaciones impide la creación de credenciales

Al habilitar la autenticación Kerberos de Microsoft Entra, es posible que se produzca este error si usted (o su administrador) establece una directiva para todo el inquilino o una directiva de administración de aplicaciones que:

  • Se aplica a la aplicación empresarial "Proveedor de recursos de almacenamiento" (ID de la aplicación a6aa9161-5291-40bb-8c5c-923b567bee3b).
  • Establece una restricción en las contraseñas del principal del servicio, que bloquea la adición de contraseñas o restringe su duración máxima a menos de 365,5 días.

Para resolver este error, configure la directiva causante para conceder una excepción a la aplicación empresarial "Proveedor de recursos de almacenamiento" (identificador de aplicación a6aa9161-5291-40bb-8c5c-923b567bee3b).

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

También puede producirse este error si habilitó anteriormente la autenticación Kerberos de Microsoft Entra mediante pasos manuales durante la vista previa limitada. Para eliminar la aplicación existente, el cliente o el administrador de TI pueden ejecutar el siguiente script. La ejecución de este script quita la aplicación creada manualmente antigua y permite 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
}

Error: la contraseña de la entidad de servicio expiró en Microsoft Entra ID

Si habilitó previamente la autenticación Kerberos de Microsoft Entra siguiendo manualmente los pasos de la versión preliminar limitada, la contraseña de la entidad de servicio de la cuenta de almacenamiento caduca cada seis meses. Una vez que expire la contraseña, los usuarios no podrán obtener vales de Kerberos para acceder al recurso compartido de archivos.

Para solucionar este problema, puede rotar la contraseña de la entidad de servicio en Microsoft Entra ID 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 del dominio (domainName y domainGUID) antes de deshabilitar Microsoft Entra Kerberos, ya que los necesite durante la reconfiguración si desea configurar permisos de directorio y de nivel de archivo mediante Windows Explorador de archivos. Si no guardó 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. Reconfigure Microsoft Entra Kerberos a través del portal de Azure

Al volver a configurar Microsoft Entra Kerberos, la nueva experiencia crea y administra automáticamente la aplicación recién creada.

Error 1326: el nombre de usuario o la contraseña son incorrectos al usar un enlace privado

Si se conecta a una cuenta de almacenamiento a través de un punto de conexión privado mediante la autenticación Kerberos de Microsoft Entra, cuando intente montar un recurso compartido de archivos mediante net use u otro método, el cliente le pedirá unas credenciales. Si introduce sus credenciales, se rechazan sus credenciales.

Causa

Este error se produce porque el cliente SMB intenta usar Kerberos pero se produce un error, por lo que recurre al uso de la autenticación NTLM. Azure Files no admite el uso de la autenticación NTLM para las credenciales de dominio. El cliente no puede obtener un ticket de Kerberos para la cuenta de almacenamiento porque el FQDN del enlace privado no está registrado en ninguna aplicación de Entra existente.

Solución

Agregue el FQDN de privateLink a la aplicación Entra de la cuenta de almacenamiento antes de montar el recurso compartido de archivos. Puede agregar los identifierUris necesarios al objeto Application mediante el portal de Azure y 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 que coincida con [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:

    "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, edite el identifierUris campo en 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 los nuevos identificadoresUris.

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

  10. Vuelva a intentar montar el recurso compartido.

Errores de autenticación intermitentes después de los cambios de red al usar Microsoft Entra Kerberos

Síntoma

Clientes de Windows que usan la autenticación Kerberos de Microsoft Entra para acceder a Azure Files pierden acceso de forma intermitente después de un cambio de red (por ejemplo, reconexión de VPN, cambio de Wi-Fi, suspensión o reanudación). Es posible que se produzca un error en el acceso hasta que el usuario cierre la sesión y vuelva a iniciar sesión en Windows.

Causa

Este problema se produce debido a un comportamiento conocido de Windows. Algunos cambios de red borran la configuración de proxy KDC almacenada en caché en el cliente. Cuando se elimina la configuración del proxy KDC, el cliente no puede renovar los tickets de servicio de Kerberos desde Microsoft Entra ID.

Aunque el token de actualización principal (PRT) del usuario permanece válido, la configuración del proxy KDC que falta impide que el cliente obtenga una nueva incidencia de servicio, por lo que se produce un error en la autenticación.

Esta limitación está en el cliente de Windows. Azure Files o Microsoft Entra ID configuración no causa este problema.

Solución

Opción uno: cerrar sesión y volver a iniciar sesión en Windows restaura el acceso al obtener un PRT nuevo, que incluye una configuración actualizada de Ticket de Concesión de Tiquete (TGT) y proxy KDC. Sin embargo, este proceso da como resultado una experiencia de usuario deficiente.

Opción dos: configure una configuración de directiva de grupo para conservar la configuración del proxy KDC en el cliente, lo que reduce las interrupciones de autenticación causadas por los cambios de red.

  1. Configure las opciones de proxy de KDC mediante la directiva de grupo.

  2. Abra Administración de directivas de grupo y edite la directiva aplicable.

  3. Vaya a Plantillas administrativas>Sistema>Kerberos>Especificar servidores proxy de KDC para clientes Kerberos.

  4. Seleccione Habilitado.

  5. En Opciones, seleccione Mostrar para abrir el cuadro de diálogo Mostrar contenido.

  6. Agregue la siguiente asignación, reemplazando Microsoft_Entra_tenant_id por el identificador de inquilino de Microsoft Entra. Incluya el espacio después de https y antes del cierre /.

    Nombre del valor Importancia
    KERBEROS.MICROSOFTONLINE.COM <https login.microsoftonline.com:443:your_Microsoft_Entra_tenant_id/kerberos/>

  7. Seleccione Aceptar y, a continuación, seleccione Aplicar.

Después de aplicar esta directiva, los clientes de Windows conservan la configuración del proxy KDC durante los cambios de red, lo que reduce las interrupciones de autenticación.

La autenticación se detiene después de aproximadamente 10 horas cuando se usa Microsoft Entra Kerberos

Síntoma

Clientes de Windows que usan la autenticación Kerberos de Microsoft Entra para acceder a Azure Files pierden el acceso después de aproximadamente 10 horas de uso continuo. El acceso solo se restaura después de que el usuario cierre la sesión y vuelva a iniciar sesión en Windows.

Causa

Este problema se debe a una limitación conocida en la autenticación Kerberos de Microsoft Entra. Microsoft Entra ID no admite actualmente la renovación de tickets de concesión de tickets (TGT).

En los escenarios de Kerberos de Microsoft Entra, el usuario recibe el TGT como parte de su token de actualización principal (PRT). Dado que no se admite la renovación de TGT, el cliente no puede actualizar el TGT después de que expire. Cuando el TGT expira, el cliente no puede obtener nuevos vales de servicio, lo que provoca errores de autenticación.

Al cerrar sesión y volver a iniciar sesión en Windows se corrige el problema al obtener un PRT nuevo, que incluye un nuevo TGT. Se trata de una limitación conocida de Microsoft Entra Kerberos y no se debe a Azure Files configuración.

Solución

Como mitigación, configure una confianza en la nube entre Active Directory Domain Services locales (AD DS) y Microsoft Entra ID al acceder a Azure Files.

Cuando se configura una confianza en la nube, los clientes Windows obtienen su TGT de AD DS en lugar de Microsoft Entra ID. Los TGT emitidos por AD DS admiten la renovación, por lo que se evita el problema de expiración que se produce con Entra Kerberos. A continuación, el TGT emitido por AD DS se intercambia por un TGT de referencia de Entra, que se usa para obtener vales de servicio para Azure Files.

Esta mitigación solo se aplica a los clientes que son:

  • Unido a un dominio de AD DS, o
  • Unido al entorno híbrido de Microsoft Entra
  • Los clientes nativos de la nube (solo Microsoft Entra) no pueden usar esta solución alternativa.

Para aplicar esta mitigación, configure una confianza en la nube entre AD DS local y Microsoft Entra ID para acceder a Azure Files. Para obtener instrucciones paso a paso, consulte Configurar una confianza en la nube para la autenticación de Azure Files.

Error AADSTS50105

Síntoma

La solicitud se interrumpió con el siguiente error AADSTS50105:

El administrador configuró 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.

Causa

Si configura la asignación obligatoria en la aplicación empresarial correspondiente, no podrá obtener un vale de Kerberos. Los registros de inicio de sesión de Entra muestran un error aunque los usuarios o grupos estén asignados a la aplicación.

Solución

No seleccione Asignación requerida para la aplicación Microsoft Entra en la cuenta de almacenamiento, porque el proceso no incluye los permisos en el ticket de 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.

Consulte también

  • Last updated on