Compartir a través de

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

  • Artículo

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.

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 dispone de un privilegio requerido.

Causa: Los permisos de AD no son suficientes

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, 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 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.

Nota:

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

Solución

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 son compatibles con grupos y usuarios que se sincronizan entre AD DS y Microsoft Entra ID mediante Microsoft Entra Connect Sync o la sincronización en la nube de Microsoft Entra Connect. 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.

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

Causa

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.

Solución

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.

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

Pasos del diagnóstico automático

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 está habilitada 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

No se pueden montar recursos compartidos de archivos de Azure con Microsoft Entra Kerberos

Pasos del diagnóstico automático

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: compruebe el servicio auxiliar de IP (iphlpsvc) necesario para la autenticación Kerberos de Microsoft Entra. Su estado debe establecerse en Running.
  9. CheckFiddlerProxy: compruebe si existe un proxy Fiddler que impida la autenticación Kerberos de Microsoft Entra.
  10. CheckEntraJoinType: compruebe si la máquina está unida a un dominio Entra o unido a un dominio entra híbrido. Es un requisito previo para la autenticación Kerberos de Microsoft Entra.

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.

No se pueden configurar los permisos de nivel de directorio/archivo (ACL de Windows) con el Explorador de archivos de Windows.

Síntoma

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

Solución

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

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

Síntoma

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 trasladar 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 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.

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 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).

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

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 de módulo inferior a v0.2.2, debe descargar el módulo AzFilesHybrid más reciente y ejecutar el siguiente script de PowerShell. Si aún no ha habilitado la autenticación AD DS en su cuenta de almacenamiento, siga esta guía.

Importante

Si anteriormente usaba el cifrado RC4 y actualizaba la cuenta de almacenamiento para usar AES-256, debe ejecutar klist purge en el cliente y, a continuación, volver a montar el recurso compartido de archivos para obtener nuevos vales 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 gira las claves Kerberos, que es necesaria 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 recursos compartidos 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, debe tener en cuenta que los usuarios que se quitan de los roles Propietario o Colaborador pueden seguir teniendo acceso a la cuenta de almacenamiento mediante 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. 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.

Vaya a la cuenta de almacenamiento deseada en Azure Portal. En la tabla de contenido de la cuenta de almacenamiento que desee, seleccione Claves de Access 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

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

Después de habilitar la autenticación Kerberos de Microsoft Entra, 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 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".

Posibles errores cuando se habilita la autenticación Kerberos de Microsoft Entra para usuarios híbridos

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

Error: Conceder consentimiento del administrador deshabilitado

En algunos casos, el administrador de Microsoft Entra puede deshabilitar la capacidad de conceder consentimiento del administrador a las aplicaciones de Microsoft Entra. Esta es una captura de pantalla de cómo se ve esto en 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, 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 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.

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

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
}

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

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.

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 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.

Causa

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.

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 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:

    "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:

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

Error AADSTS50105

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.

Causa

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.

Solució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.

Consulte 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.