FSLogix 仅云标识与外部标识：Azure Virtual Desktop 配置指南

如果您一直在等待淘汰那些仅为了让 Azure Virtual Desktop 用户加载 FSLogix 配置文件而存在的域控制器，那么障碍已经消除。自 2026 年 5 月起，面向仅云标识和外部标识的 FSLogix 配置文件容器已正式发布（GA），整个技术栈可以完全由 Microsoft Entra 加入的会话主机、使用 Microsoft Entra Kerberos 进行身份验证的 Azure Files，以及从未拥有过 Active Directory 帐户的用户组成。GA 公告发布时我写过它意味着什么；本指南则是我现在交给想要实际构建它的团队的分步说明，包括那些容易让人跌倒的部分：应用清单标记、无法使用 icacls 时的目录权限模型，以及条件访问排除项。下面的每一个设置路径和值均来自 2026 年 10 月的 Microsoft Learn。

AVD 会话主机的标识模型

Azure Virtual Desktop 加入会话主机有四种实际方式，而标识模型决定了 FSLogix 可以向什么进行身份验证。Microsoft 的标识和身份验证文章明确指出，仅存在于 AD DS 中的用户完全不受支持；每个 AVD 用户都必须能够通过 Microsoft Entra ID 被发现。

过去的问题出在第四行。Entra 加入的主机多年来一直受支持，但 FSLogix 需要 Kerberos 票证才能装载 SMB 共享，而只有 AD DS 或 Entra Domain Services 能够颁发。Entra Kerberos 首先为混合标识填补了这一空白，因为 Entra ID 可以代表已同步的本地帐户颁发票证。仅云帐户背后没有本地帐户可依托，因此只能得到本地或临时配置文件。

仅云 FSLogix 的含义

Microsoft Entra Kerberos 将租户变成了 Kerberos 密钥分发中心（KDC）。当用户登录到 Entra 加入的设备时，Entra ID 会颁发主刷新令牌（PRT），并同时颁发领域为 KERBEROS.MICROSOFTONLINE.COM 的云票证授予票证（Cloud TGT）。对于访问 Azure Files 的仅云用户，Entra Kerberos 概述描述了该流程：SMB 客户端为 cifs/<storageaccount>.file.core.windows.net 请求服务票证，Entra Kerberos 基于 Cloud TGT 颁发包含用户标识和组声明的票证，然后由 Azure Files 验证。整个过程不涉及任何本地 KDC。

时间线对支持对话很重要：

• 2025 年 9 月：AVD 对外部标识的支持进入预览，并明确不支持 FSLogix。
• 2025 年 11 月：外部标识正式发布，面向仅云标识和外部标识的 FSLogix 进入预览。
• 2026 年 5 月：面向仅云标识和外部标识的 FSLogix 支持正式发布。AVD 新增功能条目指出，该功能“已内置于现有版本的 FSLogix 中”。

最后一句回答了我最常被问到的问题。并不存在某个引入仅云支持的 FSLogix 版本号；真正的支撑工作发生在 Entra Kerberos、Azure Files 和 Windows 中。Microsoft 的发行说明确实要求运行最新版本，而当前版本 FSLogix 26.08（3.26.826.17182，2026 年 8 月 31 日发布）尤其值得安装，因为它有一项功能：在会话期间以及 VHD 重新附加时，在后台刷新用户的云 Kerberos 票证。Microsoft 指出这并不改变 10 小时的票证生存期，但它缓解了过去长会话后必须注销才能解决的存储访问故障。

外部标识支持涵盖的范围及其限制

外部标识是您邀请到员工租户中的 B2B 用户。就 FSLogix 而言，Azure Files Entra Kerberos 文章划定了边界：Azure Files SMB 对外部标识的支持仅限于 Azure Virtual Desktop 上的 FSLogix 场景，适用于被邀请到公有云租户的用户，不包括跨云用户（从 Azure Government 或 21Vianet 邀请的用户），且在政府云中不受支持。Entra Kerberos 也不支持跨租户访问；进行身份验证的是您租户中的来宾对象。外部标识无法在会话中使用 Kerberos 或 NTLM 向本地资源进行身份验证，分配给来宾的 Intune 设备配置策略也不会应用；您需要将这些策略分配给设备。

先决条件

