リモートデスクトップ接続のWebアカウントによるサインイン

ようやく社内のPCの一部をWindows 11機に入れ替えることになりました。PCのハードウェア自体は11対応のものがほとんどだったのですが、業務アプリの関係で11化できずにいました。

Windows 11機に替えるタイミングで、サインインに使用するアカウントをローカルアカウントからAzure AD（Microsoft 365）アカウントに変更することにしました。

Azure ADアカウントの方が、SSO（シングルサインオン）がスムーズで、認証も普段は求められないとMicrosoftから聞いていたので。

WebアカウントではIPアドレスが使えない

Windows 10 PCと入れ替えて、業者に業務用アプリを入れてもらい、当日テレワークをしていた方に、新しいPCにつないでくださいと連絡したところ、なんと接続できないという連絡が！？

画面をシェアしてもらうと、次のメッセージが。

Web アカウントを使用してリモートコンビューターにサインインする場合は 、 コンビューター名に NetBIOS ドメイン名または完全修飾ドメイン名 (FQDN) を指定する必要があります 。 IPアドレスの使用はサポートされていません 。

マジか！？　

Azure AD参加したPCにAzure ADアカウントでサインインしていると、Azure ADアカウントでリモート接続する必要があります。以前は、リモートデスクトップ接続の設定ファイルで調整していたような気もするけれど、現在は、リモートデスクトップ接続の詳細設定に「Webアカウントを使用して、リモートコンピューターにサインインする」というオプションがあり、これにチェックを入れるだけで、Azure ADアカウントでサインインできます。

新しいPCの設定は、コンピューター名でリモートデスクトップ接続して行っていたため問題ありませんでした。

そういえば、テレワークPCから接続テストをした際に、一回このメッセージが出たけれど、解消したような気がしていました。既に社内でAzure ADのサインインに切り替えたPCがあった気がするけれど、あれは一体、どうやって接続しているのか？

hostsで解決

それはすぐにはわからないし、FQDNが必要と言ってるんだから、とりあえずhostsファイルに、次のように追加してみました。

192.168.1.2    pc.example.com

そしたら、とりあえず接続した後、ユーザー認証を求められ、ほっと一安心。だがしかし！、そのあと、今度は得体のしれないエラーメッセージが表示されました。

サインインできませんでした。このエラーが解決されない場合、システム管理者に連絡して、エラーコードXXX99999 をお知らせください。

サーバーメッセージ：　The target-device identifier in the request pc.example.com was not found in the tenant xxxx.

えっ、これって、クラウド上の365かAzureになにかしらの情報がないとだめってことでは？　そんなの簡単にできません、というかできるかどうかもわかりません。エラーコードを検索しても、全然関係なさそうな情報しかヒットしません。

これはやばい、新しいPCだとテレワークできません、なんて話になったら、えらいこっちゃです。今からPCを戻すわけにもいかないし、従来通り、ローカルアカウントで接続するのも容易ではありませんし、そんなことしたくありません。

というわけで、ダメもとで、今度はLMHOSTSの方に、次のように行を追加して試したところ、なんとすんなり接続できました！　ほっと一安心です。

192.168.1.2    pc

そして先ほど、自宅のテレワークPCから接続する際に、もしかしてhostsでもいけるのでは？と思い、試してみたところ、なんといけました。ドメインを付けずにホスト名だけ書けば、lmhosts でも hosts でも問題ないようです。

lmhosts よりは hosts の方がわかりやすいので、Intune を使ってhosts を配布する方向で対応しようと思っています。もしくは社内に社内用のDNSを立てるかです。

Azure ADアカウントからAzure ADアカウントはOK

2023-07-06 追記

今週、リモートデスクトップ接続でもう一台PCをセットアップしながら、Webアカウントによるサインインを使っていないのにサインインできていることに気が付きました。

どうやら、ローカルPCにAzure ADアカウントでサインインしていると、Webアカウントによるサインインを有効にしなくても、リモートのAzure ADアカウントにサインインできるらしい。以前テストしたときには、おそらくこれにより問題が起こらなかったのでしょう。

Azure ADからAzure ADだと、最初のログイン時の資格認証を使うため、Webアカウントによるサインインを回避できるのかもしれません。

検証したわけではないので、マユツバ情報として。

2023-07-16 追記

結局その後、再度、Azure ADでサインインしたPCからAzure AD参加PCにAzure ADで、Webアカウントなしで接続しようとしたところ、接続できませんでした。切り分けができていませんが、とりあえずWebアカウントを有効にして接続することにしました。

2023-08-01 追記

やはり、Webアカウントオフでもつながる時がありました。どういう条件なのか不明ですが。

とりあえずIntuneによるhosts配布になりそう

2023-07-06 追記

DNSは使わずにとりあえずIntuneによるhostsファイルになりそうです。

DNSを立てること自体はできるけれど、将来的な負担はどうしてもDNSの方が上です。停止したときにどうするかなど。

今週は、レジストリー配布方法を習得したので、次はファイルの配布に挑戦です。ファイル配布は、単純に copy や xcopy で行けそうですが、コピー先のアクセス権を維持してとなると厄介そうです。

となると、PowerShell のClear-ContentとAdd-Contentを組み合わせて作るか、type の結果を、できるかどうかわからないけれど、リダイレクトしてコピー先に書き込んだ方が良さそうな気がしてきました。