FSLogix クラウド専用 ID と外部 ID：AVD セットアップ ガイド

Azure Virtual Desktop のユーザーが FSLogix プロファイルを読み込むためだけに存在しているドメイン コントローラーの廃止を待っていたなら、その障壁はなくなりました。2026 年 5 月以降、クラウド専用 ID と外部 ID 向けの FSLogix プロファイル コンテナーは一般提供（GA）となり、スタック全体を Microsoft Entra 参加済みセッション ホスト、Microsoft Entra Kerberos で認証する Azure Files、そして Active Directory アカウントを一度も持ったことのないユーザーで構成できます。GA が発表されたとき、私はこの発表が意味することを書きました。本ガイドは、実際に構築したいチームに私が今渡している手順書で、つまずきやすい部分、つまりアプリ マニフェストのタグ、icacls が使えないときのディレクトリ アクセス許可モデル、条件付きアクセスの除外設定も含みます。以下のすべての設定パスと値は 2026 年 10 月時点の Microsoft Learn に基づいています。

AVD セッション ホストの ID モデル

Azure Virtual Desktop でセッション ホストを参加させる実務的な方法は 4 つあり、ID モデルによって FSLogix が何に対して認証できるかが決まります。Microsoft のID と認証の記事は、AD DS にのみ存在するユーザーはまったくサポートされないと明記しています。すべての AVD ユーザーは Microsoft Entra ID を通じて検出可能でなければなりません。

歴史的に問題は 4 行目でした。Entra 参加済みホストは何年もサポートされてきましたが、FSLogix が SMB 共有をマウントするには Kerberos チケットが必要で、それを発行できるのは AD DS か Entra Domain Services だけでした。Entra Kerberos はまずハイブリッド ID のためにこのギャップを埋めました。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 からユーザー ID とグループ クレームを含むチケットを発行し、Azure Files がそれを検証します。オンプレミスの KDC は一切関与しません。

サポートの会話ではタイムラインが重要です。

• 2025 年 9 月：AVD の外部 ID サポートがプレビューに入り、FSLogix は明示的に対象外でした。
• 2025 年 11 月：外部 ID が GA となり、クラウド専用 ID と外部 ID 向けの FSLogix がプレビューに入りました。
• 2026 年 5 月：クラウド専用 ID と外部 ID 向けの FSLogix サポートが一般提供になりました。AVD の新機能のエントリには、この機能は「既存バージョンの FSLogix に既に組み込まれている」と記載されています。

この最後の一文が、私が最もよく受ける質問への答えです。クラウド専用サポートを導入した FSLogix のビルド番号は存在しません。実現のための作業は Entra Kerberos、Azure Files、Windows 側で行われました。Microsoft のリリース ノートは最新バージョンの実行を求めており、現行リリースの FSLogix 26.08（3.26.826.17182、2026 年 8 月 31 日公開）は特にある機能のためにインストールする価値があります。セッション中および VHD の再アタッチ時に、ユーザーのクラウド Kerberos チケットをバックグラウンドで更新するのです。Microsoft はこれが 10 時間のチケット有効期間を変えるものではないと注記していますが、長時間セッションの後にサインアウトが必要だったストレージ アクセス障害を緩和します。

外部 ID サポートの範囲と制限

外部 ID とは、従業員テナントに招待する B2B ユーザーです。FSLogix の観点では、Azure Files Entra Kerberos の記事が境界を定めています。外部 ID に対する Azure Files SMB サポートは Azure Virtual Desktop 上の FSLogix シナリオに限定され、パブリック クラウドのテナントに招待されたユーザーに適用され、クロスクラウド ユーザー（Azure Government や 21Vianet から招待されたユーザー）は除外され、政府向けクラウドではサポートされません。Entra Kerberos はクロステナント アクセスもサポートしません。認証するのはあなたのテナント内のゲスト オブジェクトです。外部 ID はセッション内から Kerberos や NTLM でオンプレミス リソースに認証できず、ゲストに割り当てた Intune デバイス構成ポリシーは適用されません。代わりにデバイスに割り当てます。

前提条件

この表には引っかかりやすい点が 2 つあります。クラウド専用サポートはパブリック クラウドのみです。ハイブリッド方式は Azure Government と 21Vianet で動作しますが、クラウド専用方式は動作しません。また、外部 ID の OS 要件はクラウド専用の要件と異なります。ゲストがプールを共用するなら、イメージを選ぶ前に両方のリストを確認してください。

手順 1：ストレージ アカウントとファイル共有

