🤖

AVD で SSO するために ADJ から MEHJ に変更する

2024/05/04に公開

Azure

avd

tech

TL;DR

AVD で SSO したい
そのために、AVD の一般的なデプロイ方法である ADJ から、MEHJ に変更したい
ADFS など追加のコンポーネントを導入することなく、SSO ができたのでうれしい

はじめに

Azure Virtual Desktop (AVD) の基本的なデプロイ方法として、Active Directory joined (AD 参加、ADJ) の構成があります。
ただし、Microsoft Entra ID 認証を使用して Azure Virtual Desktop にシングルサインオンを構成するに書いてあるとおり、single sign-on (SSO) を実現するためには、Microsoft Entra joined (MEJ) または Microsoft Entra hybrid joined (MEHJ) が必要です。
すでに AD joined の状態を前提として、MEHJ 環境に変更し、最終的に AVD の SSO を実現する手順を書いていきます。

目次のとおりではあるんですが、大まかな手順としては以下のとおりです。

AVD セッションホストを ADJ から MEHJ に変更
AVD のコントロールプレーン側の設定を変更
AD サーバーで SSO のための設定を追加
Remote Desktop クライアントから接続

ADJ から MEHJ への変更

AD joined の構成から MEHJ への変更は、Microsoft Entra connect の構成から行うようです。
というのも、この手順は大規模環境向けの一括展開方法で、今回は 1 台ずつの個別の展開しか試していないので、伝聞の形になってしまっています。
docs は Microsoft Entra ハイブリッド参加を構成する -- マネージドドメインにありますので、ぜひ見てみてください。

で、実際に試した方法は 1 台ずつ適用ができる方法で、Microsoft Entra ハイブリッド参加の対象となるデプロイに書かれています。
Group Policy Object (GPO) を用いており、AD サーバで対象のコンピューターを含む Organizational Unit (OU) を作成してリンクすることで、段階的に MEHJ への移行を進めることができます。

より小規模向けの方法としては、管理者権限を持っている前提ですが、gpedit を使って直接 registry を変更する方法もあります。

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD" /v TenantId /t REG_SZ /d "<tenant-id>" /f
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD" /v TenantName /t REG_SZ /d "<tenant-name>" /f

<tenant-id> や <tenant-name> は Azure Portal などから確認ができます。
<tenant-name> には、カスタムドメインがあっても、xxxxxxx.onmicrosoft.com など初期に割り当てられたドメインを指定することに問題はありませんでした。
その後、何度かマシンを再起動することで、MEHJ の状態へと変更されます。

確認方法はいくつかあります。

dsregcmd /status で確認

端末側で実行可能な確実な方法です。
古い表記ではありますが、AzureAdJoined と DomainJoined が YES になっていれば MEHJ になっていると判断できます。また、トラブルシュート方法は dsregcmd コマンドを使用したデバイスのトラブルシューティングに書かれています。私の場合は、ちょっと新しいものをためしてやろう、と Microsoft Entra Connect Sync ではなく Cloud Sync を使っていたためにデバイス情報が同期されずエラーとなっていました。。Connect sync と Cloud sync の機能比較は Microsoft Entra クラウド同期とは? -- Microsoft Entra Connect とクラウド同期の比較に書かれています。
Portal で確認

Azure Portal でも Microsoft Intune Admin center でもいいのですが、デバイス情報が確認できるポータルから該当のマシン情報を確認する方法です。それなりの権限がなければ見られないと思うので、あくまで管理者向けの確認方法となります。

RDP の Microsoft Entra 認証を有効化

ここに関しては、docs に書いてあるとおりなので迷いませんでした。

Import-Module Microsoft.Graph.Authentication
Import-Module Microsoft.Graph.Applications

Connect-MgGraph -Scopes "Application.Read.All","Application-RemoteDesktopConfig.ReadWrite.All"

