排查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 Sync 或 Microsoft Entra Connect 云同步从 AD DS 同步到Microsoft Entra ID的组和用户支持共享级别权限分配。确认分配共享级别权限的组和用户不受支持“仅限云”组。

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

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

原因

尝试在存储帐户上为Azure 文件存储启用Microsoft Entra 域服务身份验证时，发生错误 AadDsTenantNotFound，其中Microsoft Entra 域服务未在关联订阅的 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，请 Set-AD 运行调试 cmdlet 中返回的 cmdlet 以配置 SPN。
  3. CheckDomainJoined：验证客户端计算机是否已加入 AD 的域。 如果计算机未将域加入 AD，请参阅将 计算机加入域 以获取域加入说明。
  4. CheckPort445Connectivity：检查是否为 SMB 连接打开了端口 445。 如果端口 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

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

症状

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

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

解决方案

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

运行 Join-AzStorageAccountForAuth cmdlet 时出错

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

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

错误：“无法绑定位置参数，因为未提供任何名称”

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

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

从 AzFilesHybrid 模块 v0.2.2 开始，Azure 文件存储支持 AES-256 Kerberos 加密进行 AD DS 身份验证。 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 门户中所需的存储帐户。 在所需存储帐户的目录中，选择“安全性 + 网络”标题下的“访问密钥”。 在 “访问密钥 ”窗格中，选择“ 轮换所需密钥 上方的密钥”。

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

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

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

  1. 打开Microsoft Entra ID。
  2. 在左窗格中选择“应用注册”。
  3. 在右窗格中选择“ 所有应用程序 ”。
  4. 选择名称与 [存储帐户] $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/preview 功能。
  2. 你 (或管理员) 设置了 租户范围的策略 ，该策略：
    • 没有开始日期或开始日期在 2019 年 1 月 1 日之前。
    • 设置对服务主体密码的限制，该限制禁止自定义密码，或将最大密码生存期设置为小于 365.5 天。

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

原因 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服务主体密码，或按照以下步骤禁用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. 选择名称与 [存储帐户] $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 反馈社区提交产品反馈。