排查“Azure 文件存储”基于身份的身份验证和授权问题（SMB）

适用于： ✔️ SMB Azure 文件共享

总结

本文列出了将基于标识的身份验证与 SMB Azure 文件共享配合使用时的常见问题，并提供可能的原因和解决方法。使用本指南诊断和修复身份验证错误、权限问题和 Kerberos 配置问题。

运行 AzFilesHybrid 模块时出错

尝试运行 AzFilesHybrid 模块时，可能会收到以下错误：

客户端没有所需的特权。

原因：AD 权限不足

出现此问题是因为你没有运行模块所需的Active Directory（AD）权限。

解决方案

请查看 AD 权限，或联系 AD 管理员以提供所需的权限。

尝试装载文件共享时，可能会收到以下错误：

发生系统错误 5。访问被拒绝。

如果最终用户使用基于标识的身份验证访问 Azure 文件共享，则如果共享级别权限不正确，则对文件共享的访问失败，并出现“拒绝访问”错误。

备注

此错误可能是由于共享级别权限不正确以外的问题造成的。有关其他可能的原因和解决方案的信息，请参阅 Troubleshoot Azure 文件存储连接和访问问题。

解决方案

验证是否正确配置了权限。请参阅 “分配共享级别权限”。

为 Microsoft Entra 域服务启用 Azure 文件身份验证时出现错误 AadDsTenantNotFound：“无法找到具有租户 ID 的活跃租户 Microsoft Entra 租户 ID”

原因

尝试在存储帐户上为 Azure 文件存储启用 Microsoft Entra 域服务身份验证时，如果关联的订阅的 Microsoft Entra 租户中未创建 Microsoft Entra 域服务，会发生错误 AadDsTenantNotFound。

解决方案

在您的存储帐户所部署的订阅的 Microsoft Entra 租户上启用 Microsoft Entra 域服务。需要Microsoft Entra租户的管理员权限才能创建托管域。如果你不是 Microsoft Entra 租户的管理员，请联系管理员，并按照分步指南创建和配置 Microsoft Entra 域服务托管域。

错误：所有新添加的 URI 都必须包含租户验证的域、租户 ID 或应用 ID

原因

添加不符合Microsoft Entra ID 应用程序安全要求的重定向 URI 或标识符 URI 时，Azure 文件的基于标识的身份验证配置期间会出现此错误。

Microsoft Entra ID对应用程序标识符 URI 和重定向 URI 强制实施限制。新添加的 URI 必须引用以下值之一：

租户验证的自定义域
Microsoft Entra租户 ID
应用程序（客户端）ID

如果 URI 使用未验证的域、 .local 主机名或未与租户关联的任意 URL，则默认租户策略会阻止请求。

Microsoft Entra ID 强制实施此行为，它不特定于 Azure 文件服务。

有关详细信息，请参见:

解决方案

为 Azure 文件配置应用程序注册或基于标识的身份验证时，请确保任何重定向 URI 或标识符 URI 都使用受支持的格式之一：

使用租户验证的自定义域
使用 Microsoft Entra 租户 ID
使用应用程序（客户端）ID

请勿使用未经验证的域、 .local 主机名或任意 URL，因为Microsoft Entra ID 租户策略拒绝这些值。如果不确定租户中验证了哪些域，请查看 Microsoft Entra 管理中心中的“自定义域名”部分，或与租户管理员联系。

无法使用 AD 凭据装载Azure文件共享

自我诊断步骤

首先，请确保您已按照步骤启用 Azure 文件存储 AD DS 身份验证。

其次，请尝试使用存储帐户密钥装载Azure文件共享。如果共享无法装载，请下载 AzFileDiagnostics 以帮助验证客户端运行环境。 AzFileDiagnostics 可以检测可能导致Azure 文件存储访问失败的不兼容客户端配置，提供自我修复的规范性指导，并收集诊断跟踪。

第三，运行 Debug-AzStorageAccountAuth cmdlet，使用登录的 AD 用户对 AD 配置执行一组基本检查。 AzFilesHybrid v0.1.2+ 支持此 cmdlet。

以对目标存储帐户具有所有者权限的 AD 用户以交互方式登录Azure PowerShell：
```
Connect-AzAccount
```

运行 Debug-AzStorageAccountAuth cmdlet。

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

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

此 cmdlet 按顺序执行以下检查，并提供有关故障的指导：

