ちょっと前に、SharePoint MVP 受賞の技術者 (M男) と、SharePoint の認証方式と、リクエストヘッダからユーザー ID が読み出せるかどうかについて、このような会話がありました。
私「今回は外部からのアクセスは HTLM 認証なので、HTTP ヘッダにはユーザー名が含まれている。内部からのアクセスの場合、Kerberos 認証なので HTTP ヘッダには含まれない」
M男「Kerberos 認証でも含まれるはずだから取得できるよ」
私「Kerberos はチケット方式なので、暗号化されたチケットがあるだけで、何が入ってても読み取れない」
M男「絶対入ってるよ。だから読み出せる」
どちらが正しいか
結論から言うと、
・NTLM 認証の場合、公開された技術情報に基づいてデコードすることで、認証の成否にかかわらず、指定されたユーザー ID を取得することができます。
・Kerberos 認証の場合、サーバーがデコードする前である HTTP ヘッダの段階では、ユーザー ID はおろか、いかなるデータも読み取ることはできません。認証成功後の環境変数を使う必要があります。
しっかりと、NTML 認証と Kerberos 認証の違いを認識しましょう。
NTLM 認証の場合
NTLM 認証のシーケンスはこの通りです
(1) クライアント (ブラウザ) からサーバーに認証情報無しでリクエストを送る
(2) サーバーは 401 を返して、WWW-Authenticate: NTLM ヘッダを返す
(3) クライアントは下記のように Authorization ヘッダに NTLM ネゴシエーションメッセージを送る
Authorization: NTLM [base64 文字列]
(4) サーバーは “WWW-Authenticate” ヘッダにチャレンジコードを送る
WWW-Authenticate: NTLM [base64 チャレンジコード]
(5) クライアントは自身のパスワードでハッシュを作り、レスポンスコードを返す。
Authorization: NTLM [base64 レスポンスコード]
この時、(3)(5) にはユーザー名が含まれています。NTLM の公開された仕様に基づいてデコードすることで、ユーザー ID (domain\user) を取得できます。
Kerberos 認証の場合
Kerberos 認証のシーケンスはこの通りです
(1) クライアント (ブラウザ) からサーバーに認証情報無しでリクエストを送る
(2) サーバーは 401 を返して、WWW-Authenticate: Negociate ヘッダを返す
(3) クライアントが Active Directory にサービスチケットを要求する
(4) Active Directory はサービスに紐づいた SPN アカウントのパスワード (から作られる鍵) で、チケットを暗号化してクライアントに返す
(5) クライアントは IIS に HTTP の Authorization ヘッダを通してサービスチケットを渡す
Authorization: Negotiate YIIg8k…..NBuU=
(6) IIS はサービスチケットを SPN アカウントのパスワード (から作られる鍵) で、チケットを複合化し、ユーザーの正当性を確認する
この時、(5) のチケットにユーザー ID は含まれますが、そもそも暗号化されているので、HTTP ヘッダのレベルでは単なるバイナリ文字列になっていて読み取ることはできません。
というわけです。
参考までにトリビア
どちらを使ってるのか識別する方法。
① IIS のログに違いが出ます。
NTLM 認証の場合、IIS のログは URL のリクエストごとに
401,401,200 …
が繰り返されます。
Kerberos 認証の場合、IIS のログは URL のリクエストごとに
401,200 …
が繰り返されます。ユーザー認証のためにサーバーと AD は通信しません (サーバー負荷が軽くなる)。
② それぞれ認証情報を送る最後の Authorization ヘッダに下記の違いが出ます。
Kerberos 認証: Negotiate YIIg8k…..NBuU= (YII から始まる文字列)
NTLM 認証: NTLM TlRMT… (TlRM から始まる文字列)
③ アクセスの負荷を上げていくと、NTLM を設定したサイトからレスポンスが悪くなります。
NTLM 認証 の場合、IIS にある AD とのNTLM 認証待ちセマフォが 2 つ (同時にさばけるスレッドが 2 スレッド) のため、そこのキャパを超えたころに待ち行列が出ます。なお、サーバーを増強しても改善しづらいです (レジストリ変更で改善します)。
Kerberos 認証の場合、そもそも IIS と Acctive Directory は通信しないため、NTLM のようなボトルネックは発生しません。ほとんどの場合、Kerberos のほうが IIS の認証負荷が軽くなります。