皆さんこんにちは。国井です。
Windows 10のデバイス管理形態にAzure AD参加というのがあり、このデバイス登録を行うと、Windowsの起動時にAzure ADのアカウントを使ったサインインができるようになります。
Active Directoryドメイン参加の時はWindowsのサインイン時にADアカウントを利用していたわけですから、Active Directoryドメイン参加のAzure AD版、そんな感じの管理形態です。
ADドメイン参加をやめてAzure AD参加を利用しましょうという話の時によく出てくるのが
ドメイン参加のサーバーにアクセスできなくなるのでは?
という話です。
ところが、Azure AD参加しているデバイスはWindowsのサインイン時にAzure AD Connectで同期されたユーザーでサインインしていれば、自動的にADドメインのユーザーとみなしてアクセスを認めます。
しかしこの話、何かおかしくありませんか?
だってActive Directoryの認証・認可をするときはADのDNSサーバーにアクセスしてドメインコントローラーの場所を見つけて認証を開始.. のようなプロセスがあるはずなのに、
Azure AD参加デバイスはAD用のDNSサーバーなど全く使っていません。
じゃあ、どうやってADにアクセスして認証しているのでしょうか?
そこで、今回はAzure AD参加デバイスにWireSharkをインストールしてアクセスをしてみました。さらにWindows Serverを2台用意して、1台をドメインコントローラー(192.168.1.175)、もう1台をファイルサーバー(192.168.1.176)にしてみました。
Azure AD参加しているクライアントコンピューター(192.168.1.6)でWireSharkを実行して、ファイルサーバーの共有フォルダー(\\fs16\adfs)にアクセスした様子をパケットキャプチャしてみました。
共有フォルダーにアクセスするときは認証画面など一切出てくることなくアクセスできましたが、裏の動きはどうなっているのでしょうか?見てみましょう。
まずWireSharkのConversationsという機能を使ってクライアントがどのようなIPと通信しているか確認しました。すると全くドメインコントローラーとの通信は発生していないことがわかりました。
次に名前解決について。\\fs16というUNCパスを指定していますが、どうやって名前解決しているのでしょうか?
192.168.1.6 <==> 192.168.1.176 でフィルターをかけてパケットを見てみると、最初のやり取りでLLMNR(UDP5355)というパケットのやり取りがあることがわかります。
LLMNRとは通信相手となるコンピューターの名前解決を行うプロトコルで、確かWindows Vistaあたりから実装された名前解決方法です。
名前解決が終わるとファイル共有へのアクセスを行うべく、SMBプロトコル(TCP445)を使った通信を開始します。
そして認証プロセスは.. ご想像のとおりNTLMを利用していることがわかります。NTLM認証の場合、Kerberosプロトコルを使った認証と異なり、ドメインコントローラーと直接通信しなくても認証自体が完了できてしまいます。
事実、一連の通信ではAzure AD参加デバイスとドメインコントローラー間の通信は一切発生していません。
最後にドメインコントローラーのイベントビューアを見てみます。すると、NTLM認証が発生したタイミングでセキュリティログに下のようなイベントを残していました。
きちんとAzure AD参加デバイスでWindowsサインイン画面で入力したユーザー名と同名のActive Directoryドメインのユーザーと認識し、サインインが成功していることがわかります。
Azure AD参加デバイスがWindowsサインインするときはAzure ADに登録されたユーザー名でサインインしますが、そのユーザーがAzure AD ConnectによってActive Directoryから同期されたユーザーの場合、Active Directoryドメインに参加しているサーバーへのアクセスはNTLMを利用して透過的に認証し、シングルサインオンアクセスを実現していることがわかりました。
ただし、このときに気を付けたいのはNTLMv2認証を利用してアクセスをしている点です。
Active Directoryでは認証のベストプラクティスとしてKerberosを使え!NTLMを排除せよ!という考えがあり、グループポリシーでNTLM認証をブロックするように設定している会社もあるかと思います。
しかし、これを実装していると、NTLMによるサインインはブロックされてしまうのでご注意ください。
2021年2月8日追記
Azure ADからKerberosチケットを発行させ、オンプレミスのリソースにアクセスさせる方法がサポートされるようになりました。Active Directoryの認証・認可に使用するKerberosチケットであるTGT・STのうち、TGTをAzure ADから発行し、TGTをオンプレミスADに提示することでリソースアクセスに必要なSTを発行するという動きを実現するそうです。
2021年6月12日追記
参考URL:こちらもおすすめ