Microsoft関連の記事執筆/教育資料作成等、お仕事承り中です。ぜひよろしくお願いいたします。

AzureAD

パスワードレス認証によるSSO②　Windows Hello for Business Cloud Trust (クラウド信頼)を試してみた

こんにちは。

ずいぶんと更新期間が空いてしまいましたが、タイトルの通り、現時点(2022/05)でプレビュー中となっているWindows Hello for Businessのクラウド信頼について試してみました。
現在、パスワードレス認証の導入を積極的に導入することを検討されている企業様も増えてきていることもあって今回の本機能については、まさに期待に応えられる機能なのではないかなと思っています。
※プレビュー段階なので、GAされた場合に動作が異なるかもしれませんがご容赦くださいませ。

こちらのブログで過去にキー信頼と証明書信頼の展開について解説しておりました。詳細はこちらをご確認いただければと思いますが、
これまでは、Windows Hello for Businessを構成した端末でオンプレミスリソースにSSOするためには、キー信頼または証明書信頼が必要でした。

Windows Hello for Business ハイブリッドキー信頼の構成について

最近、Windows Hello for Business を構成したいというお声を時々耳にするため、 タイトルにもある通り、Windows Hello for Businessのハイブリッドキー信頼の構成について学習もかねて検証環境で構成してみた結果をまとめてみました。

今回、このクラウド信頼は、キー信頼するために必要となる面倒なPKIの準備や、公開鍵の同期が必要なくなります。

クラウド信頼の前提条件の確認

以下内容はこちらのMicrosoft Docsにも記載されている通りとなります。

Hybrid Cloud Trust Deployment (Preview)

Windows Hello for Business replaces username and password Windows sign in with strong authentication using an asymmetric key pair. The following deployment guide provides the information needed to successfully deploy Windows Hello for Business in a hybrid cloud trust scenario.

ライセンス

Azure AD Premiumライセンスが必要です。AzureADにデバイスが参加した際にIntuneへ自動的に登録する構成を行っているケースが多いと思いますが、その場合は必須となります。

多要素認証

まず、多要素認証設定が必須となります。これまでも本サイトで紹介してきましたがWindows Hello for Businessを設定するときに多要素認証の設定が要求されます。なので事前に多要素認証を設定しておきましょう。
このご時世、多要素認証の設定は多くの企業様も導入されてきていると感じており、セットアップにおいて大きく躓くところでもないかなと思います。

※ただ、一点注意としては多要素認証の設定は事前に設定しているからこそ、効果を発揮するものだと思います。
よく見かける構成として、社内接続の場合は無条件でアクセスさせ、社外からアクセスさせる場合に多要素認証のみアクセスを許可するという認証制御を設定している場合、社外にデバイスを持ち出さないユーザーはおそらく多要素認証の設定を行わない可能性があります。

この場合、多要素認証設定をしていないアカウントで万が一、IDとパスワードが第３者に流出した場合、その第３者が多要素認証の設定を行ってしまえば、社外からアクセス可能となってしまう可能性があります。ですのでユーザーがしっかりと多要素認証の設定を行っているかどうかは確認しておくといいかもしれません。

クライアント端末環境

このあたりは今後アップデートがあると思いますが、本日2022/5時点では以下の通りです。

  • 「KB5010415」をインストールしたWindows 10 21H2
  • 「KB5010414」をインストールしたWindows 11 21H2

2022 年 2 月 15 日 — KB5010415 (OS ビルド 19042.1566、19043.1566、および 19044.1566) プレビュー (microsoft.com)

Windows Hello for Business Cloud Trust のサポートについて説明します。 これは、Windows Hello for Businessのハイブリッドデプロイ用の新しいデプロイ モデルです。 Fast IDentity Online (FIDO) セキュリティ キーのオンプレミス シングル サインオン (SSO) をサポートするのと同じテクノロジとデプロイの手順を使用します。 Cloud Trust は、Windowsをデプロイするための公開キー 基盤 (PKI) 要件を削除し、Windows Hello for Business展開エクスペリエンスを簡素化します。

メモ：Windows 10 21H2の「KB5010415」適用条件として、「KB5003791」が適用されていないといけない文言がありましたので参考までに。

AzureADKerberosを利用するためにサポートされる環境を用意しないといけません。

  • KB3534307をインストールしたWindows Server 2016のAD
  • KB4534321をインストールしたWindows Server 2019のAD

AzureADKerberosモジュールの準備

AzureADとオンプレミスAD間でTGTのやり取りを行うために必要となるモジュールです。
ここからモジュールをインストールすることができます。

AzureADHybridAuthenticationManagement

The Azure AD Hybrid Authentication Management module enables hybrid identity organizations (those with Active Directory on-premises) to use modern credentials for their applications and enables Azure AD to become the trusted source for both cloud and on-premises authentication.