ストレージ アカウントと、プロファイル用の SMB ファイル共有を作成します。FSLogix のハウツーにある譲れないルールが 1 つあります。ストレージ アカウントは Entra ID と、AD DS や Entra Domain Services などの第 2 の方法の両方で認証することはできません。以前 AD DS に参加していたアカウントを再利用するなら、まず ID ソースを変更し、オンプレミスの SID に対して書かれた既存の ACL を見直してください。

プロファイル共有は専用のストレージ アカウントに置いてください。手順 2 の条件付きアクセスの除外はアカウント全体を表すアプリに適用されるため、汎用データをその例外に相乗りさせたくはないはずです。

手順 2：ストレージ アカウントで Microsoft Entra Kerberos を有効にする

Azure portal でストレージ アカウントを開き、Data storage > Classic file shares を選び、Identity-based access の横のステータスを選択し、Microsoft Entra Kerberos の下の Set up を選び、Microsoft Entra Kerberos チェックボックスをオンにして Save します。ドメイン名と GUID のフィールドはスキップします。これらはエクスプローラーで ACL を編集したいハイブリッド ID のためのもので、クラウド専用 ID ではいずれにせよサポートされません。

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 という名前のアプリの登録が自動作成されます。このアプリに対して 3 つの作業が必要で、どれか 1 つでも省くとプロファイルは静かにローカルへフォールバックします。

管理者の同意を付与する。Microsoft Entra ID > App registrations > All Applications でストレージ アプリを開き、API permissions を選び、要求されている 3 つのアクセス許可（openid、profile、User.Read）に対して Grant admin consent for [Directory Name] を選びます。このサービス プリンシパルの他の設定は変更しないでください。Microsoft は、文書化されていない編集は動作を壊す可能性があると述べています。

クラウド グループ タグを追加する。Kerberos チケットが運べるグループ SID は最大 1,010 個で、クラウド専用サポートによりチケットにはクラウド グループの SID も含める必要があります。Microsoft はこの手順をクラウド専用 ID では必須としています。アプリの 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 であり、クラウド専用 ID について Microsoft は、特定の RBAC ロールの割り当ては Entra Kerberos でのみサポートされ、すべてのパブリック リージョンで利用できると記載しています。関連する組み込みロールは次のとおりです。

FSLogix ストレージ アクセス許可のガイダンスは、既定の共有レベル アクセス許可をすべての認証済み ID に対して Storage File Data SMB Share Contributor に設定し、管理者グループには ACL を管理できるように Storage File Data SMB Share Elevated Contributor を付与することを推奨しています。ポータルでは 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 管理者の知る方式との最大の違いです。ディレクトリとファイル レベルのアクセス許可の記事にはツール マトリックスがあり、クラウド専用 ID の Microsoft Entra Kerberos では Windows エクスプローラーと icacls の両方がサポート対象外と記されています。選択肢は Azure portal と RestSetAcls PowerShell モジュールの 2 つで、どちらもドメイン コントローラーを必要としません。

ポータルではファイル共有を開き、Browse を選択し、上部メニューの Manage access でルート ACL を設定するか、ディレクトリを右クリックして Manage access を選びます。FSLogix のハウツーは、このタブをクラウド専用および外部 ID ユーザーの推奨オプションと呼んでいます。拒否は常に許可に勝ち、継承可能な変更は今後の項目にのみ適用されるため、最初のユーザーがサインインする前にルート 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：セッション ホストの構成

すべてのセッション ホストで 3 つのレジストリ領域を設定します。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 は従来の ID ローミングを推奨しておらず、26.01 リリースでは Entra デバイス ID ガイダンスに合わせて既定の ID 除外が更新されました。ログは HKLM\SOFTWARE\FSLogix\Logging の下にあり、LoggingEnabled の既定値は 2（すべてのログを有効）、LogFileKeepingPeriod の既定値は 2 日で、私はパイロット中はこれを引き上げます。

手順 6：ホスト プールの RDP プロパティとシングル サインオン

クラウド専用ユーザーはユーザー名とパスワードで Entra 参加済みホストにサインインできますが、外部 ID にはシングル サインオンが必須です。そして SSO は全員にとって正しい既定値です。パスワードレス認証とサードパーティ フェデレーションをセッションまで持ち込めるからです。SSO の構成には 5 つのタスクがあります。

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 は 15 台のホストを 30 日間記憶します。
3. Kerberos サーバー オブジェクトは、AD DS が環境の一部である場合にのみ作成します。純粋なクラウド専用構成には 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 デバイス向けにまだ存在しますが、接続をユーザー名とパスワードに限定するため、パスワードレスと外部 ID は使えなくなります。以前の展開で設定している場合は、SSO を有効にするときに削除してください。