表中有两个细节经常让人踩坑。仅云支持仅限公有云；混合方式可在 Azure Government 和 21Vianet 中使用，但仅云方式不行。此外，外部标识的操作系统门槛与仅云的门槛并不相同：如果来宾将共用该主机池，请在选择映像之前核对两份列表。

第 1 步：存储帐户和文件共享

创建存储帐户和用于配置文件的 SMB 文件共享。FSLogix 操作指南中有一条规则不可妥协：存储帐户不能同时使用 Entra ID 和第二种方法（例如 AD DS 或 Entra Domain Services）进行身份验证。如果要复用曾加入 AD DS 的帐户，请先更改标识源，并检查现有 ACL，因为它们是针对本地 SID 编写的。

请将配置文件共享放在独立的存储帐户上。第 2 步中的条件访问排除项适用于代表整个帐户的应用，您不希望通用数据搭上这一豁免的便车。

第 2 步：在存储帐户上启用 Microsoft Entra Kerberos

在 Azure 门户中打开存储帐户，然后依次选择 Data storage > Classic file shares，选择 Identity-based access 旁的状态，在 Microsoft Entra Kerberos 下选择 Set up，勾选 Microsoft Entra Kerberos 复选框并选择 Save。跳过域名和 GUID 字段；它们是为希望用文件资源管理器编辑 ACL 的混合标识准备的，而这对仅云标识本就不受支持。

Set-AzStorageAccount -ResourceGroupName <resourceGroupName> -StorageAccountName <storageAccountName> -EnableAzureActiveDirectoryKerberosForFile $true

az storage account update --name <storageaccountname> --resource-group <resourcegroupname> --enable-files-aadkerb true

启用该功能会自动创建名为 [Storage Account] .file.core.windows.net 的应用注册。必须对该应用执行三件事，漏掉任何一件都会导致配置文件静默回退到本地。

授予管理员同意。在 Microsoft Entra ID > App registrations > All Applications 中打开存储应用，选择 API permissions，然后为三个请求的权限（openid、profile 和 User.Read）选择 Grant admin consent for [Directory Name]。不要更改此服务主体上的任何其他内容；Microsoft 表示超出文档范围的编辑可能会破坏它。

添加云组标记。Kerberos 票证最多承载 1,010 个组 SID，而有了仅云支持后，票证必须包含云组 SID。Microsoft 将此步骤标记为仅云标识必需：打开应用的 Manifest，找到 tags 数组并添加 "kdc_enable_cloud_group_sids"，然后保存。或者通过 Graph PowerShell：

Connect-MgGraph -Scopes "Application.ReadWrite.All" -TenantId <tenantId>
Update-MgApplication -ApplicationId "<AppObjectId>" -Tags @("kdc_enable_cloud_group_sids")

有效成员身份仍超过 1,010 个 SID 的用户会在服务票证阶段失败，登录日志显示错误 140011 KerberosUsersGroupNumberExceeded；解决办法是减少这些帐户的嵌套组和动态组成员身份。

将应用从 MFA 中排除。Entra Kerberos 没有用户界面来在配置文件加载期间完成升级验证提示。每一条要求 MFA 且面向所有资源的条件访问策略都必须排除存储应用。如果遗漏此项，装载共享时会返回“System error 1327: Account restrictions are preventing this user from signing in.”。还要检查应用程序管理策略：阻止添加对称密钥或将密钥生存期限制在 366 天以内的策略，需要为 Storage Resource Provider 服务（应用 ID a6aa9161-5291-40bb-8c5c-923b567bee3b）设置例外，否则启用 Entra Kerberos 会因 Graph 返回 BadRequest 而失败。

如果通过专用终结点访问共享，请将 <storageaccount>.privatelink.file.core.windows.net 条目添加到应用的 identifierUris 中，否则客户端会回退到 NTLM 并以错误 1326 失败。

第 3 步：共享级 RBAC

共享级访问就是 Azure RBAC，而对于仅云标识，Microsoft 的文档指出，仅在使用 Entra Kerberos 时才支持分配特定 RBAC 角色，且在所有公有区域可用。相关的内置角色包括：

FSLogix 存储权限指南建议将默认共享级权限设置为面向所有已验证标识的 Storage File Data SMB Share Contributor，并为管理员组授予 Storage File Data SMB Share Elevated Contributor 以便管理 ACL。在门户中的路径是 Classic file shares > Identity-based access > Step 2: Set share-level permissions > Enable permissions for all authenticated users and groups。如果您偏好显式分配，请将角色的范围限定到共享：

