排查 Azure 文件存储基于标识的身份验证和授权问题 (SMB)

本文列出了将 SMB Azure 文件共享与基于标识的身份验证配合使用时的常见问题。 并提供了这些问题的可能原因和解决方法。 NFS Azure 文件共享当前不支持基于标识的身份验证。

适用于

文件共享类型	SMB	NFS
标准文件共享 (GPv2)、LRS/ZRS
标准文件共享 (GPv2)、GRS/GZRS
高级文件共享 (FileStorage)、LRS/ZRS

运行 AzFilesHybrid 模块时出错

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

客户端没有所需的特权。

原因：AD 权限不足

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

解决方案

请参阅 AD 特权，或联系 AD 管理员提供所需的权限。

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

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

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

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

如果最终用户使用 Active Directory 域服务（AD DS）或Microsoft Entra 域服务身份验证访问 Azure 文件共享，则如果共享级别权限不正确，则对文件共享的访问失败，并出现“拒绝访问”错误。

注意

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

解决方案

验证是否正确配置了权限：

• 有关 Active Directory 域服务 (AD DS)，请参阅分配共享级权限。

  已使用 Microsoft Entra Connect 同步或Microsoft Entra Connect 云同步，已从 AD DS 同步到 Microsoft Entra ID 的组和用户支持共享级权限分配。确认分配的组和用户共享级别权限不受支持“仅限云”组。

• Microsoft Entra 域服务 请参阅 分配共享级权限。

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

原因

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

解决方案

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

无法装载使用 AD 凭据的 Azure 文件存储

自我诊断步骤

首先，请确保已完成启用 Azure 文件存储 AD DS 身份验证的步骤。

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

第三，可以运行 Debug-AzStorageAccountAuth cmdlet，对已登录 AD 用户对 AD 配置执行一组基本检查。 AzFilesHybrid v0.1.2+ 版本支持此 cmdlet。 需要使用对目标存储帐户具有所有者权限的 AD 用户身份运行此 cmdlet。

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

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

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

1. CheckADObjectPasswordIsCorrect：确保在表示存储帐户的 AD 标识上配置的密码与存储帐户 kerb1 或 kerb2 密钥的匹配。 如果密码不正确，可以运行 Update-AzStorageAccountADObjectPassword 以重置密码。
2. CheckADObject：确认 Active Directory 中有一个对象表示存储帐户，并且具有正确的 SPN（服务主体名称）。 如果未正确设置 SPN，请运行调试 cmdlet 中返回的 Set-AD cmdlet 以配置 SPN。
3. CheckDomainJoined：验证客户端计算机是否已加入 AD。 如果计算机未加入 AD 域，请参阅“ 将计算机加入域 ”以获取域加入说明。
4. CheckPort445Connectivity：检查端口 445 是否已为 SMB 连接打开。 如果端口 445 未打开，请参阅故障排除工具 AzFileDiagnostics，了解Azure 文件存储的连接问题。
5. CheckSidHasAadUser：检查登录的 AD 用户是否已同步到 Microsoft Entra ID。 如果要查找特定 AD 用户是否同步到 Microsoft Entra ID，可以指定 -UserName 输入参数和 -Domain 输入参数。 对于给定的 SID，它会检查是否存在关联的Microsoft Entra 用户。
6. CheckAadUserHasSid：检查登录的 AD 用户是否已同步到 Microsoft Entra ID。 如果要查找特定 AD 用户是否同步到 Microsoft Entra ID，可以指定 -UserName 输入参数和 -Domain 输入参数。 对于给定的 Microsoft Entra 用户，它会检查其 SID。 若要运行此检查，必须提供 -ObjectId 参数以及 Microsoft Entra 用户的对象 ID。
7. CheckGetKerberosTicket：尝试获取 Kerberos 票证以连接到存储帐户。 如果没有有效的 Kerberos 令牌，请运行 klist get cifs/storage-account-name.file.core.windows.net cmdlet 并检查错误代码以确定票证检索失败的原因。
8. CheckStorageAccountDomainJoined：检查是否已启用 AD 身份验证，并填充帐户的 AD 属性。 否则，在Azure 文件存储上启用 AD DS 身份验证。
9. CheckUserRbacAssignment：检查 AD 标识是否具有适当的 RBAC 角色分配，以提供用于访问Azure 文件存储的共享级别权限。 如果没有， 请配置共享级权限。 （在 AzFilesHybrid v0.2.3+ 版本上受支持）
10. CheckUserFileAccess：检查 AD 标识是否具有适当的目录/文件权限（Windows ACL），以访问Azure 文件存储。 如果没有， 请配置目录/文件级别权限。 若要运行此检查，必须提供 -FilePath 参数以及要调试其访问权限的已装载文件的路径。 （在 AzFilesHybrid v0.2.3+ 版本上受支持）
11. 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 来执行一组基本检查。 AzFilesHybrid v0.3.0+ 版本上为 Microsoft Entra Kerberos 身份验证配置的存储帐户支持此 cmdlet。

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

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

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