CheckADObjectPasswordIsCorrect：确保在代表该存储帐户的 AD 标识上配置的密码与该存储帐户的 kerb1 或 kerb2 密钥匹配。如果密码不正确，请运行 Update-AzStorageAccountADObjectPassword 重置密码。
CheckADObject：确认Active Directory中有一个对象表示存储帐户，并且具有正确的 SPN（服务主体名称）。如果未正确设置 SPN，请运行调试 cmdlet 中返回的 Set-AD cmdlet 以配置 SPN。
CheckDomainJoined：验证客户端计算机是否已加入到 AD 域。如果您的计算机没有加入 AD 域，请参阅“将计算机加入域”以获取域加入说明。
CheckPort445Connectivity：检查端口 445 是否为 SMB 连接打开。如果端口 445 未打开，请参阅故障排除工具 AzFileDiagnostics，了解Azure 文件存储的连接问题。
CheckSidHasAadUser：检查登录的 AD 用户是否已同步到Microsoft Entra ID。若要查找特定 AD 用户是否同步到Microsoft Entra ID，请在输入参数中指定 -UserName 和 -Domain。对于给定的 SID，它会检查是否存在关联的Microsoft Entra ID用户。
CheckAadUserHasSid：检查登录的 AD 用户是否已同步到Microsoft Entra ID。若要查找特定 AD 用户是否同步到Microsoft Entra ID，请在输入参数中指定 -UserName 和 -Domain。对于给定Microsoft Entra ID用户，它会检查其 SID。若要运行此检查，请提供 -ObjectId 参数以及Microsoft Entra ID用户的对象 ID。
CheckGetKerberosTicket：尝试获取 Kerberos 票证以连接到存储帐户。如果没有有效的 Kerberos 令牌，请运行 klist get cifs/storage-account-name.file.core.windows.net cmdlet 并检查错误代码以确定票证检索失败的原因。
CheckStorageAccountDomainJoined：检查是否已启用 AD 身份验证，并填充帐户的 AD 属性。否则，对 Azure 文件存储启用 AD DS 身份验证。
CheckUserRbacAssignment：检查 AD 标识是否具有适当的 RBAC 角色分配，以提供用于访问Azure 文件存储的共享级别权限。如果没有，请配置共享级权限。（AzFilesHybrid v0.2.3+支持）
CheckUserFileAccess：检查 AD 标识是否具有访问Azure 文件存储的适当目录/文件权限（Windows ACL）。如果没有，请配置目录/文件级别权限。若要运行此检查，请提供 -FilePath 参数以及要调试其访问权限的已装载文件的路径。（AzFilesHybrid v0.2.3+支持）
CheckKerberosTicketEncryption：检查存储帐户是否已配置为接受 Kerberos 票证使用的加密类型。（AzFilesHybrid v0.2.5+支持）
CheckChannelEncryption：检查存储帐户是否已配置为接受客户端使用的 SMB 通道加密类型。（AzFilesHybrid v0.2.5+支持）
CheckDomainLineOfSight：检查客户端是否具备与域控制器不受阻碍的网络连接。（AzFilesHybrid v0.2.5+支持）
CheckDefaultSharePermission：检查是否配置了默认共享级别权限。（AzFilesHybrid v0.2.5+支持）
CheckAadKerberosRegistryKeyIsOff：检查 Microsoft Entra Kerberos 注册表项是否已禁用。如果键处于打开状态，请在提升的命令提示符下运行 reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 0 以将其关闭，然后重新启动计算机。（AzFilesHybrid v0.2.9+支持）

如果您想运行前面那些检查中的一部分，请使用 -Filter 参数，并指定一个以逗号分隔的要运行检查列表。例如，若要运行与共享级别权限（RBAC）相关的所有检查，请使用以下 PowerShell cmdlet：

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

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

如果在 X: 上装载了文件共享，并且只想运行与文件级权限（Windows ACL）相关的检查，请运行以下 PowerShell cmdlet：

$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

无法使用 Microsoft Entra Kerberos 挂载 Azure 文件共享

自我诊断步骤

首先，请确保按照相关步骤启用 Microsoft Entra Kerberos 身份验证。

其次，运行 Debug-AzStorageAccountAuth cmdlet 来执行一组基本检查。此 cmdlet 支持在 AzFilesHybrid v0.3.0+ 上已配置 Microsoft Entra Kerberos 身份验证的存储帐户。