$scope = "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>/fileServices/default/fileshares/<share-name>"
New-AzRoleAssignment -SignInName <user-principal-name> -RoleDefinitionName "Storage File Data SMB Share Contributor" -Scope $scope

角色分配通常在 30 分钟内生效。当默认权限和显式分配同时适用时，以较高的权限为准。

第 4 步：不依赖 NTFS 工具的目录权限

这是仅云方式与 AVD 管理员熟知做法差异最大的地方。目录和文件级权限文章提供了一张工具矩阵，对于使用仅云标识的 Microsoft Entra Kerberos，Windows 文件资源管理器和 icacls 均被标记为不受支持。您的两个选项是 Azure 门户和 RestSetAcls PowerShell 模块，二者都不需要域控制器。

在门户中，打开文件共享，选择 Browse，然后使用顶部菜单中的 Manage access 设置根 ACL，或右键单击某个目录并选择 Manage access。FSLogix 操作指南将此选项卡称为仅云和外部标识用户的推荐选项。拒绝始终优先于允许，而可继承的更改仅适用于将来的项目，因此请在第一个用户登录之前设置好根 ACL。

使用 PowerShell 时，文档中的模式如下：

Install-Module RestSetAcls
$context = New-AzStorageContext -StorageAccountName "<storage-account-name>" -StorageAccountKey "<storage-account-key>"
Add-AzFileAce -Context $context -FileShareName <share-name> -FilePath "/" -Type Allow -Principal "testUser@contoso.com" -AccessRights Read,Synchronize -InheritanceFlags ObjectInherit,ContainerInherit

权限模型本身与任何 FSLogix 共享相同。Microsoft 推荐的 ACL 是：CREATOR OWNER 对“仅子文件夹和文件”拥有修改权限，管理员组对“此文件夹、子文件夹和文件”拥有完全控制权限，用户组对“仅此文件夹”拥有修改权限。新建的 Azure 文件共享根目录已经授予 NT AUTHORITY\Authenticated Users 可继承的修改权限，以及 CREATOR OWNER 对子对象的完全控制权限，这比推荐模型更宽松，但足以用于试点。共享级 RBAC 和 Windows ACL 都会强制执行，以最严格者为准，因此共享级别的 Reader 即便拥有文件夹的完全控制权限也无法写入。

如果需要在创建配置文件文件夹时就设置 ACL 而不借助任何工具，FSLogix 的 SIDDirSDDL 设置接受带有 %sid% 占位符的 SDDL 字符串，并在创建用户目录时应用。

第 5 步：会话主机配置

每台会话主机上有三个注册表区域：必须允许 Windows 检索云 Kerberos 票证，Entra 凭据密钥必须随配置文件漫游，并且 FSLogix 必须指向共享。请将这些内容烘焙到映像中，或通过 Intune 下发。

云 Kerberos 票证检索。使用 Intune 设置目录中的 Kerberos > CloudKerberosTicketRetrievalEnabled 设置并设为 Enabled。Microsoft 特别指出要使用设置目录而不是自定义 OMA-URI，因为 OMA-URI 方法在多会话主机上不起作用。组策略的等效项为 Administrative Templates > System > Kerberos > Allow retrieving the Azure AD Kerberos Ticket Granting Ticket during logon（旧版本中标注为“Allow retrieving the cloud kerberos ticket during the logon”）。注册表形式：

reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1

需要重新启动或刷新策略。设置后，除非添加主机到领域的映射，否则主机将无法再访问使用 AD DS 身份验证的存储帐户；如果两者并存，请为每个 AD DS 帐户配置 Define host name-to-Kerberos realm mappings 或 ksetup /addhosttorealmmap <storageaccount>.file.core.windows.net <REALM>。

凭据密钥漫游。让凭据管理器中的密钥属于正在加载的配置文件，而不是用户首次接触的那台主机：

reg add HKLM\Software\Policies\Microsoft\AzureADAccount /v LoadCredKeyFromProfile /t REG_DWORD /d 1

FSLogix 设置。在 HKLM\SOFTWARE\FSLogix\Profiles 下，Microsoft 的配置配置文件容器指南如下：

