Kerberos は、ユーザーまたはホストの身元を確認するために使用される認証プロトコルです。 このトピックには、Windows Server および Windows での Kerberos 認証に関する情報が含まれています。
Windows Server オペレーティング システムには、公開キー認証、承認データの転送、委任のために、Kerberos Version 5 認証プロトコルと拡張機能が実装されています。 Kerberos 認証クライアントはセキュリティ サポート プロバイダー (SSP) として実装され、セキュリティ サポート プロバイダー インターフェイス (SSPI) を使用してアクセスできます。 初回ユーザー認証は Winlogon シングル サインオン アーキテクチャと統合されます。
Kerberos キー配布センター (KDC) は、ドメイン コントローラーで実行されている他の Windows Server セキュリティ サービスと統合されます。 KDC では、そのセキュリティ アカウント データベースとして、ドメインの Active Directory Domain Services データベースを使用します。 ドメインまたはフォレスト内の既定の Kerberos 実装には、Active Directory ドメイン サービスが必要です。
Kerberos認証の仕組み
Kerberos認証には、セキュリティプリンシパルとして行動するクライアント、プリンシパルが到達したいサービス、そして両者が信頼する鍵配布センター(KDC)の3者が関与します。 セキュリティプリンシパルとは、システムが認証できるユーザー、コンピュータ、サービスなどのアイデンティティのことです。 Windows Serverでは、KDCはすべてのドメインコントローラーで動作し、そのドメインのActive Directory Domain Servicesデータベースをアカウントデータベースとして使用します。
ユーザーがサインインすると、KerberosクライアントはKDCに連絡し、ユーザーの身元を証明し、チケット付与チケット(TGT)を取得します。 TGTは、クライアントがユーザーのパスワードを再度提示することなくサービスへのアクセスを要求できる認証情報です。 クライアントはTGTをチケットキャッシュに保存し、チケットの有効期限が切れるまで再利用します。
サービスに接続するために、クライアントは自身のTGTをKDCに提示し、その特定のサービスに対するサービスチケットを要求します。 KDCはサービスチケットを返し、クライアントはそれを直接ターゲットサービスに提示します。 チケットにはクライアントの本人確認に必要な情報がすでに含まれているため、サービスは各接続ごとにドメインコントローラーに連絡することなくクライアントを認証できます。
Windows Serverは、インターネット工学タスクフォース(IETF)が定義した業界標準のKerberosバージョン5プロトコルを実装しています。 この標準トラックの基盤により、Windows実装はKerberosを使用する他のシステムと相互運用可能です。 標準に加えて、Windowsは公開鍵認証、認可データの伝送、委任のための拡張機能を追加しています。 MicrosoftはこれらのWindows特有の動作をWindowsプロトコル仕様[MS-KILE]: Kerberos Protocol Extensionsに記録しており、Windows実装が標準からどこを拡張または異なるかを記述しています。
実際の適用例
ドメインベースの認証に Kerberos を使用することで得られる利点については、次のセクションで説明します。
委任された認証
Windows オペレーティング システムで実行されるサービスは、クライアントの代わりにリソースにアクセスするとき、クライアント コンピューターを偽装できます。 多くの場合、サービスは、ローカル コンピューター上のリソースにアクセスしてクライアントに対する処理を完了できます。 クライアント コンピューターがサービスに対して認証を行うとき、NTLM と Kerberos プロトコルは、サービスがクライアント コンピューターをローカルに偽装するために必要な承認情報を提供します。 ただし、分散アプリケーションによっては、フロントエンド サービスが他のコンピューター上のバックエンド サービスに接続するときに、クライアント コンピューターの ID を使用する必要があるように設計されていることもあります。 Kerberos 認証は、サービスがクライアントの代わりとして他のサービスに接続できる委任メカニズムをサポートしています。
シングルサインオン
ドメイン内またはフォレスト内で Kerberos 認証を使用すると、ユーザーまたはサービスは、管理者によって許可されたリソースに、資格情報を繰り返し要求されることなくアクセスできます。 最初に Winlogon を使用してドメインにサインオンした後は、フォレスト内でリソースへのアクセスが試行されるたびに、Kerberos が資格情報を管理します。
Interoperability
マイクロソフトによる Kerberos V5 プロトコルの実装は、インターネット技術標準化委員会 (IETF) に対して推奨されている標準トラック仕様に基づいています。 そのため、Windows オペレーティング システムでは、Kerberos プロトコルが認証に使用される他のネットワークとの相互運用性に対しては、Kerberos プロトコルが基盤になります。 さらに、Microsoft は、Kerberos プロトコルを実装するために Windows プロトコルのドキュメントを公開しています。 このドキュメントには、Microsoft による Kerberos プロトコルの実装に関する技術的な要件、制限事項、依存関係、および Windows 固有のプロトコルの動作が含まれます。
サーバーに対するより効率的な認証
Kerberos の前は NTLM 認証を使用できましたが、アプリケーション サーバーはすべてのクライアント コンピューターやサービスを認証するためにドメイン コント ローラーに接続する必要がありました。 Kerberos プロトコルでは、更新可能なセッション チケットがパススルー認証の代わりになります。 サーバーは、特権属性証明書 (PAC) を検証する必要がない限り、ドメイン コントローラーに移動する必要はありません。 その代わりに、サーバーは、クライアント コンピューターから提示された資格情報を調べてクライアントを認証できます。 クライアント コンピューターは特定のサーバーに対する資格情報を一度入手したら、それをネットワーク ログオン セッション全体で再利用できます。
相互認証
Kerberos プロトコルを使用すると、ネットワーク接続の一方のエンティティは、相手側が本物のエンティティであることを検証できます。 NTLM では、クライアントがサーバーの ID を検証したり、サーバーが別のサーバーの ID を検証することはできません。 NTLM 認証は、サーバーが本物であることが前提となっているネットワーク環境向けの方式でした。 Kerberos プロトコルにはこのような前提はありません。
暗号化の種類
Windows Server 2025 以降、Kerberos は、パス HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Lsa\Kerberos\Parameters にあるレガシ レジストリ キー REG_DWORD SupportedEncryptionTypes を認識しなくなりました。 代わりにグループ ポリシーを使用することをお勧めします。 グループ ポリシー設定の詳細については、「 ネットワーク セキュリティ: Kerberos で許可される暗号化の種類を構成する」を参照してください。