Entra 参加した端末に、サインインできない事象と対応
ケース①
シナリオ
・Windows 10 proをAzure VMで新規作成
・RDPで対象VMにログイン（ローカルアカウント）
・Entra参加を実施
利用したユーザは、test@xxxxxx.onmicrosoft.com
・対象VMにて、NLA無効化
・RDP切断
・再度RDPで対象VMにログイン
・Windows のログインが画面が表示される
・対象VMへのサインインで以下UPNとパスワードを入力、
・「The user name or password is incorrect.Try again」と表示される
★感覚としては、UPNとパスワードを入力してすぐに、上記が表示される
（Entraまで認証要求が飛んでいる感じがせず、ローカルPCではじかれている印象）
対応方法
RDP 接続時に ”AzureAD\xxx@xxxxxx.onmicrosoft.com (AzureAD\<Microsoft Entra ID ユーザー アカウント名>)” の形式でサインインを試行してみる。
以下に Microsoft Entra 参加を構成した VM への RDP 接続の動作につい記載します。
まず Microsoft Entra 参加が構成された Windows への Microsoft Entra ID ユーザー アカウントでの RDP を実施する場合、既定の設定では RDP 接続元のデバイスも Microsoft Entra ID に対して登録、参加がされている必要があります。
この接続元のデバイスも Microsoft Entra ID に対して登録、参加が必要な点については以下の公開情報に説明があります。
リモートの Microsoft Entra 参加済みデバイスに接続する
– Microsoft Entra 認証なしで接続する
// 抜粋 //
既定では、リモート PC でサポートされている場合でも、RDP は Microsoft Entra 認証を使用しません。 このメソッドを使用すると、次の場所からリモートの Microsoft Entra 参加済みデバイスに接続できます。
・Windows 10 バージョン 1607 以降を使用して、 Microsoft Entra 参加済みデバイスまたは Microsoft Entra ハイブリッド参加済み デバイス。
・Windows 10 バージョン 2004 以降を使用した Microsoft Entra 登録済みデバイス。
！注意
ローカル デバイスとリモート デバイスの両方が同じ Microsoft Entra テナントに存在する必要があります。 Microsoft Entra B2B ゲストは、リモート デスクトップではサポートされていません。
///////////
しかし、接続先の VM にて [ネットワーク レベル認証を使用して接続するデバイスを要求する] (NLA) を無効化することで、この RDP 接続元のデバイスも Microsoft Entra ID に対して登録、参加がされている必要があるという要件をスキップすることが可能となっています。
また、既定の設定では Windows デバイスに RDP 接続を試行しても接続先の Windows の認証画面は表示されません。既定の設定では Windows デバイスに RDP 接続を試行すると以下の画面が表示されます。
一方で [ネットワーク レベル認証を使用して接続するデバイスを要求する] (NLA) を無効化した場合は、RDP 接続を試行すると以下の画像のように RDP 接続先の Windows の認証画面が表示される動作となります。
[ネットワーク レベル認証を使用して接続するデバイスを要求する] (NLA) を無効化した Microsoft Entra 参加構成 VM に RDP 接続を試行し、 Windows の認証画面が表示された場合、Microsoft Entra ID ユーザー アカウントによるサインインを実施するには ”AzureAD\xxx@xxxxxx.onmicrosoft.com (AzureAD\<Microsoft Entra ID ユーザー アカウント名>)” の形式でのサインインが必要になります(公式ドキュメントには記載されていない謎の仕様）
注意点
Microsoft Entra 参加が構成された VM への RDP 接続時には、[ネットワーク レベル認証を使用して接続するデバイスを要求する] (NLA) は有効に状態で運用するのが推奨となっています。
こちらは以下の公開情報にも説明があります。
リモート Microsoft Entra参加済みデバイスに接続する
– 前提条件
// 抜粋 //
・リモート デバイスでは、[設定]、[システム]、[リモート デスクトップ] の [リモート デスクトップ] オプションを選択して、別のデバイスからこの PC に接続>使用する必要があります>リモート デスクトップ。
○[ ネットワーク レベル認証を使用して接続するデバイスを要求する ] オプションを選択することをお勧めします。
//////////
[ネットワーク レベル認証を使用して接続するデバイスを要求する] の無効化が非推奨であることは明言されていませんが、基本的には有効化状態で運用をいただくことが推奨となっているようです（MSサポートにも確認しました）。
NLAを無効にした状態で、RDPでEntra参加済み端末に接続して、WHfBの検証はできるか
元々、WHfBの検証をする際に、手元に手ごろな端末がなかったため、Azure VM上のWindows端末を使えないか？と考えたところが、スタートでした。
確認した結果（結論は以下です）
RDP 接続を実施している場合、この接続先の VM 上では Windows Hello for Business のプロビジョニングは利用が出来ない動作となっています。
本動作は RDP 接続時の制限となっており、Hyper-V などの VM であれば拡張セッション（りモーとデスクトップの技術を使った接続方法）を利用していない状態の接続であれば Windows Hello for Business を利用することも可能ですが、拡張セッションを利用した RDP 接続となると同じ VM でも Windows Hello for Business が利用できません。
ケース②
シナリオ
・Windows 10 proをVMware環境にて VMで新規作成
・vSphere Clientの「WEBコンソール」起動(RDPではない）により、対象VMをブラウザ上で表示
・対象VMにログイン（ローカルアカウント）
・FortigateのSSL証明書をローカル コンピューターの証明書ストアにインストール、HTTPSでの通信ができることを確認（インターネット接続境界のFortigateにてSSLインスペクションを実施しているため）★今回のポイント
・Windows 10 proのライセンス認証を実施
・Entra参加を実施
利用したユーザは、test@xxxxxx.onmicrosoft.com
・ローカルアカウントはサインアウト
・Windows のログインが画面が表示される
・対象VMへのサインインで以下UPNとパスワードを入力、
・「ユーザ名かパスワードが正しくありません。入力し直してください」と表示される
対応方法
dsregcmd /statusコマンドの結果にて、Device Details の項目で 「DeviceAuthStatus : FAILED. Error: 0xd0072f8f」 というエラーが記録されていることが確認しました。
この 0xd0072f8f というエラーは、"ERROR_INTERNET_DECODING_FAILED (Content decoding has failed)" という内容を示しており、一般的には TLS/SSL の通信が正常に行えない場合に発生し得ます。
どうやら、SSL証明書のインストールがうまくいっていなかったようです。
■手順①今回実施したＳＳＬ証明書のインストール手順
・certlm.mscを起動
・信頼されたルート証明書期間を選択し、右クリック
・「すべてのタスク」→「インポート」より証明書をインポート
■手順②実施後に問題が解消したインストール手順
・デスクトップにあるSSL証明書をダブルクリック
・「証明書のインストール」
・保存場所として「ローカルコンピュータ」を選択
・証明書の配置先を、「信頼されたルート証明書期間」として、インポート
手順②を実施したことで、
Device Details が「Success」に変わり、test@xxxxxx.onmicrosoft.comで、端末にログインできるようになりました。
注意点
証明書のインストール手順①②はどちらも実施していることは同じはず（手順だけが違うと）なのに、なぜか手順②の方法で、dsregcmd /statusでエラーが表示されなくなった。