$VHDLocations = "\\<storage-account>.file.core.windows.net\<share>"
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name Enabled -PropertyType dword -Value 1 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name VHDLocations -PropertyType string -Value $VHDLocations -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name DeleteLocalProfileWhenVHDShouldApply -PropertyType dword -Value 1 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name FlipFlopProfileDirectoryName -PropertyType dword -Value 1 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name VolumeType -PropertyType string -Value vhdx -Force

将 RoamIdentity 保留为默认值 0；Microsoft 不建议使用旧式标识漫游，且 26.01 版本已更新默认标识排除项以匹配 Entra 设备标识指南。日志位于 HKLM\SOFTWARE\FSLogix\Logging 下；LoggingEnabled 默认为 2（启用所有日志），LogFileKeepingPeriod 默认为 2 天，我在试点期间会调高该值。

第 6 步：主机池 RDP 属性和单一登录

仅云用户可以用用户名和密码登录 Entra 加入的主机，但外部标识必须使用单一登录，而且 SSO 对所有人都是正确的默认选择，因为它将无密码身份验证和第三方联合身份验证一路带入会话。SSO 配置包含五项任务：

1. 在 Windows Cloud Login 服务主体（应用 ID 270efc09-cd0d-444b-a71f-39af4910ec45）上为 RDP 启用 Entra 身份验证。门户路径：Microsoft Entra ID > Devices > Remote connection configuration > Windows Cloud Login，然后启用 Entra ID 身份验证协议。在 PowerShell 中，将其 remoteDesktopSecurityConfiguration 上的 isRemoteDesktopProtocolEnabled 设为 true。
2. 通过在 Target device groups to enable SSO 下添加会话主机的动态设备组（最多 10 个组）来隐藏同意提示。否则，用户会被要求允许连接，而 Entra 会在 30 天内记住 15 台主机。
3. 仅当 AD DS 是您环境的一部分时才创建 Kerberos 服务器对象。在纯仅云构建中没有 AD DS，因此此步骤不适用。
4. 审查条件访问（第 7 步）。
5. 在主机池上，将 RDP 属性 Microsoft Entra single sign-on 设置为 Connections will use Microsoft Entra authentication to provide single sign-on，在 PowerShell 中即 enablerdsaadauth:i:1。

RDP 属性参考将 enablerdsaadauth（默认 0）记录为 targetisaadjoined 的替代项。旧的 targetisaadjoined:i:1 仍然适用于非 Windows 客户端以及未加入 Entra、未混合加入或未注册的 Windows 设备，但它将连接限制为用户名和密码，这就排除了无密码和外部标识。如果以前的部署中设置了它，请在启用 SSO 时移除。

对于没有会话主机配置的主机池，还需在资源组级别将 Virtual Machine User Login 角色分配给与应用程序组相同的用户组，否则用户会通过代理身份验证却被 VM 拒绝。使用会话主机配置的主机池不需要此分配。

第 7 步：条件访问注意事项

Microsoft 的 AVD MFA 指南现在建议使用两条对齐的策略而非一条：策略 1 针对 Azure Virtual Desktop 应用（9cdead84-a844-4324-93f2-b2e6bb768d07），用于源和网关身份验证；策略 2 针对 Windows Cloud Login，用于会话主机登录。两者都要求 MFA；Every time 登录频率仅在 Windows Cloud Login 上受支持。频率不一致会导致会话中途出现提示。

在仅云 FSLogix 主机池上，排除项与包含项同样重要：

• 将 [Storage Account] .file.core.windows.net 从任何 MFA 策略中排除（第 2 步）。
• 切勿将 Azure Virtual Desktop Azure Resource Manager Provider 应用（50e95039-b200-4007-bc97-8d5790743a63）添加到策略中；它仅用于检索源。
• 不要阻止 Windows 365 应用（0af06dc6-e4b5-4f28-818e-e78e62d137a5）；即使用户只有 AVD 资源，Windows App 也会向它进行身份验证。
• 检查任何针对所有资源要求设备合规性的策略。Entra 加入的会话主机可能无法满足为用户终结点编写的合规性策略。
• 为 AVD 用户禁用旧式的每用户 MFA。若与条件访问同时启用，Entra 加入的主机会返回“The sign-in method you’re trying to use isn’t allowed”。
• 如果不将登录限制为 Windows Hello 企业版等强方法，请按 Entra 加入的主机文章所述排除 Azure Windows VM Sign-In 应用。

