你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
实现 SMB 访问的 Azure 文件存储基于标识的身份验证选项概述
本文介绍 Azure 文件共享如何在本地或 Azure 中使用域服务,以支持通过 SMB 对 Azure 文件共享进行基于标识的访问。 通过为 Azure 文件共享启用基于标识的访问,你可以将现有文件服务器替换为 Azure 文件共享,而无需替换现有的目录服务,从而保持用户对共享的无缝访问。
术语表
了解与为 Azure 文件共享进行基于标识的身份验证相关的一些关键术语非常有用:
Kerberos 身份验证
Kerberos 是一种身份验证协议,用于验证用户或主机的标识。 有关 Kerberos 的详细信息,请参阅 Kerberos 身份验证概述。
服务器消息块 (SMB) 协议
SMB 是行业标准网络文件共享协议。 有关 SMB 的详细信息,请参阅 Microsoft SMB 协议和 CIFS协议概述。
Microsoft Entra ID
Microsoft Entra ID(前 Azure AD)是 Microsoft 的多租户、基于云的目录和标识管理服务。 Microsoft Entra ID 将核心目录服务、应用程序访问管理和标识保护融入一个解决方案中。
Microsoft Entra 域服务
Microsoft Entra 域服务提供托管域服务,例如域加入、组策略、LDAP、Kerberos/NTLM 身份验证。 这些服务与 Active Directory 域服务完全兼容。 有关详细信息,请参阅 Microsoft Entra 域服务。
本地 Active Directory 域服务 (AD DS)
通过将本地 Active Directory 域服务 (AD DS) 与 Azure 文件存储集成,可存储目录数据,同时可向网络用户和管理员提供该数据。 安全性通过登录身份验证以及对目录中对象的访问控制与 AD DS 集成。 通过单一网络登录,管理员可以管理其整个网络中的目录数据和组织,获得授权的网络用户可以访问该网络上的任何资源。 本地环境中的或云托管 VM 上的企业通常采用 AD DS,并将 AD DS 凭据用于访问控制。 有关详细信息,请参阅 Active Directory 域服务概述。
Azure 基于角色的访问控制 (Azure RBAC)
Azure RBAC 为 Azure 实现了精细的访问管理。 使用 Azure RBAC,可通过向用户授予执行其作业所需的最少权限来管理对资源的访问权限。 有关详细信息,请参阅什么是 Azure 基于角色的访问控制?
混合标识。
混合用户标识是 AD DS 中通过本地 Microsoft Entra Connect 同步应用程序或 Microsoft Entra Connect 云同步(可从 Microsoft Entra 管理中心安装的轻型代理)同步到 Microsoft Entra ID 的标识。
支持的身份验证方案
Azure 文件存储支持使用以下方法通过 SMB 进行基于标识的身份验证。 对每个存储帐户只能使用一种方法。
- 本地 AD DS 身份验证:本地 AD DS 联接或 Microsoft Entra 域服务联接的 Windows 计算机可以通过 SMB 使用同步到 Microsoft Entra ID 的本地 Active Directory 凭据访问 Azure 文件共享。 客户端必须与 AD DS 建立无障碍的网络连接。 如果已在本地或 Azure 中的 VM 上设置 AD DS,设备通过加入域联接 AD,则应使用 AD DS 进行 Azure 文件共享身份验证。
- Microsoft Entra 域服务身份验证: 基于云的 Microsoft Entra 域服务联接的 Windows VM 可以使用 Microsoft Entra 凭据访问 Azure 文件共享。 在此解决方案中,Microsoft Entra ID 代表客户运行传统的 Windows Server AD 域,该域是客户 Microsoft Entra 租户的子域。
- 用于混合标识的 Microsoft Entra Kerberos:使用 Microsoft Entra ID 对混合用户标识进行身份验证,允许 Microsoft Entra 用户使用 Kerberos 身份验证访问 Azure 文件共享。 这意味着最终用户可以通过 Internet 访问 Azure 文件共享,而无需建立从 Microsoft Entra 混合联接和 Microsoft Entra 联接的 VM 到域控制器的连接。 目前不支持仅限云的标识。
- 适用于 Linux 客户端的 AD Kerberos 身份验证:Linux 客户端可以使用本地 AD DS 或 Microsoft Entra 域服务通过 SMB 对 Azure 文件存储使用 Kerberos 身份验证。
限制
- 任何身份验证方法都不支持使用 Azure RBAC 将共享级别权限分配到计算机帐户(机器帐户),因为无法将计算机帐户同步到 Microsoft Entra ID 中的标识。 如果要允许计算机帐户使用基于标识的身份验证访问 Azure 文件共享,请使用默认共享级别权限或考虑改用服务登录帐户。
- 网络文件系统 (NFS) 共享不支持基于标识的身份验证。
常见用例
使用 Azure 文件存储的基于标识的身份验证在以下各种场景中都很有用:
取代本地文件服务器
弃用和取代分散的本地文件服务器,这是每个企业会在 IT 现代化旅程中遇到的一个共同问题。 可以将数据迁移到 Azure 文件存储时,最恰当的做法是将 Azure 文件共享和本地 AD DS 身份验证结合在一起使用。 通过完全迁移,你可以利用高可用性和可伸缩性的优势,同时最大程度地减少客户端更改。 它为最终用户提供无缝的迁移体验,这样最终用户就可以继续通过现有的加入域的计算机使用相同的凭据访问其数据。
将应用程序直接迁移到 Azure
将应用程序直接迁移到云时,你可能想要为数据保留同样的身份验证模型。 将基于标识的访问控制体验扩展到 Azure 文件共享时,就无需再将应用程序更改为新式身份验证方式,这样还会加快云采用进程。 Azure 文件共享提供了与 Microsoft Entra 域服务或本地 AD DS 集成来进行身份验证的选项。 如果计划实现 100% 云原生,并最大程度地减少管理云基础结构的工作量,则 Microsoft Entra 域服务可能更加适合作为完全托管的域服务。 如果需要实现与 AD DS 功能完全兼容,可以考虑在 VM 上自承载域控制器,从而将 AD DS 环境扩展到云。 无论采用哪种方法,你都可以灵活选择最适合自己业务需求的域服务。
备份和灾难恢复 (DR)
如果你将主文件存储保留在本地,则 Azure 文件共享可以作为备份或灾难恢复的理想存储方式,从而提高业务连续性。 可以使用 Azure 文件共享来备份现有文件服务器中的数据,同时保留 Windows 随机访问控制列表 (DACL)。 对于灾难恢复方案,可以配置一个身份验证选项,用于支持在进行故障转移时强制执行适当的访问控制。
基于标识的身份验证的优点
将基于标识的身份验证用于 Azure 文件存储与采用共享密钥身份验证相比,具有以下几个优势:
将传统的基于标识的文件共享访问体验扩展到云
如果计划将应用程序直接迁移到云,用 Azure 文件共享替代传统的文件服务器,则可能需要让应用程序使用本地 AD DS 或 Microsoft Entra 域服务凭据进行身份验证,来访问文件数据。 Azure 文件共享支持使用本地 AD DS 或 Microsoft Entra 域服务凭据,来通过 SMB 从本地 AD DS 或 Microsoft Entra 域服务域联接的 VM 访问 Azure 文件共享。对 Azure 文件共享强制实施粒度访问控制
可以向特定标识授予共享、目录或文件级别权限。 例如,假设多个团队使用一个 Azure 文件共享进行项目协作。 你可以向所有团队授予访问非敏感目录的权限,而仅授权财务团队访问含敏感财务数据的目录。备份 Windows ACL(又称为 NTFS 权限)和数据
可使用 Azure 文件共享备份现有的本地文件共享。 将文件共享通过 SMB 备份到 Azure 文件共享时,Azure 文件存储会保留 ACL 和你的数据。
工作原理
Azure 文件共享使用 Kerberos 协议,以通过 AD 源进行身份验证。 当某个与用户或客户端上运行的应用程序关联的标识尝试访问 Azure 文件共享中的数据时,请求会发送到 AD 源来对该标识进行身份验证。 如果身份验证成功,则会返回 Kerberos 令牌。 客户端会发送一个包含 Kerberos 令牌的请求,Azure 文件共享将使用该令牌来对该请求授权。 Azure 文件共享仅接收 Kerberos 令牌,而不接收用户的访问凭据。
可以使用三个 AD 源之一在新的和现有的存储帐户上启用基于标识的身份验证:AD DS、Microsoft Entra 域服务或 Microsoft Entra Kerberos(仅限混合标识)。 只能将一个 AD 源用于存储帐户的文件访问身份验证,该验证适用于帐户中的所有文件共享。 必须先设置域环境,然后才能在存储帐户上启用基于标识的身份验证。
AD DS
对于本地 AD DS 身份验证,必须设置 AD 域控制器,并让计算机或 VM 加入域。 可以将域控制器托管在 Azure VM 或本地。 无论采用哪种方法,加入域的客户端都必须与域控制器建立不受阻碍的网络连接,因此这些客户端必须位于域服务的企业网络或虚拟网络 (VNET) 中。
下图说明了 Azure 文件共享通过 SMB 进行本地 AD DS 身份验证的过程。 必须使用 Microsoft Entra Connect 同步或 Microsoft Entra Connect 云同步将本地 AD DS 同步到 Microsoft Entra ID。对于 Azure 文件共享访问,只可以对同时位于本地 AD DS 和 Microsoft Entra ID 的混合用户标识进行身份验证和授权。 这是因为,共享级别权限是针对 Microsoft Entra ID 中的标识配置的,目录/文件级别权限是对 AD DS 中的标识强制实施的。 请务必为同一个混合用户正确配置权限。
若要了解如何启用 AD DS 身份验证,请先阅读概述 - 通过 SMB 对 Azure 文件共享进行本地 Active Directory 域服务身份验证,然后参阅为 Azure 文件共享启用 AD DS 身份验证。
Microsoft Entra 域服务
对于 Microsoft Entra 域服务身份验证,应启用 Microsoft Entra 域服务,并让计划用于访问文件数据的 VM 加入域。 已加入域的 VM 必须与 Microsoft Entra 域服务位于同一虚拟网络 (VNET) 中。
下图说明了 Azure 文件共享通过 SMB 进行 Microsoft Entra 域服务身份验证的工作流。 它遵循与本地 AD DS 身份验证类似的模式,但有两个主要区别:
无需在 Microsoft Entra 域服务中创建标识来表示存储帐户。 此过程由启用进程在后台完成。
Microsoft Entra ID 中存在的所有用户都可以进行身份验证,并获得授权。 用户可以只是云用户,也可以是混合用户。 从 Microsoft Entra ID 同步到 Microsoft Entra 域服务的同步由平台管理,无需任何用户配置。 但是,客户端必须加入 Microsoft Entra 域服务托管域。 它不能加入或注册 Microsoft Entra。 Microsoft Entra 域服务不支持将非 Azure 客户端(即用户笔记本电脑、工作站、其他云中的 VM 等)域加入 Microsoft Entra 域服务托管域。 但是,可以通过提供显式凭据(如 DOMAINNAME\username)或使用完全限定的域名 (username@FQDN),从未加入域的客户端装载文件共享。
若要了解如何启用 Microsoft Entra 域服务身份验证,请参阅在 Azure 文件存储上启用 Microsoft Entra 域服务身份验证。
用于混合标识的 Microsoft Entra Kerberos
启用和配置 Microsoft Entra ID 以对混合用户标识进行身份验证允许 Microsoft Entra 用户使用 Kerberos 身份验证访问 Azure 文件共享。 此配置使用 Microsoft Entra ID 发出必要的 Kerberos 票证,以通过行业标准 SMB 协议访问文件共享。 这意味着最终用户可以通过 Internet 访问 Azure 文件共享,而无需建立从 Microsoft Entra 混合联接和 Microsoft Entra 联接的 VM 到域控制器的连接。 但是,为用户和组配置目录和文件级权限需要与本地域控制器建立不受限制的网络连接。
重要
Microsoft Entra Kerberos 身份验证仅支持混合用户标识;它不支持仅限云的标识。 需要传统的 AD DS 部署,并且必须使用 Microsoft Entra Connect 同步或 Microsoft Entra Connect 云同步将其同步到 Microsoft Entra ID。客户端必须已加入 Microsoft Entra 或 Microsoft Entra 混合联接。 加入 Microsoft Entra 域服务或仅加入 AD 的客户端不支持 Microsoft Entra Kerberos。
若要了解如何为混合标识启用 Microsoft Entra Kerberos 身份验证,请参阅为 Azure 文件存储上的混合标识启用 Microsoft Entra Kerberos 身份验证。
还可以使用此功能将 FSLogix 配置文件存储在 Microsoft Entra 联接的 VM 的 Azure 文件共享上。 有关详细信息,请参阅使用 Azure 文件存储和 Microsoft Entra ID 创建配置文件容器。
访问控制
Azure 文件存储强制授予共享级别和目录/文件级别的用户访问权限。 可以对通过 Azure RBAC 管理的 Microsoft Entra 用户或组执行共享级别权限分配。 对于 Azure RBAC,用于访问文件的凭据应该可用于或同步到 Microsoft Entra ID。 可以将“存储文件数据 SMB 共享读取者”等 Azure 内置角色分配给 Microsoft Entra ID 中的用户或组,以授予对 Azure 文件共享的访问权限。
在目录/文件级别,Azure 文件存储支持预留、继承和强制执行 Windows ACL,就像任何 Windows 文件服务器一样。 在现有文件共享和 Azure 文件共享之间通过 SMB 复制数据时,可以选择保留 Windows ACL。 无论你是否打算强制执行授权,都可以使用 Azure 文件共享来备份 ACL 和数据。
为 Azure 文件配置共享级别权限
在存储帐户上启用 AD 源后,必须执行下列操作之一来访问文件共享:
- 设置适用于所有经过身份验证的用户和组的默认共享级别权限
- 将内置 Azure RBAC 角色分配给用户和组,或者
- 为 Microsoft Entra 标识配置自定义角色,并分配对存储帐户中的文件共享的访问权限。
使用分配的共享级别权限,已获授权的标识就会只获得相应共享的访问权限,没有其他权限,甚至没有对根目录的访问权限。 你仍需单独配置目录级别和文件级别的权限。
配置对 Azure 文件存储目录级别或文件级别的权限
Azure 文件共享在目录级别和文件级别(包括根目录)强制实施标准 Windows ACL。 支持通过 SMB 和 REST 配置目录级别或文件级别权限。 请从 VM 装载目标文件共享,并使用 Windows 资源管理器、Windows icacls 或 Set-ACL 命令配置权限。
使用存储帐户密钥获取超级用户权限
拥有存储帐户密钥的用户可使用超级用户权限访问 Azure 文件共享。 超级用户权限可绕过所有访问控制限制。
重要
为保证安全性,建议采用以下最佳做法:避免共享存储帐户密钥,并尽可能利用基于标识的身份验证。
将数据导入 Azure 文件共享时保留目录和文件 ACL
将数据复制到 Azure 文件共享时,Azure 文件存储支持保留目录级别或文件级别 ACL。 可以使用 Azure 文件同步或常见的文件移动工具集,将目录或文件上的 ACL 复制到 Azure 文件共享。 例如,可使用带 /copy:s
标志的 robocopy 将数据和 ACL 复制到 Azure 文件共享。 默认情况下,系统会保留 ACL,因此你无需在存储帐户上启用基于标识的身份验证来保留 ACL。
定价
在存储帐户上启用通过 SMB 进行的基于标识的身份验证无需支付额外的服务费。 有关定价的详细信息,请参阅 Azure 文件存储定价和 Microsoft Entra 域服务定价。
后续步骤
有关 Azure 文件存储和通过 SMB 进行基于标识的身份验证的详细信息,请参阅以下资源: