☰

Kerberos シングル サインオン (SSO) を無効にできません

tag-icon • tag-icon active-directory iis-7.5 kerberos single-sign-on
Kerberos シングル サインオン (SSO) を無効にできません

私は、Windows ドメイン内で内部的にホストされている Web アプリケーションの NTLM を置き換えるために、Kerberos シングル サインオン (SSO) を検討してきました。

テスト サービス (setspn -s) のサービス プリンシパル名 (SPN) を作成した後、Fiddler または WireShark を使用して、認証が NTLM から Kerberos に切り替わったことを明確に確認できます。

慎重なインフラストラクチャ チームを擁する私は、変更を迅速かつ簡単に取り消すことができることを証明したいと思います。Web サーバー構成を通じて NTLM を強制することは望んでいません。それに応じて、SPN が削除され (setspn -d)、その削除が確認されます (setspn -q)。

次のコマンドを実行して、クライアント上のすべてのサービス チケットを削除します。

C:\>klist purge

Current LogonId is 0:0x521ac
        Deleting all tickets:
        Ticket(s) purged!

C:\>

Web アプリケーションとのさらなるやり取りが発生すると、別のサービス チケットが作成され、Kerberos が引き続き SSO 認証メカニズムとして使用されます。これは、以前にサービスを使用していないユーザーにも当てはまります。これは、すべてのやり取りが一晩中アイドル状態 (12 ～ 14 時間) だった翌日でも同様です。

観察された持続性の説明を見つけるために何度も検索しましたが、何も見つかりませんでした。しかし、この記事で手がかりを見つけたと思います。LsaLookupSids関数は、ユーザー名が変更された場合、新しいユーザー名ではなく古いユーザー名を返すことがあります。:

ローカル セキュリティ機関 (LSA) は、SID とユーザー名のマッピングをドメイン メンバー コンピューターのローカル キャッシュにキャッシュします。キャッシュされたユーザー名は、ドメイン コントローラーと同期されません。ドメイン メンバー コンピューターの LSA は、最初にローカル SID キャッシュを照会します。既存のマッピングがローカル SID キャッシュに既に存在する場合、LSA はドメイン コントローラーを照会する代わりに、キャッシュされたユーザー名情報を返します。この動作は、パフォーマンスを向上させることを目的としています。

キャッシュ エントリはタイムアウトしますが、アプリケーションによる繰り返しのクエリによって、既存のキャッシュ エントリがキャッシュ エントリの最大有効期間にわたって存続する可能性があります。

キー配布センター (KDC) が同様の方法で SPN エントリをキャッシュするかどうかを確認できる方 (または別の説明を提供できる方) はいらっしゃいますか? もしそうなら、キャッシュ エントリの最大有効期間はどれくらいですか?

答え1

問題を発見しました。サービスの DNS レコードは「A」レコードではなく、実際には「CNAME」レコードでした。これは、ブラウザがサービス アカウントのキーを作成していたことを意味します。これは、サイト/サーバーの「useAppPoolCredentials」設定が「False」(デフォルト) に設定されていたことに関係しています。変更を加えていた SPN は、実行されていた Kerberos 認証に参加していませんでした。

関連情報