以对目标存储帐户具有所有者权限的 AD 用户以交互方式登录Azure PowerShell：
```
Connect-AzAccount
```

运行 Debug-AzStorageAccountAuth cmdlet。

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

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

此 cmdlet 按顺序执行以下检查，并提供有关故障的指导：

CheckPort445Connectivity：检查端口 445 是否为 SMB 连接打开。如果端口 445 未打开，请使用故障排除工具 AzFileDiagnostics，解决Azure 文件存储的连接问题。
CheckAADConnectivity：检查 Entra 连通性。如果客户端无法访问 Entra，则使用 Kerberos 身份验证的 SMB 装载可能会失败。如果此检查失败，则表明存在网络错误（可能是防火墙或 VPN 问题）。
CheckEntraObject：确认 Entra 中有一个对象表示存储帐户，并且具有正确的服务主体名称（SPN）。如果未正确设置 SPN，请在存储帐户上禁用并重新启用 Entra Kerberos 身份验证。
CheckRegKey：检查 CloudKerberosTicketRetrieval 注册表项是否已启用。此注册表项是 Entra Kerberos 身份验证所必需的。
CheckRealmMap：检查用户是否配置了任何领域映射，以将该账户加入到与 KERBEROS.MICROSOFTONLINE.COM 不同的另一个 Kerberos 领域。
CheckAdminConsent：检查 Entra 服务主体是否已被授予管理员同意，以获取 Kerberos 票证所需的 Microsoft Graph 权限。
CheckWinHttpAutoProxySvc：检查用于 Microsoft Entra Kerberos 身份验证所需的 WinHTTP Web 代理自动发现服务（WinHttpAutoProxySvc）。其状态应设置为 Running。出于安全原因，可以选择通过注册表项禁用 Web 代理自动发现（WPAD）。但是，不要禁用整个 WinHttpAutoProxySvc 服务，因为它负责许多其他功能，包括 Kerberos 密钥分发中心代理（KDC 代理）请求。
CheckIpHlpScv：检查 Microsoft Entra Kerberos 身份验证所需的 IP Helper 服务（iphlpsvc）。其状态应设置为 Running。
CheckFiddlerProxy：检查是否存在阻止Microsoft Entra Kerberos 身份验证的 Fiddler 代理。
CheckEntraJoinType：检查计算机是否已加入 Entra 域或已加入混合 Entra 域。这是Microsoft Entra Kerberos 身份验证的先决条件。

如果您想运行前面那些检查中的一部分，请使用 -Filter 参数，并指定一个以逗号分隔的要运行检查列表。

由于不支持 Kerberos 加密类型，使用 Entra Kerberos 时装载到 Azure 文件存储失败。

使用 Microsoft Entra Kerberos 身份验证装载Azure文件共享时，装载操作将失败。日志收集可能会显示无法解密 Kerberos 服务票证。您可能还会发现已配置以下注册表项：HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\SupportedEncryptionTypes

原因

如果将 SupportedEncryptionTypes 注册表项配置为不包含 AES 的值，Windows 仅允许使用由该位掩码指定的加密类型。例如，该值 0x7 指示客户端仅支持以下 Kerberos 加密类型：

DES_CBC_CRC
DES_CBC_MD5
RC4_HMAC

由于 Microsoft Entra Kerberos 始终使用 AES-256（AES256-CTS-HMAC-SHA1-96）因此，如果帐户或计算机支持的加密类型中不包含 AES，则装载会失败。

备注

默认情况下，新式Windows操作系统上启用了 AES 加密。如果未配置 SupportedEncryptionTypes 注册表项，Windows 会在可用时自动协商使用 AES。

解决方案

若要使用 Microsoft Entra Kerberos 成功装载Azure文件共享，请在支持的加密类型中包含 AES-256。

使用以下选项之一：

选项 1：删除注册表项（如果不是有意配置，建议这样做）

如果未故意限制加密类型：

删除注册表项：HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\SupportedEncryptionTypes
重新启动计算机。

重新启动后，请重试装载文件共享。

小窍门

删除密钥会还原Windows默认行为，这允许Active Directory自动协商 Kerberos 票证的 AES。

选项 2：使用组策略显式启用 AES-256

如果你的组织需要显式配置的 Kerberos 加密类型：