$MSRDspId = (Get-MgServicePrincipal -Filter "AppId eq 'a4a365df-50f1-4397-bc59-1a1564b8bb9c'").Id
$WCLspId = (Get-MgServicePrincipal -Filter "AppId eq '270efc09-cd0d-444b-a71f-39af4910ec45'").Id

のあと、いったん false であることを確認します。

Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $MSRDspId
Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId

そして、true に変更して、再度確認します。

If ((Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $MSRDspId) -ne $true) {
    Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $MSRDspId -IsRemoteDesktopProtocolEnabled
}

If ((Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId) -ne $true) {
    Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId -IsRemoteDesktopProtocolEnabled
}

Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $MSRDspId
Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $WCLspId

ターゲットデバイスグループを構成

docs に書かれているこの部分に関しては、ユーザーに対して SSO でログインした際に最初に聞かれてしまうダイアログを非表示にするものだったのでいったん割愛しています。

Kerberos サーバーオブジェクトを作成

ここが厄介なのですが、たぶん、Microsoft Entra ID 認証で SSO ログインすると、AD 認証をしておらず、Kerberos 認証を利用するようなリソースへのアクセスに問題が発生するんだと思います。
オンプレミスのリソースへのパスワードなしのセキュリティキーサインイン -- Kerberos サーバーオブジェクトを作成するに書かれている手順を実行し、それっぽいオブジェクトを作成します。
例が 4 種類あり、よくわからなかったのですが、結局はなんかたぶん AD 上で 2 番目の手順を実行すればうまくいきました。

セッションホストが MEHJ ではなく、MEJ であればこの手順は不要です。
たとえば、AVD 環境を新しく構築し、AD 認証を利用するファイルサーバーなどは利用しない・接続性がない、認証は全部 Microsoft Entra ID 認証だよ、という環境であればこちらの手順を割愛できます。

シングルサインオンを有効にするようにホストプールを構成

こちらは簡単で、Azure Portal から該当のホストプールを選択し、RDP property にある該当の項目を設定するのみです。

Remote Desktop クライアントから接続

では早速、接続していきましょう。
うまくいけば、該当の AVD リソースをダブルクリックし、パスワード等を入力せずに接続できるはずです。
パスワードが求められるようであれば何かの手順を飛ばしているか、設定が反映されていない、必要な接続先へのネットワーク接続性が保たれていない可能性があります。
私の場合は、Kerberos サーバーオブジェクトを、まぁいらないだろう、と思って飛ばしていたらダメでした。。

まとめ

AVD の基礎的なデプロイである ADJ 環境から、MEHJ 環境へと移行することで、SSO を有効化するための手順を書いてみました。
手元のマシンに対する要件 (Microsoft Entra Registered (MER) や MEJ である必要) がなく、SSO できるのはなかなか便利なのではないかと思います。
AVD が出てきた当初、AD 認証の部分を SSO できないか、ということで Active Directory Federation Services (ADFS) を今さら立てる、みたいな話もありましたが、ちゃんとクラウドっぽい解決方法が正しく提供されて一安心です。

参考

Microsoft Entra ID 認証を使用して Azure Virtual Desktop にシングルサインオンを構成する

Microsoft Entra ハイブリッド参加（旧HAADJ）を構成してみた

Microsoft Entra Kerberos 認証を構成しオンプレミスへ SSO する

Microsoft Entra ハイブリッド参加を構成する -- マネージドドメイン

Microsoft Entra ハイブリッド参加の対象となるデプロイ

Hybrid Azure AD Join 失敗時の初動調査方法について (マネージド編)

Microsoft Entra デバイス登録のしくみ

dsregcmd コマンドを使用したデバイスのトラブルシューティング

オンプレミスのリソースへのパスワードなしのセキュリティキーサインイン -- Kerberos サーバーオブジェクトを作成する

Update log

概要の手順を追加 - 2024/05/04
いい感じの blog があったのでリンクを追加 - 2024/05/04