条件访问需要 Entra ID P1 或 P2，且不能与安全默认值共存。这也是 2026 年 5 月“默认无密码”变更的交汇点；我在 Entra ID 默认无密码与治理融合中介绍过这些内容，值得与本文一起阅读，因为启用 SSO 的 Entra 加入 AVD 主机池正是通行密钥和 Windows Hello 企业版能够一路贯通到桌面的环境。

外部标识：同一主机池上的来宾

邀请承包商就是普通的 B2B 操作：在 Entra 管理中心，以至少 User Administrator 的身份转到 Microsoft Entra ID > Users > New user > Invite external user，输入其电子邮件和显示名称，并在 Assignments 选项卡中将其添加到您的 AVD 用户组。来宾在您的目录中显示为 emailaddress#EXT#@yourtenant.onmicrosoft.com，用户类型为来宾，且必须先兑换邀请，其他一切才会生效。

此后，来宾与组中的任何其他成员一样对待：应用程序组分配、Virtual Machine User Login 角色、共享级 RBAC 和目录 ACL 都来自组成员身份。第一个来宾登录前需要核对的事项：

1. 主机的操作系统版本。Windows 11 企业版 24H2 或更高版本且安装 KB5065789 或更高，或 Windows Server 2025 且安装 KB5073379 或更高。Microsoft 明确表示，外部标识的操作系统要求比仅云用户更严格。
2. 已启用 SSO。外部标识不能使用旧式用户名加密码路径；必须设置 enablerdsaadauth:i:1。
3. 客户端。Windows、macOS、iOS、Android 上的 Windows App 或浏览器。在 iOS 和 Android 上，唯一支持的社交提供程序是在 Authenticator 中配置为已连接帐户的 Microsoft 帐户。不支持一次性密码登录。
4. 许可。Microsoft 的许可指南指出，来宾主租户中的许可证不会赋予其在您租户中的 AVD 权限；请购买与员工同类的许可证（例如 Microsoft 365 E3）并分配给您租户中的来宾对象。每用户访问定价面向外部商业用途（例如销售 SaaS 应用），Microsoft 明确表示它不是启用来宾帐户的方式。
5. Microsoft 365 应用。仅当被邀请的帐户拥有 Microsoft 365 Apps 许可证且其主租户的条件访问未阻止时，桌面应用才能登录；否则来宾在会话浏览器中使用 Web 应用。
6. 云边界。AVD 侧支持公有云和 Azure for US Government，但 FSLogix 和 Azure Files 侧仅限公有云，且不支持跨云邀请。

来宾在共享上获得与成员相同的 %username%_%sid% 文件夹，这正是 GA 的意义所在：一个池化主机池，一种配置文件模型，内部和外部用户并肩而行。

验证

以从未登录过的测试用户身份登录（或设置 DeleteLocalProfileWhenVHDShouldApply），然后：

• 在主机上运行 C:\Program Files\FSLogix\Apps\frx.exe list-redirects；第一行应将 \Users\<user> 映射到已装载容器上的 \Device\HarddiskVolumeN\Profile。
• 在门户中打开文件共享，确认存在名为 <username>_<SID>（未启用 FlipFlop 时为 <SID>_<username>）的目录，其中包含 Profile_<username>.vhdx。
• 在会话中，klist cloud_debug 显示 Cloud TGT，dsregcmd /status 报告 CloudTgt : YES。
• 检查 HKLM\Software\FSLogix\Profiles\Sessions<SID> 中的 Status 为 0 且 Reason 为 0（容器已附加）。
• 在 Microsoft Entra ID > Monitoring & health > Sign-in logs 中按用户筛选：Azure Virtual Desktop 和 Windows Cloud Login 条目都应显示成功，并应用了预期的条件访问策略。任何失败条目都会告诉您是哪条策略阻止了它。

故障排除

先看文本日志。FSLogix 写入 C:\ProgramData\FSLogix\Logs\Profile\Profile_<date>.log；搜索 LoadProfile: <username>，跟踪线程 ID，并阅读所有 [ERROR:xxxxxxxx] 行。八位代码是 Windows 系统错误，可用 net helpmsg <decimal> 解码。事件查看器中有 Applications and Services Logs > FSLogix > Apps > Admin 和 Operational。FSLogix 支持工具可将所有内容打包以供提交案例。