Windows Hello for Business Cloudtrustの設定

Intuneまたは、GPOにてWindows Hello for Business Cloud Trustを利用するためにポリシー展開を行う必要があります。
今回はIntuneにて構成を行ってみました。

構成してみる

AzureADKerberosのデプロイ

先ほどの事前準備でモジュールをインストールした後、以下にならってデプロイ作業を行います。

まずはインストールを実行します。

Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

ここから設定作業に移ります。

$domain = "contoso.corp.com"   #オンプレミスADのドメイン名を指定

$cloudCred = Get-Credential -Message 'An Active Directory user who is a member of the Global Administrators group for Azure AD.'　　 #AzureADのグローバル管理者のユーザー名とパスワードを入力する

$domainCred = Get-Credential -Message 'An Active Directory user who is a member of the Domain Admins group.' 
#オンプレミスADのドメイン管理者のユーザー名とパスワードを入力する

Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred 
#AzureADKerberosのコンピューターオブジェクトが生成される

上記コマンドを実行後、オブジェクトが生成されていることを確認します。

Get-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred

このような形でRODCとユーザーオブジェクトが作成されていれば、結果が返ってきます。

実際にActiveDirectoryユーザーとコンピューターの画面上でも生成されていることが確認できます。

読み取り専用ドメインコントローラー

「krbtgt」ユーザーオブジェクト

この「krbtgt」がTGT暗号化キーを保持しているようです。なのでMicrosoft社は定期的にローテーションを行うよう、推奨しています。

AzureADKerberosサーバーキーをローテーションします

AzureADKerberosサーバーの暗号化krbtgtキーは定期的にローテーションする必要があります。
他のすべてのActiveDirectoryDCkrbtgtキーをローテーションするために使用するのと同じスケジュールに従うことをお勧めします。

シームレスSSOみたいな感じで定期的に更新をしないといけないようですね。ただ定期的にって記載されているけど、どれくらいの頻度で行えばいいものなのか。。

Windows Hello for Business Cloudtrustの設定

次にWindows Hello for Business Cloud Trustの構成を行います。
GPOとIntuneで構成することができますが、本環境ではAzureAD参加を行った端末に対して実行するため、Intuneを使って構成したいと思います。

やることは以下二つ。

  • Windows Hello for Business の有効化
  • Windows Hello for Business Cloud Trustの構成

まずは、Windows Hello for Businessを有効化するように構成します。
テナント全体に対して設定するポリシーもありますが、今回は対象を絞りたかったので構成プロファイルから行います。

[プロファイルの作成]-[Identity Protection]を選択します。

超簡易的ですが、いったんWindows Hello for Businessを構成するための最低限の設定のみで構成します。

後は、対象のグループなど指定してポリシーを作成します。

では次にクラウドトラストの構成を行います。
プロファイルの作成から「カスタム」を選択します。


構成設定で以下のように値を入力します。

名前：任意

説明：任意

OMA-URI：./Device/Vendor/MSFT/PassportForWork/テナントID/Policies/UseCloudTrustForOnPremAuth

値：True

検証当時、OMA-URIの値をDocsからそのままコピペしたとき、うまくいきませんでした。どうもスラッシュの前に空白などが入っていると構成できないようです。環境に依存した問題かもしれませんが、うまく構成できない場合は、一度お試しいただければと思います。

あとは適用対象を指定し、ポリシーを保存します。

クライアント端末での動作確認

さて、ここまで来たらクライアントの動作確認に移ります。すでに端末にログインしている方は、一度サインアウトして再度サインインを行ってみてください。

Windows Hello for Businessのセットアップ画面が表示されるのでウィザードにしたがって進めます。

多要素認証を設定していれば、WIndows Hello for Businessの設定を行う前に必ず要求されます。

ここで冒頭お話していた通り、多要素認証を設定していない場合は、その場で多要素認証を設定するようにウィザードが進んでしまいます。なのでIDとパスワードが漏洩した場合は多要素認証の設定を第3者に構成されてしまう恐れがあるのでしっかり設定は事前に行っておくほうがいいかもしれないです。

Windows Hello for Businessの設定が終わったら正しく構成が行えているかを確認しましょう。
イベントログを起動し、[Windows]-[User Device Registration]に記録されている以下イベントIDを確認します。

赤枠部分がYesとなっているかを確認します。もしYesになっていない場合はポリシーが適用されていない等、
うまく構成されていない状態になっている可能性があります。

テストとしてオンプレミスのリソースにSSOできるかどうかの確認をします。
ファイルサーバーのリソースにアクセスしてみると、認証画面が表示されずシームレスにSSOができました。

また「klist」コマンドを実行してみると、対象のユーザーに対してKerberosチケットが発行されていることも確認ができました。

-AzureAD