1. CheckPort445Connectivity：检查端口 445 是否已为 SMB 连接打开。 如果端口 445 未打开，请使用故障排除工具 AzFileDiagnostics 解决Azure 文件存储的连接问题。
2. CheckAADConnectivity：检查 Entra 连接。 如果客户端无法访问 Entra，则使用 Kerberos 身份验证的 SMB 装载可能会失败。 如果此检查失败，则表明存在网络错误（可能是防火墙或 VPN 问题）。
3. CheckEntraObject：确认 Entra 中有一个对象，该对象表示存储帐户，并且具有正确的服务主体名称（SPN）。 如果未正确设置 SPN，请在存储帐户上禁用并重新启用 Entra Kerberos 身份验证。
4. CheckRegKey：检查注册表项是否 CloudKerberosTicketRetrieval 已启用。 此注册表项是 Entra Kerberos 身份验证所必需的。
5. CheckRealmMap：检查用户 是否已配置将帐户加入到另一个 Kerberos 领域的任何领域映射 ， 而不是 KERBEROS.MICROSOFTONLINE.COM。
6. CheckAdminConsent：检查 Entra 服务主体 是否已获得管理员同意 以获取 Kerberos 票证所需的 Microsoft Graph 权限。
7. CheckWinHttpAutoProxySvc：检查Microsoft Entra Kerberos 身份验证所需的 WinHTTP Web 代理自动发现服务（WinHttpAutoProxySvc）。 其状态应设置为 Running。
8. CheckIpHlpScv：检查Microsoft Entra Kerberos 身份验证所需的 IP 帮助程序服务（iphlpsvc）。 其状态应设置为 Running。

如果只想运行上一次检查的子选择，则可以使用参数 -Filter ，以及要运行的检查逗号分隔列表。

无法使用 Windows 文件资源管理器配置目录/文件级别权限 (Windows ACL)

症状

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

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

解决方案

建议使用 icacls 配置目录/文件级别权限，而不是使用 Windows 文件资源管理器。

运行 Join-AzStorageAccountForAuth cmdlet 时出现错误

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

如果具有 RID 主机 FSMO 角色的域控制器不可用或在从域中删除后从备份中还原，则可能会出现此错误。 确认所有域控制器都在运行并可用。

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

此错误很可能是由命令中的 Join-AzStorageAccountforAuth 语法错误触发的。检查命令是否存在拼写错误或语法错误，并验证是否安装了最新版本的 AzFilesHybrid 模块（https://github.com/Azure-Samples/azure-files-samples/releases）。

对 AES-256 Kerberos 加密的 Azure 文件存储本地 AD DS 身份验证支持

从 AzFilesHybrid 模块 v0.2.2 开始，Azure 文件存储支持对 AD DS 身份验证使用 AES-256 Kerberos 加密。 AES-256 是推荐的加密方法，它是从 AzFilesHybrid 模块 v0.2.5 开始使用的默认加密方法。 如果已使用低于 v0.2.2 的模块版本启用 AD DS 身份验证，则需要下载最新的 AzFilesHybrid 模块，并运行以下 PowerShell。 如果尚未在存储帐户上启用 AD DS 身份验证，请按照此指南操作。

重要

如果你以前使用 RC4 加密并将存储帐户更新为使用 AES-256，则应在客户端上运行 klist purge，然后重新装载文件共享，以便使用 AES-256 获取新的 Kerberos 票证。

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

Update-AzStorageAccountAuthForAES256 -ResourceGroupName $ResourceGroupName -StorageAccountName $StorageAccountName

作为更新的一部分，cmdlet 将轮换 Kerberos 密钥，这是切换到 AES-256 所必需的。 除非需要重新生成这两个密码，否则无需重新轮换。

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