按 Win + R，键入 gpedit.msc并选择 Enter。
转到：Local Computer Policy > 计算机配置> Windows设置>安全设置>本地策略>安全选项
打开 网络安全：配置 Kerberos 允许的加密类型。
启用以下加密类型：
- AES256_HMAC_SHA1
- AES128_HMAC_SHA1 （可选）
应用更改并重新启动计算机。

重新启动后，请重试装载文件共享。

重要

Entra Kerberos 需要 AES256_HMAC_SHA1 才能成功装载Azure文件共享。 RC4 或仅使用 DES 的配置会失败。若要了解有关注册表项的详细信息，请参阅解密支持的 Kerberos 加密类型的选择。

无法使用文件资源管理器配置目录或文件级别权限（Windows ACL）

症状

尝试在装载的文件共享上使用文件资源管理器配置 Windows ACL 时，可能会遇到以下症状之一：

单击“安全”选项卡下的“编辑权限”后，“权限”向导不会加载。
尝试选择新用户或组时，域位置不会显示正确的Active Directory 域服务（AD DS）域。
你正在使用多个 AD 林，并收到以下错误消息：“无法使用在以下域中查找所选对象所需的 Active Directory 域控制器。” 确保Active Directory域控制器可用，并尝试再次选择对象。

解决方案

不要使用文件资源管理器，而应使用 icacls 配置目录级或文件级权限。

无法在文件资源管理器中查看文件或目录所有者的用户主体名称（UPN）

症状

文件资源管理器显示文件或目录所有者的安全标识符（SID），但不显示 UPN。

原因

文件资源管理器将 RPC API 直接调用服务器（Azure 文件存储），将 SID 转换为 UPN。 Azure 文件存储不支持此 API，因此不会显示 UPN。

解决方案

在已加入域的客户端上，使用以下 PowerShell 命令查看目录及其所有者中的所有项，包括 UPN：

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

运行 Join-AzStorageAccountForAuth cmdlet 时出现错误

错误：“目录服务无法分配相对标识符”

如果保留 RID 主 FSMO 角色的域控制器不可用或已从域中删除并从备份中还原，则会发生此错误。确认所有域控制器都在运行并可用。

错误： “无法绑定位置参数，因为未指定名称”

此错误很可能是由命令中的 Join-AzStorageAccountforAuth 语法错误触发的。检查命令是否存在拼写错误或语法错误，并验证是否安装了最新版本的 AzFilesHybrid 模块。

以前具有“所有者”或“参与者”角色分配的用户标识仍具有存储帐户密钥访问权限

存储帐户“所有者”和“参与者”角色授予列出存储帐户密钥的能力。存储帐户密钥允许完全访问存储帐户的数据，包括文件共享、blob、表和队列。它还通过通过 FileREST API 公开的旧管理 API 提供对Azure 文件存储管理操作的有限访问权限。如果要更改角色分配，请考虑从所有者或参与者角色中删除的用户可能继续通过保存的存储帐户密钥访问存储帐户。

解决方案 1

可以通过轮换存储帐户密钥轻松解决此问题。每次轮换一个密钥，并在轮换过程中将访问权限从一个密钥切换到另一个密钥。存储帐户提供两种类型的共享密钥：存储帐户密钥（提供对存储帐户数据的超级管理员访问权限）和 Kerberos 密钥（用作存储帐户与Windows Server Active Directory域控制器之间的共享机密）用于Windows ServerActive Directory方案。

若要轮换存储帐户的 Kerberos 密钥，请参阅在 AD DS 中更新存储帐户标识的密码。

在Azure门户中导航到所需的存储帐户。在所需存储帐户的目录下，选择“安全性 + 网络”标题下的“访问密钥”。在“访问密钥”窗格中，选择所需密钥上方的“轮换密钥”。

显示“访问密钥”窗格的屏幕截图。

以下脚本轮换存储帐户的两个密钥。如果要在轮换期间交换密钥，则需要在脚本中提供其他逻辑来处理此方案。将<resource-group>和<storage-account>替换为适合您环境的适当值。

$resourceGroupName = "<resource-group>"
$storageAccountName = "<storage-account>"

# Rotate primary key (key 1). You should switch to key 2 before rotating key 1.
New-AzStorageAccountKey `
    -ResourceGroupName $resourceGroupName `
    -Name $storageAccountName `
    -KeyName "key1"

# Rotate secondary key (key 2). You should switch to the new key 1 before rotating key 2.
New-AzStorageAccountKey `
    -ResourceGroupName $resourceGroupName `
    -Name $storageAccountName `
    -KeyName "key2"

