Windows Hello for Business で PIN や顔認証・指紋認証を構成したのに、ハイブリッド Azure AD 参加デバイスだけ「そのオプションは一時的に利用できません（That option is temporarily unavailable）」と表示されて使えない――という相談は、Intune 導入後のハイブリッド環境でとてもよく発生します。本記事では、仕組みを押さえながら、再現しやすい手順で原因を切り分け、安定運用につなげるための具体的な対処方法をまとめます。
Windows Hello で「そのオプションは一時的に利用できません」が出る状況とは
まずは問題の症状を整理します。ハイブリッド Azure AD 参加の Windows 10 / Windows 11 クライアントで、サインイン画面から Windows Hello（PIN / 顔認証 / 指紋認証）を選ぶと、次の英語メッセージが表示され、該当オプションが利用できないケースです。
That option is temporarily unavailable.
For now, please use a different method to sign in.
同じ Intune ポリシーを適用していても、Azure AD のみ参加（クラウドネイティブ）のデバイスでは問題なく Windows Hello が使える一方で、オンプレミス AD と Azure AD のハイブリッド参加デバイスのみこのエラーになるのがポイントです。
この差はそのまま、「クラウドだけで認証が完結する Azure AD 参加」と、「オンプレミス Active Directory（AD）と Azure AD の両方にまたがるハイブリッド参加」という構成の違いから生じています。つまり、オンプレ AD 側の条件が満たされていないときに、この「一時的に利用できません」エラーが出やすくなります。
前提環境と発生しやすいシナリオ
本記事では次のような構成を前提として説明します。
- クライアント OS: Windows 10 21H2 / 22H2、または Windows 11
- デバイスはオンプレ AD ドメイン参加＋ハイブリッド Azure AD 参加
- Intune（Microsoft Intune）から Windows Hello for Business（WHfB）ポリシーを配布
- ユーザーは PIN, 顔認証, 指紋認証を登録済み
- Azure AD のみ参加デバイスでは問題が発生しない
特に「リモートワークが多く、VPN 越しにオンプレ AD と通信している」「拠点ごとに分割された DNS ゾーンやファイアウォールが存在する」といった環境では、ハイブリッド参加デバイスでのみ Windows Hello が不安定になることがよくあります。
ハイブリッド Azure AD 参加デバイスでのみ問題になる理由
Windows Hello for Business（WHfB）は、単に PIN や指紋をローカルに照合しているわけではありません。TPM 内の秘密鍵と、Azure AD やオンプレ AD（ドメイン コントローラ）側の公開鍵を組み合わせたチャレンジレスポンスで認証を行います。
Azure AD のみ参加デバイスの場合、サインイン時のメインの相手は Azure AD です。一方、ハイブリッド Azure AD 参加デバイスでは、以下の条件が満たされて初めて WHfB が安定して動作します。
| 条件 | 内容 | 満たされない場合の影響 |
|---|---|---|
| 1. デバイスが正しくハイブリッド参加している | AzureAdJoined / AzureAdPrt が有効な状態 | クラウド側でデバイスを正しく認識できず、WHfB が一部無効化される |
| 2. オンプレ AD のコンピューターアカウントが有効 | lastLogonTimeStamp が更新され、DC とセキュアチャネルを確立可能 | ドメイン コントローラと通信できず、オンプレ認証が失敗する |
| 3. WHfB の信頼モデルが正しく構成されている | Cloud Kerberos Trust または 証明書信頼モデルが正しくセットアップ | キーペアは存在しても、Kerberos チケット発行などが行えない |
どれかひとつでも欠けると、Windows は WHfB を安全に使えないと判断し、サインイン画面で「そのオプションは一時的に利用できません」とユーザーに別のサインイン方法（パスワードなど）を使うよう促します。
原因切り分けのための基本チェック一覧
ここからは、実際に現場で使えるトラブルシュートのステップを整理します。まず全体像を一覧で確認してから、一つずつ詳しく見ていきます。
| 手順 | 目的 | コマンド / 操作 | ポイント |
|---|---|---|---|
| 1 | ハイブリッド参加状態の確認 | dsregcmd /status | AzureAdJoined=YES、AzureAdPrt=YES であること |
| 2 | デバイスオブジェクト同期の確認 | Get-ADComputer -Identity <PC名> -Properties * | オンプレ AD にコンピューターオブジェクトがあり、lastLogonTimeStamp が更新されているか |
| 3 | ドメイン コントローラとの通信確認 | Test-ComputerSecureChannel -Verbosenltest /dsgetdc:<ドメイン名> /pdc | 1355 エラーは「DC 未検出」。DNS / ネットワーク / FW を疑う |
| 4 | WHfB の信頼モデルを構成 | Cloud Kerberos Trust を推奨 （Intune または GPO で Use cloud trust for on-premises authentication を有効化） | Windows 10 21H2/22H2、Windows 11 でサポート。代替として証明書信頼モデル構築 |
| 5 | PIN / 生体情報の再登録 | [設定] → [アカウント] → [サインイン オプション] → 「PIN を忘れた場合」 | 構成が正しいのにエラーが続く場合に有効 |
| 6 | TPM のクリア | tpm.msc → [TPM のクリア]、または BIOS/UEFI でリセット | 再イメージ後・設定変更後の古いキー競合を解消 |
| 7 | OS バージョンの適合性確認 | Windows 10 側のビルドを確認（winver） | Windows 11 で成功 / Windows 10 で失敗 → 10 側が 22H2 + 最新 CU か確認 |
手順 1: dsregcmd /status でハイブリッド参加状態を確認する
まずは、そもそもデバイスが正しくハイブリッド Azure AD 参加できているかを確認します。管理者権限の PowerShell または コマンド プロンプトで次を実行します。
dsregcmd /status
出力の中で特に重要なのは次の 2 行です。
- AzureAdJoined = YES
- AzureAdPrt = YES
AzureAdJoined=YES は、デバイスが Azure AD に参加済みであることを示します。ここが NO の場合は、ハイブリッド Azure AD 参加そのものがうまく完了していません。GPO や Intune のハイブリッド参加用設定、Azure AD Connect 側の構成を見直す必要があります。
AzureAdPrt（Primary Refresh Token）=YES は、Azure AD との間で有効なトークンが確立されていることを示します。NO の場合は、次のような要因が疑われます。
- インターネット接続が不安定、またはプロキシで
login.microsoftonline.comなどへのアクセスがブロックされている - ユーザーのパスワードが期限切れで、トークンを更新できていない
- 時刻同期の問題（クライアントとドメイン コントローラ / Azure AD 間で時刻差が大きい）
この段階で AzureAdJoined=NO または AzureAdPrt=NO であれば、WHfB 以前に「ハイブリッド Azure AD 参加デバイスとしての前提条件」が崩れているため、そこから優先的に修正します。
手順 2: オンプレ AD のコンピューターオブジェクトと lastLogonTimeStamp を確認する
ハイブリッド構成では、デバイスはオンプレ AD ドメインのメンバーでもあります。オンプレ側のコンピューターアカウントが無効化されたり、権限不足になっていると WHfB 認証も不安定になります。
ドメイン コントローラ上、または RSAT が入った管理端末から、次を実行して対象 PC の状態を確認します。
Get-ADComputer -Identity <PC名> -Properties *
ここで特に確認したいのは次の項目です。
- Enabled … オブジェクトが無効化されていないか
- lastLogonTimeStamp … 最近更新されているか（オンラインになっているのに何ヶ月も更新されていない場合は怪しい）
- userAccountControl … 4096（WORKSTATION_TRUST_ACCOUNT）など、想定外のフラグが立っていないか
lastLogonTimeStamp が極端に古い場合は、クライアントと DC 間のセキュアチャネルが壊れている可能性があります。これは次の「手順 3」でさらに詳細に確認します。
手順 3: Test-ComputerSecureChannel と nltest で DC 接続を検証する
WHfB でオンプレ AD に対して認証を行うには、クライアントが ドメイン コントローラと確実に通信できることが絶対条件です。ローカルにキャッシュが残っている間はなんとなく動いてしまい、あるタイミングで突然「そのオプションは一時的に利用できません」に変わることもあります。
まずはセキュアチャネル（ドメイン メンバーとしての信頼関係）を、管理者権限の PowerShell で確認します。
Test-ComputerSecureChannel -Verbose
ここで True が返ればセキュアチャネルは正常です。False やエラーが出る場合は、次の点を疑います。
- VPN 接続が確立されていない、またはフルトンネル VPN で DC へのルーティングが漏れている
- クライアントの DNS 設定が社内 DNS を参照していない（インターネット DNS だけになっているなど）
- ファイアウォールで RPC / Kerberos 関連ポートがブロックされている
さらに、PDC（プライマリ ドメイン コントローラ）への到達性を nltest でチェックします。
nltest /dsgetdc:<ドメイン名> /pdc
ここで 1355 エラー（ERROR_NO_SUCH_DOMAIN） が出る場合、「そのドメインは見つかりません」という状態です。ほぼ確実に DNS またはネットワーク経路の問題なので、次のような観点で確認します。
- クライアントの DNS サーバーが社内 DNS（ドメインをホストしているサーバー）になっているか
- 名前解決で
_ldap._tcp.dc._msdcs.<ドメイン名>が引けるか - VPN / 拠点間ルータ / ファイアウォールで DC（TCP 88, 389, 445, RPC など）への通信が許可されているか
DC に到達できない状態では、Windows は WHfB を使ったオンプレ認証を継続できず、サインイン画面から該当オプションを一時的に無効化します。逆に、ここを直すだけで何もしていないのに「突然直った」ように見える例も多いです。
手順 4: WHfB の信頼モデル ― Cloud Kerberos Trust を推奨
ハイブリッド Azure AD 環境における WHfB の構成で、最近の推奨はCloud Kerberos Trust（クラウド Kerberos 信頼）です。これは Azure AD にある認証情報を使ってオンプレ AD の Kerberos チケットを発行させる仕組みで、従来の「証明書信頼モデル」と比べて構成がシンプルになります。
Intune または グループポリシーで、次のような設定を有効化します。
- ポリシー名（例）: Use cloud trust for on-premises authentication
- 状態: 有効
この設定は、Windows 10 21H2 / 22H2 と Windows 11 でサポートされています。Windows 10 の古いビルドやサポート外のエディションでは Cloud Kerberos Trust を完全に利用できない場合があるため、後述の「手順 7」で OS バージョンを必ず確認します。
一方、既存環境で WHfB の証明書信頼モデル（NDES / SCEP によるクライアント証明書発行）を使っている場合は、次も合わせて確認してください。
- NDES サーバーが稼働しているか（サービス停止・証明書期限切れがないか）
- 証明書テンプレートの拡張キー使用法（EKU）が WHfB 用に正しく設定されているか
- クライアントに WHfB 用証明書が配布されているか（
certlm.mscで個人ストアなどを確認）
証明書信頼モデルを使う場合、どこか一箇所の設定漏れや証明書期限切れがあると、やはり「そのオプションは一時的に利用できません」につながります。新規導入であれば、構成が軽い Cloud Kerberos Trust への一本化を強くおすすめします。
手順 5: PIN / 生体情報の再登録（再プロビジョニング）
ハイブリッド参加状態、DC との通信、信頼モデルがすべて正しいにもかかわらず、特定ユーザーや特定デバイスだけでエラーが続く場合は、WHfB 資格情報自体の破損や不整合が疑われます。その場合は一度 PIN / 生体情報を再登録します。
- [設定] → [アカウント] → [サインイン オプション] を開く
- 「Windows Hello 暗証番号 (PIN)」を選択
- 「PIN を忘れた場合」 をクリック
- 表示されるウィザードに従って、Microsoft アカウント または 会社/学校アカウントで再認証
- 新しい PIN を登録し、その後に顔認証・指紋認証を再度登録
複数の WHfB 政策を切り替えたり、GPO から Intune への移行を行った直後などは、ポリシー変更によって既存の PIN が無効化されることがあります。この場合も、ユーザーに「PIN を忘れた場合」から再登録させることで解消するパターンが多いです。
手順 6: TPM のクリアで古いキー競合を解消する
Windows Hello for Business は、TPM 内に保存された秘密鍵を使って認証を行います。そのため、OS の再イメージや大幅な構成変更を繰り返した PC では、TPM 内に古いキーが残り、それが WHfB の再プロビジョニングを妨げるケースがあります。
そのような場合は、次の手順で TPM をクリアします。
- [スタート] メニューから
tpm.mscを実行 - 「TPM 管理コンソール」で現在の状態を確認
- 右ペインから [TPM のクリア] を選択し、再起動して処理を完了
または、BIOS / UEFI 設定画面から「TPM Clear」「Security Chip Reset」などの項目を実行する方法もあります（ベンダーによって名称は異なります）。ただし TPM のクリアは、BitLocker の回復キーを事前にバックアップしておくことが絶対条件です。BitLocker が有効なドライブでは、TPM をクリアすると復号に回復キーが必要になるためです。
TPM をクリアした後は、再度サインインし、手順 5 の要領で WHfB の PIN / 生体情報を新規に登録します。これで「古いキーとの競合」が解消されるため、サインイン画面のエラーが収まることがあります。
手順 7: OS バージョンと更新プログラムの適合性を確認する
Cloud Kerberos Trust を利用した WHfB のハイブリッド構成では、Windows のビルドや累積更新プログラムの有無が動作に大きく影響します。よくあるのが、「Windows 11 の PC では問題なく動くのに、Windows 10 だけエラーになる」というパターンです。
この場合、Windows 10 側で次を確認します。
winverコマンドでバージョンとビルド番号を確認- 可能であれば Windows 10 22H2 かつ最新の累積更新プログラム（CU）を適用
- 古い LTSB / LTSC エディションを使っている場合は、Cloud Kerberos Trust のサポート状況を事前に検証
実務上は、「Windows 11 でテスト → 問題なし → Windows 10 でも同じポリシーを適用」と展開しがちですが、Windows 10 側の更新が遅れていると WHfB 周りの動作が不安定になり、「そのオプションは一時的に利用できません」が Windows 10 にだけ発生するケースが多く見られます。
典型的な原因と対処まとめ
ここまでの内容を、よくある症状ごとに整理した一覧です。現場での一次切り分けや、ヘルプデスク向けマニュアルの雛形としても利用できます。
| 症状 | 主な原因 | 代表的な解決策 |
|---|---|---|
nltest /dsgetdc で 1355 エラー | DC への到達不可、または DNS 設定不備 | DNS ゾーンやクライアント DNS 設定、サイト・サブネット、ファイアウォールルールを修正 |
| イベントログに「証明書信頼が確立されていない」 | WHfB 用証明書が未発行または期限切れ | NDES / SCEP 構成と証明書テンプレートを確認し、クライアントに証明書を再配布 |
| Cloud Kerberos Trust が有効にならない | Intune / GPO ポリシー未適用、対応 OS ではない | ポリシー設定を有効化し、対象グループに割り当て。Windows 10 を 22H2＋最新 CU に更新 |
| 特定 PC だけ WHfB が突然使えなくなる | TPM 内キーの衝突、またはセキュアチャネル破損 | TPM をクリアし、ドメイン再参加やセキュアチャネルの修復後に WHfB を再プロビジョニング |
AzureAdPrt=NO だが DC にはつながる | Azure AD への接続不良、トークン更新失敗 | プロキシ例外に login.microsoftonline.com などを追加し、ユーザーに再サインインさせる |
| Windows 11 では成功、Windows 10 だけ失敗 | Windows 10 側のバージョン・更新プログラム不足 | Windows 10 クライアントを 22H2＋最新 CU に統一してから再テスト |
Windows Hello for Business の仕組みをざっくり理解しておく
トラブルシュートをやりやすくするために、WHfB のざっくりした動きを押さえておきましょう。詳細なプロトコルは非常に複雑ですが、ハイブリッド環境のトラブル対応では次の 3 点を理解しておけば十分です。
- TPM 内の秘密鍵 … PIN / 生体情報はあくまでローカルのキーを解錠するための手段
- Azure AD / オンプレ AD 側の公開鍵 … デバイスやユーザーに紐づいた公開鍵を保管
- チャレンジレスポンス … サーバーからのチャレンジに、秘密鍵で署名したレスポンスを返す
ハイブリッド環境では、サインイン時に次のようなことが裏側で行われます。
- ユーザーが Windows Hello（PIN / 顔 / 指紋）でローカルサインイン
- デバイスの TPM が秘密鍵を使って署名し、Azure AD またはオンプレ AD へ応答
- Cloud Kerberos Trust または証明書信頼モデルに基づき、Kerberos チケットやトークンが発行される
この流れのどこかで「鍵がない / 信頼関係がない / 相手に届かない」のいずれかが起こると、Windows は安全側に倒れて WHfB を無効化し、「そのオプションは一時的に利用できません」と表示します。逆に言えば、この記事で説明した 3 条件（TPM / DC 通信 / 信頼モデル）を順に確認していけば、多くの問題は整理して考えられます。
ネットワークとプロキシの注意点（ハイブリッド環境で特に重要）
ハイブリッド Azure AD 参加デバイスの場合、クライアントは次の 2 種類の通信を同時に満たす必要があります。
- オンプレ AD / DC との通信（Kerberos, LDAP など）
- Azure AD との通信（PRT 更新、デバイス登録、トークン取得など）
特にプロキシや SSL インスペクションを導入している環境では、次のような落とし穴で WHfB が不安定になることがあります。
- プロキシ認証が必要なため、サインイン前の段階で Azure AD にアクセスできない
- SSL インスペクションにより、Azure AD への接続で証明書エラーが発生し、PRT 更新に失敗
- VPN 接続を確立しないと DC に到達できないのに、サインイン時点では VPN が張られていない
これらを避けるために、次のような設計・運用を検討するとよいでしょう。
login.microsoftonline.comやdevice.login.microsoftonline.comなど、Microsoft 365 関連の必須エンドポイントをプロキシ認証除外する- VPN クライアントの「常時接続」機能や「デバイス トンネル（先行接続）」を活用し、サインイン前から DC に到達できるようにする
- クライアント DNS の設定を見直し、オンプレ DNS とインターネット DNS の優先順位やスプリットブレイン DNS を整理する
ネットワーク設計のわずかな違いが WHfB の動作に大きく影響するため、「Azure AD のみ参加デバイスでは問題ないから安心」と考えるのではなく、「ハイブリッド参加デバイスでの経路」を必ず別途検証することが重要です。
Intune での状態確認とイベントログの活用
クライアント側だけでなく、管理側コンソールから WHfB のプロビジョニング状況を確認することも大切です。Intune 管理センター上では、次のメニューから Windows Hello for Business の状態を見ることができます。
- [Endpoint Security] → [Account protection] → [Windows Hello for Business]
ここで各デバイスのプロビジョニング状態や、失敗時のエラーコードを確認しておくと、「ポリシーがそもそも適用されていないのか」「適用されたがクライアント側でエラーになったのか」を切り分けられます。
また、クライアント側では次のイベントログが WHfB トラブルシュートの重要な情報源です。
- アプリケーションとサービス ログ → Microsoft → Windows → User Device Registration
- アプリケーションとサービス ログ → Microsoft → Windows → Authentication → Windows Hello for Business（OS バージョンによる）
ここに「信頼モデルが構成されていない」「証明書が見つからない」「クラウドからの応答がない」などのヒントが出ていることが多いため、サインイン画面のメッセージだけで判断せず、必ずログをあわせて確認しましょう。
ケーススタディ: 実際によくある失敗パターン
パターン 1: GPO から Intune に移行した途端に一部 PC でエラー
ある企業では、従来 GPO で WHfB を構成していたところ、Intune への移行に伴い「Cloud Kerberos Trust」を有効化しました。パイロットでは問題なかったものの、本番展開後に特定の拠点の PC だけ「そのオプションは一時的に利用できません」が頻発しました。
調査の結果、その拠点だけ VPN のルーティングが別経路になっており、DC へのポートが一部閉じていたことが判明。nltest /dsgetdc では 1355 エラーが出ていました。ルーティングとファイアウォールを修正し、DC との通信を確保したところ、WHfB のエラーも解消しました。
パターン 2: Windows 11 では成功、Windows 10 では常に失敗
別の環境では、Windows 11 クライアントで WHfB を導入し、Cloud Kerberos Trust も正常に動作していました。その成功を受けて Windows 10 クライアントにも同じ Intune ポリシーを適用したところ、Windows 10 だけ「そのオプションは一時的に利用できません」となりました。
確認すると、Windows 10 側は 20H2 の古いビルドで、累積更新プログラムも数ヶ月遅れていました。全クライアントを 22H2 + 最新 CU に更新したところ、同じポリシーで問題なく動作するようになりました。ここから、Cloud Kerberos Trust は OS の対応状況・更新状態とセットで評価する必要があることが分かります。
パターン 3: 一部ユーザーだけ突然 PIN が使えなくなった
最後に、ユーザー単位で発生したケースです。同じ PC でも、A さんのアカウントでは WHfB が使えるのに、B さんだけ「そのオプションは一時的に利用できません」と表示され、イベントログには WHfB のキーが見つからない旨のエラーが出ていました。
この場合は、B さんのプロファイルで何らかの理由により WHfB 関連のコンテナが壊れていたことが原因でした。[PIN を忘れた場合] から再登録しても改善しなかったため、一度 B さんのサインインプロファイルをバックアップの上で再作成し、TPM をクリアしてから WHfB を再プロビジョニングしたところ、エラーが解消しました。
このように、ネットワークや OS ではなく「特定ユーザーのプロファイル」や「TPM の状態」が原因になることもあり、切り分けでは ユーザー単位 / デバイス単位 / 拠点単位でパターンを整理することが有効です。
安定運用のためのベストプラクティス
最後に、ハイブリッド Azure AD 環境で Windows Hello for Business を安定運用するためのポイントを、再度整理しておきます。
- 構成のシンプル化 … 新規導入なら Cloud Kerberos Trust を基本とし、証明書信頼モデルとの二重運用はできるだけ避ける
- OS と更新プログラムの標準化 … Windows 10 / 11 でサポートバージョンを明確にし、最新 CU まで上げたうえでポリシーを適用
- ネットワーク経路の事前設計 … DC と Azure AD の両方に安定して到達できるよう、VPN・プロキシ・DNS の設計を見直す
- パイロット展開と段階的ロールアウト … 拠点ごと・ユーザー層ごとにパイロット検証を行い、「ハイブリッド参加デバイス」での動作を重点的に確認
- 運用ドキュメントの整備 … 本記事のようなチェックリストやコマンド例をまとめておき、ヘルプデスクが一次対応できるようにする
まとめ：3 つのポイントを押さえれば「一時的に利用できません」は怖くない
Windows Hello で「そのオプションは一時的に利用できません」と表示されると、一見原因が分かりにくく感じますが、ハイブリッド Azure AD 参加デバイスに特有の条件に着目すると、意外と整理して考えることができます。
- dsregcmd /status で AzureAdJoined / AzureAdPrt を確認する
- Get-ADComputer / Test-ComputerSecureChannel / nltest で DC と信頼関係・通信を確認する
- Cloud Kerberos Trust か証明書信頼モデルのどちらを使うかを明確にし、構成と OS バージョンをそろえる
この 3 つを順番に確認し、必要に応じて PIN 再登録や TPM クリアを行えば、ハイブリッド環境での多くの「一時的に利用できません」エラーは解消できます。Windows Hello for Business は慣れるとパスワードレス運用のための強力な武器になりますので、今回紹介した手順を自社環境向けにカスタマイズし、トラブル時の標準手順として活用してみてください。
コメント