今回、タイトルのネタで話題になり調べてみたので、残しておこうと思います。
Kerberos 認証の場合
こちらのドキュメントにあるように、
- ログオン先端末の所属するドメインのドメインコントローラ (DC) で認証を試行する
- 当該 DC には、該当のユーザーはいないので、信頼関係先のドメインの DC の情報を得る
- ログオン先端末から、信頼関係先のドメインの DC へ認証を行う
- 認証が成功し、ログオンができる
という流れになります。
まったく同じケースではないですが、こちらの一番下の図が分かりやすいと思います。
NTLM 認証の場合
話題になったのはこちらでした。一例としては、xxx\user01 といった形でログオンする場合です。
結論から行くと、下記のような流れになります。
- ログオン先端末の所属するドメインの DC で認証を試行する
- 当該 DC には、該当のユーザーはいないので、当該 DC から信頼関係先のドメインの DC へ 認証を転送する (パススルー認証)
- 認証が成功し、当該 DC からログオン先端末へレスポンスを返す
- ログオンができる
参考情報ですが、Windows Server 2000 のリソースキット (No.4, P.27) に下記の記載がありました。
クライアントが NTLM 認証プロトコルを使用している場合、認証のための最初の要求は、
クライアントからターゲットドメインのリソースサーバーに直接渡されます。このサーバーは
そのコンピュータアカウントドメインのドメインコントローラにユーザーのセキュリティ
赤生と情報を送信します。ドメインコントローラは、そのセキュリティアカウントデータべースに
クライアントのユーザーアカウントを照会します。アカウントが存在しない場合は、ドメインコントローラは
次のロジックを使ってパススルー認証を実行し、その要求を転送するか、その要求を拒否します。
■現在のドメインはそのユーザーのドメインと直接的な信頼関係がありますか。
・「はい」の場合、ドメインコントローラは、パススルー認証のためにユーザーの
ドメインのドメインコントローラにクライアントの認証情報を送信します。
・「いいえ」の場合は、次の手順に進みます。
■現在のドメインはそのユーザーのドメインと推移的な信頼関係がありますか。
・「はい」の場合は、信頼パスの次のドメインに認証要求を渡します。このドメイン
コントローラは、そのセキュリティアカウントデータベースにユーザーの認証情報を
照会し、再び処理を開始します。
・「いいえ」の場合は、ログオン拒否メッセージをクライアントに送信します。
また、こちらの MS ドキュメントも参考になると思います。
https://technet.microsoft.com/pt-pt/library/cc773178(v=ws.10).aspx
https://msdn.microsoft.com/en-us/library/cc237016.aspx
今回、実際うろ覚えなものも多く、あらためて勉強になりました。