RESOURCE_GROUP_NAME="<resource-group>"
STORAGE_ACCOUNT_NAME="<storage-account>"

# Rotate primary key (key 1). You should switch to key 2 before rotating key 1.
az storage account keys renew \
    --resource-group $RESOURCE_GROUP_NAME \
    --account-name $STORAGE_ACCOUNT_NAME \
    --key "primary"

# Rotate secondary key (key 2). You should switch to the new key 1 before rotating key 2.
az storage account keys renew \
    --resource-group $RESOURCE_GROUP_NAME \
    --account-name $STORAGE_ACCOUNT_NAME \
    --key "secondary"

在新创建的应用程序上设置 API 权限

启用 Microsoft Entra Kerberos 身份验证后，您必须明确向注册在 Microsoft Entra 租户中的新 Microsoft Entra 应用程序授予管理员同意，才能完成配置。可以按照以下步骤从 Azure 门户配置 API 权限。

打开 Microsoft Entra ID。
在左窗格中选择 应用注册。
在右窗格中选择“所有应用程序”。
选择名称匹配“[Storage Account] $storageAccountName.file.core.windows.net”的应用程序。
在左侧窗格中选择“API 权限”。
选择页面底部的添加权限。
选择为“DirectoryName”授予管理员同意。

启用 Microsoft Entra Kerberos 身份验证时的潜在错误

启用 Microsoft Entra Kerberos 身份验证时，可能会遇到以下错误。

在某些情况下，Microsoft Entra管理员可能会禁用向Microsoft Entra应用程序授予管理员同意的功能。这是 Azure 门户中的此界面外观的屏幕截图。

如果存在此条件，请让 Entra 管理员向新的 Entra 应用程序授予管理员同意。若要查找和查看管理员，请选择 角色和管理员，然后选择 云应用程序管理员。

错误 - “请求 Microsoft Graph 时返回错误代码 BadRequest”

原因 1：应用程序管理策略阻止创建凭据

启用 Microsoft Entra Kerberos 身份验证时，如果（或管理员）设置了租户范围的策略或应用管理策略，可能会遇到此错误：

适用于“存储资源提供程序”企业应用程序（应用 ID a6aa9161-5291-40bb-8c5c-923b567bee3b）。
设置对服务主体密码的限制，这会阻止添加密码或将最长密码生存期限制为少于 365.5 天。

若要解决此错误，请将有问题的策略配置为对“存储资源提供程序”企业应用程序（应用 ID ）a6aa9161-5291-40bb-8c5c-923b567bee3b。

原因 2：存储帐户已存在应用程序

如果您以前通过手动受限预览步骤启用了 Microsoft Entra 的 Kerberos 身份验证，则可能会遇到此错误。若要删除现有应用程序，客户或其 IT 管理员可以运行以下脚本。运行此脚本会删除旧的手动创建的应用程序，并允许新体验自动创建和管理新创建的应用程序。启动与Microsoft Graph的连接后，登录到设备上的 Microsoft Graph 命令行工具应用程序，并向应用授予权限。

$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
}

错误 - Microsoft Entra ID 中的服务主体密码已过期

如果以前通过手动受限预览步骤启用了 Microsoft Entra Kerberos 身份验证，则存储帐户的服务主体的密码每六个月过期一次。密码过期后，用户无法获取 Kerberos 票证来访问文件共享。

若要解决此问题，可以每隔六个月轮换Microsoft Entra ID服务主体密码，或按照以下步骤禁用 Microsoft Entra Kerberos，删除现有应用程序，然后重新配置 Microsoft Entra Kerberos。

在禁用 Microsoft Entra Kerberos 之前，请务必保存域属性（domainName 和 domainGUID），因为如果要使用Windows文件资源管理器配置目录和文件级权限，则需要在重新配置期间保存它们。如果未保存域属性，仍可以使用 icacls 作为解决方法来配置目录/文件级权限。

重新配置 Microsoft Entra Kerberos 时，新体验会自动创建和管理新创建的应用程序。

错误 1326 - 使用专用链接时用户名或密码不正确

如果你使用 Microsoft Entra Kerberos 身份验证通过专用终结点连接到存储帐户，当你尝试使用 net use 或其他方法挂载文件共享时，客户端会提示你输入凭据。如果您输入凭据，这些凭据将被拒绝。

原因