存储帐户“所有者”和“参与者”角色授予列出存储帐户密钥的能力。 使用存储帐户密钥可以完全访问存储帐户的数据（包括文件共享、Blob 容器、表和队列），并可以经由通过 FileREST API 公开的旧版管理 API 对 Azure 文件存储管理操作进行有限访问。 如果要更改角色分配，应考虑从“所有者”或“参与者”角色中删除的用户可能会继续通过已保存的存储帐户密钥保持对存储帐户的访问权限。

解决方案 1

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

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

门户

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

PowerShell

以下脚本将轮换存储帐户的两个密钥。 如果希望在轮换期间换出密钥，则需要在脚本中提供其他逻辑来处理这种情况。 请记得将 <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"

Azure CLI

以下脚本将轮换存储帐户的两个密钥。 如果希望在轮换期间换出密钥，则需要在脚本中提供其他逻辑来处理这种情况。 请记得将 <resource-group> 和 <storage-account> 替换为适合环境的值。

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 权限。

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

为混合用户启用 Microsoft Entra Kerberos 身份验证时的潜在错误

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

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

在某些情况下，Microsoft Entra 管理员可能会禁用授予管理员同意Microsoft Entra 应用程序的能力。 下面是发生这种情况时的 Azure 门户的屏幕截图。

如果是这种情况，请让Microsoft Entra 管理员向新Microsoft Entra 应用程序授予管理员同意。 若要查找和查看管理员，请选择“角色和管理员”，然后选择“云应用程序管理员”。

错误 - “对 Azure AD Graph 的请求失败并出现代码 BadRequest”

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

启用 Microsoft Entra Kerberos 身份验证时，如果满足以下条件，可能会遇到此错误：

1. 你使用的是应用程序管理策略的 beta/预览功能。
2. 你（或你的管理员）已设置一个租户范围的策略，该策略：
   • 在 2019 年 1 月 1 日之前没有开始日期或开始日期。
   • 设置对服务主体密码的限制，该密码禁止自定义密码或设置最长密码生存期少于 365.5 天。

目前没有针对此错误的解决方法。

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

如果以前通过手动受限预览步骤启用了 entra Kerberos 身份验证 Microsoft，则可能会遇到此错误。 若要删除现有应用程序，客户或其 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 中的服务主体密码，或按照以下步骤禁用 Microsoft Entra Kerberos，删除现有应用程序，然后重新配置 Microsoft Entra Kerberos。

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

1. 禁用 Microsoft Entra Kerberos
2. 删除现有应用程序
3. 通过Azure 门户重新配置 Microsoft Entra Kerberos

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

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

如果使用 Microsoft Entra Kerberos 身份验证通过专用终结点/专用链接连接到存储帐户，则尝试通过 net use 或其他方法装载文件共享时，系统会提示客户端输入凭据。 用户可能会键入其凭据，但凭据被拒绝。

原因

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

解决方案

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

1. 打开 Microsoft Entra ID。

2. 在左侧窗格中选择“应用注册”。

3. 选择“所有应用程序”。

4. 选择名称匹配“[Storage Account] $storageAccountName.file.core.windows.net”的应用程序。

5. 选择左侧窗格中的“清单”。

6. 复制并粘贴现有内容，以便创建一个重复的副本。

7. 编辑 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"
   ],
   

8. 查看内容并选择“保存”以使用新的 identifierUris 更新应用程序对象。

9. 更新任何内部 DNS 引用以指向专用链接。

10. 重试装载共享。

错误AADSTS50105

请求因以下错误AADSTS50105中断：

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

原因

如果为相应的企业应用程序设置了“分配必需”，则无法获取 Kerberos 票证，并且Microsoft Entra 登录日志会显示错误，即使用户或组已分配给应用程序。

解决方案

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

另请参阅

• 对 Azure 文件进行故障排除
• 排查 Azure 文件存储性能问题
• 排查 Azure 文件存储连接性问题 (SMB)
• 排查 Linux 上的 Azure 文件存储一般 SMB 问题
• 排查 Linux 上的 Azure 文件存储一般 NFS 问题
• 排查 Azure 文件同步问题

联系我们寻求帮助

如果你有任何疑问或需要帮助，请创建支持请求或联系 Azure 社区支持。 你还可以将产品反馈提交到 Azure 反馈社区。