セッション ホスト構成を使わないホスト プールでは、アプリケーション グループに割り当てたのと同じユーザー グループに、リソース グループ レベルで Virtual Machine User Login ロールも割り当てます。そうしないと、ユーザーはブローカーには認証できても VM に拒否されます。セッション ホスト構成を使うホスト プールではこの割り当ては不要です。

手順 7：条件付きアクセスの考慮事項

Microsoft の AVD 向け MFA ガイダンスは現在、1 つではなく整合した 2 つのポリシーを推奨しています。ポリシー 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）をブロックしないでください。Windows App は AVD のみのユーザーでもこのアプリに認証します。
• すべてのリソースに対してデバイス コンプライアンスを要求するポリシーを確認します。Entra 参加済みセッション ホストは、ユーザー エンドポイント向けに書かれたコンプライアンス ポリシーを満たさない可能性があります。
• AVD ユーザーについて従来のユーザー単位 MFA を無効にします。条件付きアクセスと併せて有効になっていると、Entra 参加済みホストは「The sign-in method you’re trying to use isn’t allowed」を返します。
• Windows Hello for Business などの強力な方法にサインインを限定しない場合は、Entra 参加済みホストの記事の説明どおり Azure Windows VM Sign-In アプリを除外します。

条件付きアクセスには Entra ID P1 または P2 が必要で、セキュリティの既定値群とは共存できません。ここは 2026 年 5 月のパスワードレス既定化の変更と交差する場所でもあります。私は Entra ID のパスワードレス既定化とガバナンスの統合でこれを取り上げており、本記事と併せて読む価値があります。SSO を有効にした Entra 参加済み AVD プールは、パスキーと Windows Hello for Business がデスクトップまで流れる環境そのものだからです。

外部 ID：同じホスト プール上のゲスト

請負業者の招待は通常の 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. ホストの OS ビルド。KB5065789 以降を適用した Windows 11 Enterprise 24H2 以降、または KB5073379 以降を適用した Windows Server 2025。Microsoft は、外部 ID はクラウド専用ユーザーより厳しい OS 要件があると明記しています。
2. SSO が有効。外部 ID は従来のユーザー名とパスワードの経路を使えません。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 の意味です。1 つのプール型ホスト プール、1 つのプロファイル モデル、内部ユーザーと外部ユーザーが並んで使えます。

検証

一度もサインインしていないテスト ユーザーでサインインし（または 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] の行を読みます。8 桁のコードは 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 キー、領域マッピング、管理者の同意、2 つの必須サービス、Fiddler プロキシ、参加の種類です。

AD 参加ストレージが依然として正しい選択となる場合

可能だからというだけでハイブリッド環境を Entra Kerberos ストレージに移すことはしません。次の場合はプロファイル共有に AD DS または Entra Domain Services の認証を残してください。

• ユーザーがセッション内から Kerberos や NTLM でオンプレミスのファイル サーバー、プリント サーバー、統合認証の Web アプリに到達する必要がある場合。外部 ID はこれをまったく行えず、クラウド専用ユーザーにはオンプレミス アカウントがありません。
• Azure Government や 21Vianet で運用している場合。クラウド専用 Entra Kerberos はサポートされません。
• ID がハイブリッドで、ツール群が icacls、ACL を保持する Robocopy、または Azure File Sync である場合。ハイブリッド経路ならそれらをすべて維持できます。
• セッション時間が日常的に 10 時間を超え、FSLogix 26.08 にまだ標準化できない場合。ハイブリッド参加クライアントは、Entra 専用クライアントが使えないクラウド信頼による緩和を使えます。

Azure Files 上のハイブリッド FSLogix は引き続き完全にサポートされており、GA には移行を強制するものは何もありません。

今すべきこと

1. ID の種類別にユーザーを棚卸しします。ハイブリッド、クラウド専用、ゲストです。現在永続プロファイルを持たないクラウド専用ユーザーとゲストが最初の候補です。
2. パイロット イメージを KB5079391 以降を適用した Windows 11 24H2（ゲストも使うなら 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. 2 つの条件付きアクセス ポリシーを作成し、除外を確認し、ユーザー単位 MFA を無効にします。
8. クラウド専用のパイロット ユーザーにサインインさせ、frx.exe list-redirects でコンテナーを検証し、ゲストでも繰り返します。
9. その後にドメイン コントローラー廃止計画を見直し、オンプレミス Kerberos がまだ必要なものにはハイブリッド共有を残します。

これらすべての毎月の変更は AVD 新機能シリーズで追跡しています。

もう一組の手が必要ですか？Big Hat Group は米国とカナダの組織向けに Azure Virtual Desktop アーキテクチャのコンサルティングを提供しています。ID と 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 の ID ベース認証のトラブルシューティング（SMB）
• Azure Virtual Desktop の ID と認証
• 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 の新機能