发生此错误的原因是 SMB 客户端尝试使用 Kerberos 但失败，因此它回退到使用 NTLM 身份验证。 Azure 文件存储不支持对域凭据使用 NTLM 身份验证。客户端无法获取存储帐户的 Kerberos 票证，因为专用链接 FQDN 未注册到任何现有的 Entra 应用程序。

解决方案

在装载文件共享之前，将 privateLink FQDN 添加到存储帐户的 Entra 应用程序。可以使用 Azure 门户并按照以下步骤将所需的 identifierUris 添加到应用程序对象：

打开 Microsoft Entra ID。
在左窗格中选择 应用注册。
选择“所有应用程序”。
选择名称匹配“[Storage Account] $storageAccountName.file.core.windows.net”的应用程序。
选择左侧窗格中的Manifest。
复制并粘贴现有内容，以便创建一个重复的副本。

编辑 JSON 清单。对于每个 <storageAccount>.file.core.windows.net 条目，请添加相应的 <storageAccount>.privatelink.file.core.windows.net 条目。例如，如果您的清单文件对于 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"
],

然后将字段 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",

    "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"
],

查看内容并选择“保存”以使用新的 identifierUris 更新应用程序对象。
更新任何内部 DNS 引用以指向专用链接。
重试挂载共享。

使用 Microsoft Entra Kerberos 时网络更改后出现间歇性身份验证失败

症状

Windows客户端使用 Microsoft Entra Kerberos 身份验证访问 Azure 文件时，在网络更改后（例如 VPN 重新连接、Wi-Fi 改变、睡眠或唤醒），可能会间歇性地失去访问权限。在用户注销并重新登录到Windows之前，访问可能会失败。

原因

此问题是由于已知的Windows行为而发生的。某些网络更改清除客户端上缓存的 KDC 代理配置。删除 KDC 代理配置后，客户端无法从Microsoft Entra ID刷新 Kerberos 服务票证。

尽管用户的主刷新令牌（PRT）保持有效，但缺少的 KDC 代理配置会阻止客户端获取新的服务票证，因此身份验证失败。

此限制适用于Windows客户端。 Azure 文件存储或Microsoft Entra ID配置不会导致此问题。

解决方案

Option one：注销并重新登录 Windows，通过获取新的 PRT 来恢复访问权限，其中包括刷新后的票证授予票证（TGT）和 KDC 代理配置。但是，此过程会导致用户体验不佳。

选项 2：配置组策略设置以在客户端上保留 KDC 代理配置，从而减少网络更改导致的身份验证中断。

使用组策略配置 KDC 代理设置。
打开组策略管理并编辑适用的策略。
转到 管理模板>系统>Kerberos>为 Kerberos 客户端指定 KDC 代理服务器。
选择启用。
在 “选项”下，选择“ 显示 ”以打开“显示内容”对话框。
添加以下映射，将 Microsoft_Entra_tenant_id 替换为 Microsoft Entra 租户 ID。在 https 之后和结尾的 / 之前包含空格。

值名称价值

KERBEROS.MICROSOFTONLINE.COM <https login.microsoftonline.com：443：your_Microsoft_Entra_tenant_id/kerberos />
选择“ 确定”，然后选择“ 应用”。

值名称	价值
KERBEROS.MICROSOFTONLINE.COM	<https login.microsoftonline.com：443：your_Microsoft_Entra_tenant_id/kerberos />

应用此策略后，Windows客户端在网络更改中保留 KDC 代理配置，从而减少身份验证中断。

使用 Microsoft Entra Kerberos 时，身份验证在大约 10 小时后停止

症状

使用 Microsoft Entra Kerberos 身份验证的 Windows 客户端在连续使用 Azure 文件存储大约 10 小时后将失去访问权限。只有在用户注销并重新登录到Windows后，才会还原访问权限。

原因

此问题是由 Microsoft Entra Kerberos 身份验证中的已知限制引起的。 Microsoft Entra ID 当前不支持续订票证授予票证（TGT）。

在 Microsoft Entra Kerberos 场景中，用户会获得 TGT，该 TGT 是其主要刷新令牌（PRT）的一部分。由于 TGT 续订不受支持，因此客户端在 TGT 过期后无法刷新 TGT。当 TGT 过期时，客户端无法获取新的服务票证，这会导致身份验证失败。

注销并重新登录Windows通过获取新的 PRT（包括新的 TGT）来修复问题。这是Microsoft Entra Kerberos 的已知限制，不是由Azure 文件存储配置引起的。

