今回、タイトルのネタで話題になり調べてみたので、残しておこうと思います。

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

今回、実際うろ覚えなものも多く、あらためて勉強になりました。