对于存储侧诊断，AzFilesHybrid 模块（0.3.0 或更高版本）中的 Debug-AzStorageAccountAuth 会运行 Entra Kerberos 检查：端口 445、Entra 连接性、Entra 对象和 SPN、CloudKerberosTicketRetrieval 键、领域映射、管理员同意、两个必需服务、Fiddler 代理以及加入类型。

何时仍应选择 AD 加入的存储

我不会仅仅因为可行就把混合环境迁移到 Entra Kerberos 存储。在以下情况下，请在配置文件共享上保留 AD DS 或 Entra Domain Services 身份验证：

• 用户需要在会话内通过 Kerberos 或 NTLM 访问本地文件服务器、打印服务器或集成身份验证的 Web 应用；外部标识完全做不到这一点，而仅云用户没有本地帐户。
• 您运行在 Azure Government 或 21Vianet 中，这些环境不支持仅云 Entra Kerberos。
• 您的标识是混合标识，且工具链是 icacls、保留 ACL 的 Robocopy 或 Azure File Sync；混合路径可保留所有这些。
• 会话时长经常超过 10 小时，而您尚无法统一到 FSLogix 26.08；混合加入的客户端可以使用仅 Entra 客户端无法使用的云信任缓解措施。

Azure Files 上的混合 FSLogix 仍然完全受支持，GA 中没有任何内容强制迁移。

应采取的行动

1. 按标识类型清点用户：混合、仅云、来宾。目前没有持久配置文件的仅云用户和来宾是首批候选对象。
2. 将试点映像修补或重建为 Windows 11 24H2 并安装 KB5079391 或更高版本（若来宾也会使用则为 KB5065789 或更高版本），并安装 FSLogix 26.08。
3. 创建专用存储帐户和共享，启用 Entra Kerberos，授予管理员同意，添加 kdc_enable_cloud_group_sids，并将存储应用从 MFA 策略中排除。
4. 将默认共享级权限设置为 Storage File Data SMB Share Contributor，为管理员授予 Elevated Contributor，并使用 Manage access 设置根 ACL。
5. 通过 Intune 设置目录推送 CloudKerberosTicketRetrievalEnabled、LoadCredKeyFromProfile 以及 FSLogix 注册表值。
6. 在主机池上启用 SSO（enablerdsaadauth:i:1），配置 Windows Cloud Login，并移除旧指南遗留的任何 targetisaadjoined:i:1。
7. 构建两条条件访问策略，确认排除项，并禁用每用户 MFA。
8. 让一名仅云试点用户完成登录，用 frx.exe list-redirects 验证容器，然后换成来宾重复一遍。
9. 之后再重新审视域控制器退役计划，并为仍需本地 Kerberos 的任何内容保留混合共享。

我在 AVD 新增功能系列中跟踪所有这些内容的每月变化。

需要帮手？Big Hat Group 为美国和加拿大的组织提供 Azure Virtual Desktop 架构咨询服务，从标识与 FSLogix 健康检查到完整的仅 Entra 主机池构建。预约探索通话，一起梳理您的环境。

来源

• 使用 Microsoft Entra ID 在 Azure Files 上存储 FSLogix 配置文件容器
• Azure Files 的 Microsoft Entra Kerberos 身份验证
• 为 Azure Files 分配共享级权限
• 为 Azure Files 配置目录和文件级权限
• 配置 SMB 存储权限（FSLogix）
• 配置配置文件容器（FSLogix）
• FSLogix 配置设置参考
• FSLogix 发行说明
• 使用日志记录和诊断进行 FSLogix 故障排除
• FSLogix 代码及其含义
• Microsoft Entra Kerberos 简介
• Azure Files 基于标识的身份验证故障排除（SMB）
• Azure Virtual Desktop 标识和身份验证
• Azure Virtual Desktop 中 Microsoft Entra 加入的会话主机
• 使用 Microsoft Entra ID 为 Azure Virtual Desktop 配置单一登录
• 支持的 RDP 属性
• 使用条件访问为 Azure Virtual Desktop 强制执行 Microsoft Entra 多重身份验证
• Azure Virtual Desktop 许可
• 在 Microsoft Entra 管理中心添加 B2B 协作用户
• Azure Virtual Desktop 的新增功能