解决方案

作为缓解措施，请在访问Azure 文件存储时在本地Active Directory 域服务（AD DS）和Microsoft Entra ID之间配置云信任。

配置云信任时，Windows客户端从 AD DS 获取其 TGT，而不是Microsoft Entra ID。 AD DS 颁发的 TGT 支持续订，因此可以避免 Entra Kerberos 中会出现的到期问题。然后，将 AD DS 签发的 TGT 换成 Entra 引荐 TGT，并使用该 TGT 获取 Azure 文件存储的服务票证。

此缓解仅适用于以下客户端：

已加入 AD DS 域，或
已加入 Microsoft Entra 混合环境
云原生（仅限Microsoft Entra）客户端无法使用此解决方法。

若要应用此缓解措施，请在本地 AD DS 与Microsoft Entra ID之间配置云信任，以便访问Azure 文件存储。有关分步指南，请参阅为Azure 文件存储身份验证配置云信任。

错误AADSTS50105

症状

请求因以下错误AADSTS50105中断：

管理员将应用程序“企业应用程序名称”配置为阻止用户，除非他们被专门授予（已分配）对应用程序的访问权限。登录的用户“{EmailHidden}”被阻止，因为它们不是具有访问权限的组的直接成员，也没有管理员直接分配访问权限。请与管理员联系，以分配对此应用程序的访问权限。

原因

如果为相应的企业应用程序设置了 所需的分配 ，则无法获取 Kerberos 票证。即使将用户或组分配到应用程序，Entra 登录日志也会显示错误。

解决方案

不要为存储帐户选择Microsoft Entra应用程序所需的 Assignment，因为进程不会在返回给请求者的 Kerberos 票证中填充权利。有关详细信息，请参阅错误 AADSTS50105 - 登录用户未被分配应用程序的角色。

另请参阅

反馈

此页面是否有帮助？

Last updated on 2026-06-03

排查“Azure 文件存储”基于身份的身份验证和授权问题（SMB）

总结

运行 AzFilesHybrid 模块时出错

原因：AD 权限不足

解决方案

装载Azure文件共享时出现错误 5

原因：共享级别权限不正确

解决方案

为 Microsoft Entra 域服务启用 Azure 文件身份验证时出现错误 AadDsTenantNotFound：“无法找到具有租户 ID 的活跃租户 Microsoft Entra 租户 ID”

原因

解决方案

错误：所有新添加的 URI 都必须包含租户验证的域、租户 ID 或应用 ID

原因

解决方案

无法使用 AD 凭据装载Azure文件共享

自我诊断步骤

无法使用 Microsoft Entra Kerberos 挂载 Azure 文件共享

自我诊断步骤

由于不支持 Kerberos 加密类型，使用 Entra Kerberos 时装载到 Azure 文件存储 失败。

原因

解决方案

选项 1：删除注册表项（如果不是有意配置，建议这样做）

选项 2：使用组策略显式启用 AES-256

无法使用文件资源管理器配置目录或文件级别权限（Windows ACL）

症状

解决方案

无法在文件资源管理器中查看文件或目录所有者的用户主体名称（UPN）

症状

原因

解决方案

运行 Join-AzStorageAccountForAuth cmdlet 时出现错误

错误：“目录服务无法分配相对标识符”

错误： “无法绑定位置参数，因为未指定名称”

以前具有“所有者”或“参与者”角色分配的用户标识仍具有存储帐户密钥访问权限

解决方案 1

在新创建的应用程序上设置 API 权限

启用 Microsoft Entra Kerberos 身份验证时的潜在错误

错误 -“授予管理员同意”已禁用

错误 - “请求 Microsoft Graph 时返回错误代码 BadRequest”

原因 1：应用程序管理策略阻止创建凭据

原因 2：存储帐户已存在应用程序

错误 - Microsoft Entra ID 中的服务主体密码已过期

错误 1326 - 使用专用链接时用户名或密码不正确

原因

解决方案

使用 Microsoft Entra Kerberos 时网络更改后出现间歇性身份验证失败

症状

原因

解决方案

使用 Microsoft Entra Kerberos 时，身份验证在大约 10 小时后停止

症状

原因

解决方案

错误AADSTS50105

症状

原因

解决方案

另请参阅

反馈

其他资源

由于不支持 Kerberos 加密类型，使用 Entra Kerberos 时装载到 Azure 文件存储失败。