Kerberos 認証とは、ネットワーク認証方式の一つです。
Active Directory のドメイン環境では、ユーザーやコンピューターなどのリソースを一元的に管理できますが、その際の認証方式の基盤は Kerberos 認証で実現されています。Kerberos 認証の仕組みによりシングル サインオン(SSO)が実現でき、一度の認証でドメイン内にある様々なリソースにアクセスできるようになります。
Kerberos 認証では認証されたことを示すチケットが発行され、サーバーへアクセスする時はそのチケットを提示して接続します。チケットは共通鍵暗号方式の仕組みを使って暗号化されており、共通鍵をもっている端末でないとチケットは利用できず、Kerberos 認証に失敗します。
今回は Kerberos 認証にて使用されるチケットや認証フローの詳細な仕組みについて紹介します。
Kerberos 認証とは？
Kerberos(ケルベロス)認証とはネットワーク認証方式の１つで、Active Directory ドメイン サービスでメインで利用されている認証方式です。MIT で開発された認証方式で、「RFC 4120」で標準化されており、認証方式の名前はギリシャ神話にでてくる「地獄の番犬ケルベロス」(頭が３つあるキモい犬)から由来しています。現在は、Kerberos バージョン５が主に使用されています。
Kerberos 認証の特徴としては、接続元のクライアントと接続先のサーバーの両方とも認証できる仕組み(相互認証)となっています。Kerberos 認証では、ID/パスワードまたは証明書などでクライアントの認証が完了した後、認証されたことを示すチケットを発行し、サーバーへアクセスする時はチケットを提示して接続します。一度取得したチケットは保存して利用できるため、サーバーに接続する時に再度ユーザーへの認証が求められることはありません。
Kerberos 認証の基本的な仕組みや認証フローの概要については、以下の記事で紹介しています。
Kerberos 認証とは、ネットワーク認証方式の一つです。 Active Directory のドメイン環境では、ユーザーやコンピューターなどのリソースを一元管理できますが、その際の認証方式の基盤は Kerberos 認証で実現されていま[…]
Kerberos 認証で使われる暗号鍵
Kerberos 認証の認証フローでは、Kerberos チケットという認証に成功した証明となるチケットが利用されます。
発行されたチケットは、「発行の要求をしたアカウント」(＝ユーザー プリンシパル)と「利用したいサービスを提供している端末」(＝サービス プリンシパル)のみで利用できる仕組みとなっています。その仕組みのために、共通鍵暗号方式が利用されています。Kerberos 認証では複数の共通鍵を生成して、ユーザー プリンシパルとサーバー プリンシパルの両方を正当性を確認できるようになっています。
Kerberos 認証で使用される共通鍵の一覧は以下の通りです。
| User Key | ユーザー プリンシパルのアカウントのパスワードをもとに生成 |
| TGS Key | Krbtgt アカウントのパスワードをもとに生成 |
| Service Key | SPN が紐づけられたサービス アカウントのパスワードをもとに生成 |
| TGS Session Key | TGT 取得の結果、生成されるキー |
| Session Key | サービス チケットの取得の結果、生成されるキー |
各共通鍵が Kerberos 認証において、どのように利用されるのか紹介します。
Kerberos 認証の流れ
Kerberos 認証では、KDC から TGT とサービス チケットを発行して認証が行われます。認証フローにて使用される各鍵の利用用途の概要は以下の通りです。
本記事では、以下の通り暗号鍵の種類ごとに色を分けて表現します。
各暗号フローの詳細は以下の通りです。
AS Request
接続元のクライアント(ユーザー プリンシパル)が、KDC の AS に対して TGT の発行を要求します。TGT とは、認証の対象であるユーザー プリンシパルが本人であることを証明するチケットです。
クライアント側の端末では、ユーザーが入力したパスワードをもとにして User Key と呼ばれる鍵を生成します。生成した User Key を時刻情報を暗号化し、「事前認証データ」と呼ばれる情報を作成します。クライアントは事前認証データを AS Request に含めて KDC に送信します。
AS Response
KDC の AS は TGT の発行要求(AS Request)を受け取ったら、要求に含まれる認証情報をもとにユーザーの認証を行います。認証情報によりユーザーの正当性の確認がとれたら、KDC は TGT を発行してクライアント(ユーザー プリンシパル)へ送信します。
AS Request を受け取った KDC は、AS Request に含まれるアカウント名をもとに、AD データベースに該当のアカウント名をもつ AD オブジェクトを検索します。該当する AD オブジェクトがみつかったら、その AD オブジェクトのパスワードをもとに User Key を生成します。生成した User Key を用いて、暗号化された事前認証データを復号します。User Key はアカウントのパスワードをもとに生成されているため、事前認証データを正常に復号できたら、クライアントは KDC で管理している AD アカウントと同じパスワードをもっていることが証明できます。そのため、クライアントの認証は成功したことになります。
クライアントの認証に成功したら、AS Response にて発行した TGT と TGS Session Key を送信します。TGS Session Key とは、KDC がこの Kerberos 認証のセッション用に生成した鍵で、TGS Request にて使用します。TGS Session Key は User Key にて暗号化されており、クライアントしか使用できない仕組みとなっています。
KDC では Krbtgt アカウントのパスワードをもとに生成した TGS Key を保持しています。TGT には、TGS Session Key や User Credential などの情報が含まれています。ここでの User Credential とは、ユーザーの SID とユーザーが所属するグループの SID の情報となります。発行された TGT は、TGS Key で暗号化されて送信されます。
TGS Request
接続元のクライアント(ユーザー プリンシパル)は、KDC の SGT に対してサービス チケットの発行を要求します。TGS Request には、利用するサービスを指定するために SPN(Service Principal Name) を指定します。
AS Response を受け取ったクライアントは、TGS Session Key と TGT を入手した状態となります。TGS Session Key は User Key で復号して、鍵が利用できるようになります。サービス チケットを要求する際には、ユーザー認証を完了していることを示すために、TGS Request に TGT を含めて送信します。
TGT だけでは中間者攻撃により攻撃者が不正に TGT を入手している可能性は否定できないため、本人確認の証明書としては十分ではありません。TGS Request の送信元の身元を証明するために、TGT と合わせて Authenticator という送信元の認証に使用できるデータを送信します。Authenticator とは、時刻情報やシーケンス番号などのデータを TGS Session Key で暗号化したものです。TGS Session Key は KDC と同じ User Key を保持していないと利用できないため、「TGS Session Key が利用できる」＝「ユーザー認証されている」ことを証明しています。
TGS Response
KDC の TGS はサービス チケットの発行要求(TGS Request)を受け取ったら、まず TGT に問題がないことを確認します。TGT に問題がないことの確認がとれたら、TGS Request に指定されている SPN を確認し、対象のサービスへアクセスするためのサービス チケットを発行します。サービスチケットを発行したら、接続元のクライアント(ユーザー プリンシパル)に送信します。
TGS Request を受け取った KDC の TGS は、AD データベースから TGS Request に含まれる SPN に紐づく AD アカウントを探します。該当の AD アカウントがみつかったら、その AD オブジェクトのパスワードをもとに Service Key を生成します。
TGS Request を受け取った KDC の TGS は、Authenticator と TGT を検証します。Authenticator が TGS Session Key で復号できたら、TGT と合わせて「ユーザー認証されている」ことが確認できます。クライアントが「ユーザー認証されている」ことが確認できたら、TGS Response にて発行したサービス チケットと Session Key を送信します。
Session Key とは、KDC がこの Kerberos 認証のセッション用に生成した鍵で、AP Request にて使用します。Session Key は TGS Session Key にて暗号化されており、クライアントにしか使用できない仕組みとなっています。
サービス チケットには、Service Key や User Credential などの情報が含まれています。
ここでの User Credential とは、ユーザーの SID とユーザーが所属するグループの SID の情報となります。
発行されたサービスチケットは、Service Key で暗号化されて送信されます。
AP Request
接続元のクライアント(ユーザー プリンシパル)は、KDC から発行されたサービス チケットをサービスを提供しているサーバーに提示して、サービスの利用を要求します。
TGS Response を受け取ったクライアントは、Session Key とサービス チケットを入手した状態となります。Session Key は TGS Session Key で復号して、鍵が利用できるようになります。サービスの利用を要求するために、AP Request にサービス チケットを含めて送信します。
サービス チケットだけでは中間者攻撃により攻撃者が不正にサービス チケットを入手している可能性は否定できません。AP Request の送信元がクライアントの身元を証明するために、TGT と合わせて Authenticator という送信元の認証に使用できるデータを送信します。Authenticator とは、時刻情報やシーケンス番号などのデータを Session Key で暗号化したものです。Session Key は、TGS Session Key を保持していないと利用できません。GS Session Key で暗号化したものです。TGS Session Key は KDC と同じ User Key を保持していないと利用できないため、「TGS Session Key が利用できる」＝「ユーザー認証されている」ことを証明しています。
AP Response
サービスを提供しているサーバーは、クライアント(ユーザー プリンシパル)から提示されたサービス チケットを検証します。サービス チケットに問題がなければ、クライアントに利用を許可します。
AP Request を受け取ったサービス プリンシパルのサーバーは、送信されたサービス チケットと Authenticator を検証します。サービス チケットは Service Key で暗号化されているため、サービス アカウントのパスワードから Service Key を生成してサービス チケットを復号します。正常に復号できたらサービス チケットは問題ありません。
また、サービス チケットには Session Key が含まれているため、Authenticator のデータを復号できるか確認します。サービス チケットと Authenticator が復号できたら、Kerberos 認証として成功したことになります。
サーバーは AP Response にて Kerberos 認証に成功したことを示す結果を応答します。また、サーバーの正当性を証明するために、相互認証データとして Authenticator に含まれていた時刻情報を Session Key で暗号化したデータを送信します。相互認証データにより、AP Request を送信した端末であること、また、Service Key を持っている端末であることを証明できるため、サービス プリンシパルとしての正当性が保証できます。
これで Kerberos 認証は完了です。クライアントはサービスを利用できるようになります。
Kerberos 認証で利用されるアルゴリズム
Kerberos 認証では認証の一連のフローにて、共通鍵暗号化方式が利用されています。Kerberos 認証に利用可能な暗号化アルゴリズムや鍵長の一覧は以下の通りです。
| 暗号化アルゴリズム | 鍵長 | サポートする OS バージョン |
| AES256-CTS-HMAC-SHA1-96 | 256 bit | Windows 7 / Windows Server 2008 R2 以降 |
| AES128-CTS-HMAC-SHA1-96 | 128 bit | Windows Vista / Windows Server 2008 以降 |
| RC4-HMAC | 128 bit | Windows 2000 Server 以降 |
| DES-CBC-MD5 | 56 bit | Windows 2000 Server 以降 |
| DES-CBC-CRC | 56 bit | Windows 2000 Server 以降 |
Kerberos 認証で使用されるアルゴリズム関連の設定
Windows OS のバージョンにより、利用可能な Kerberos 認証の暗号化アルゴリズムは異なっています。ドメイン環境には様々な OS バージョンの端末があるため、Kerberos 認証の要求をする際には自身が利用可能な暗号化アルゴリズムを通知して、認証においては共通で利用可能な暗号化アルゴリズムを使用します。
Windows OS では、使用できる暗号化アルゴリズムを制限するための設定が複数用意されています。暗号化アルゴリズムの種類により暗号化の強度が異なるため、セキュリティ ポリシーにあわせて設定を変更することができます。
Kerberos 認証に使用される暗号化アルゴリズムに関する設定項目の一覧は以下の通りです。
SupportedEncryptionTypes
コンピューターがサポートする暗号化アルゴリズムのタイプを指定する設定です。SupportedEncryptionTypes の設定は、以下のポリシーにて設定することができます。
ポリシー：[ネットワーク セキュリティ：Kerberos で許可する暗号化の種類を構成する]
設定値：[これらのポリシーの設定を定義する] のチェックボックスを有効
有効する暗号化アルゴリズムのタイプのチェックボックスを有効
・KDC 側で生成される User Key、Service Key の暗号化アルゴリズムに影響します
・KDC 側で生成される TGS Key の暗号化アルゴリズムに影響します。そのため、発行される TGT の暗号化アルゴリズムにも影響します
ユーザー プリンシパルが送信する AS Request、TGS Request にて提示する利用可能な暗号化アルゴリズムの一覧(ReqBody – Etype)に影響します
AD データベースで管理されているサービス アカウントの msDS-SupportedEncryptionTypes の設定に影響。そのため、Session Key の暗号化アルゴリズムにも影響します
DefaultEncryptionType
クライアントが KDC に AS Request にて、事前認証データを暗号化する時の暗号化方式を指定するレジストリです。
名前: DefaultEncryptionType
種類: REG_DWORD
〇 aes128-cts-hmac-sha1-96 の場合は 0x11(17)
KdcUseRequestedEtypesForTickets
KDC で選択される暗号化アルゴリズムの動作を変更するためのレジストリです。
既定では TGT やサービス チケットは、KDC(ドメイン コントローラー)がサポートする暗号化タイプのうち最も強度が高いものが選択されます。レジストリ KdcUseRequestedEtypesForTickets の設定値を 1 に設定すると、クライアントが提示した暗号化アルゴリズムのうち一番上にある暗号化アルゴリズムで TGT やサービス チケットを暗号化する動作となります。
名前: KdcUseRequestedEtypesForTickets
種類: REG_DWORD
設定値：1
UserAccountControl
アカウントに紐づく User Key あるいはサービス チケットの暗号化アルゴリズムを DES のみに限定する設定です。
ユーザー アカウントの [アカウント] タブの [アカウント オプション] にて [このアカウントに Kerberos DES 暗号化のみを使う] を有効にすると、UserAccountControl 属性にて 0x200000 (UF_USE_DES_KEY_ONLY) の bit が有効になります。
ms-DSSupportedencryptionTypes
ユーザー アカウントの [アカウント] タブの [アカウント オプション] にて [このアカウントに Kerberos AES 128 ビット暗号化をサポートする]、[このアカウントに Kerberos AES 256 ビット暗号化をサポートする] を有効にすると、ms-DSSupportedencryptionTypes 属性に設定されます。
上記のオプションを設定すると、ms-DSSupportedencryptionTypes 属性に以下の通りに設定されます。
| アカウント オプションの項目 | 設定値 | フラグ |
| このアカウントに Kerberos AES 128 ビット暗号化をサポートする | 0x8 | AES128_CTS_HMAC_SHA1_96 |
| このアカウントに Kerberos AES 256 ビット暗号化をサポートする | 0x10 | AES256_CTS_HMAC_SHA1_96 |
Kerberos 認証フローのパケット
Kerberos 認証の一連の流れの詳細を紹介しましたが、実際にパケットではどのようなフローとなるのか紹介します。正常時の Kerberos 認証のパケット フローを把握しておくことで、Kerberos 認証に問題があった場合のトラブルシューティングに役立ちます。
Kerberos 認証のパケット フローは以下の通りです。
① クライアントがサポートする暗号化アルゴリズムの通知
Kerberos 認証の開始にあたり、まず、クライアント(ユーザー プリンシパル)がサポートしている暗号化アルゴリズムを通知します。パケット上では AP Request と表示されます。
クライアントがサポートしている暗号化アルゴリズムの一覧は、パケットの “etype” の項目より確認できます。この etype は、クライアント端末の SupportedEncryptionTypes に基づいて利用可能な暗号化アルゴリズムを通知します。
② KDC がサポートする暗号化アルゴリズムの応答
KDC がサポートする暗号化アルゴリズムをクライアントに通知する応答を返します。先ほど送信した AP Request には、事前認証データが含めず送信しているため、事前認証を要求するパケットとして KRB_ERR_PREAUTH_REQUIRED と表示されます。「ERR」という文字が含まれていますが、Kerberos 認証として問題があることを示すものではありません。
KRB_ERR_PREAUTH_REQUIRED のパケットにて、KDC が User Key として利用可能な暗号化アルゴリズムを通知します。サポートしている暗号化アルゴリズムの一覧は、パケットの “etype” の項目より確認できます。この etype は、KDC の SupportedEncryptionTypes に基づいて利用可能な暗号化アルゴリズムを通知します。
KDC のコンピューター アカウントの UserAccessControl に UF_USE_DES_KEY_ONLY フラグが指定されている場合には、DES のみが利用可能となります。この場合、ドメイン コントローラーとクライアント端末の両方の SupportedEncryptionTypes で DES のアルゴリズムをサポートしている必要があります。
③ AS Request
事前認証データとして、時刻情報を User Key で暗号化して、AS Request に含めて KDC に送信します。
事前認証データは User Key で暗号化しますが、クライアント端末の SupportedEncryptionTypes から最も暗号強度の高いものが選択されます。クライアント端末にて DefaultEncryptionType が設定されている場合には、その暗号化アルゴリズムを優先的に使用します。また、認証先の KDC から KRB_ERR_PREAUTH_REQUIRED を受け取っている場合には、KDC から通知された暗号化アルゴリズムの一覧も考慮します。
④ AS Response
AS Request を受信してアカウントの認証に問題がなかったら、AS Response にて TGT と TGS Session Key を送信します。
TGT はパケットの ticket の項目にて確認できます。発行した TGT は TGS Key で暗号化され、その際の暗号化アルゴリズムは KDC の SupportedEncryptionTypes に依存します。KDC にて KdcUserRequestedEtypesForTickets のレジストリが設定されている場合には、AS Request にてクライアントが事前認証データの暗号化に使用された暗号化アルゴリズムが優先的に使用されます。
TGS Session Key は as-rep の下の enc-part の項目にて確認できます。TGS Session Key の鍵の暗号化アルゴリズムには、AS Request で提示された暗号化アルゴリズムの一覧と、KDC の SupportedEncryptionTypes の中から最も暗号強度が高いものが選択されます。
また、TGS Session Key を User Key で暗号化する際の暗号化アルゴリズムには、事前の AS Request の事前認証データでの暗号化に使用された暗号化アルゴリズムが使用されます。
⑤ TGS Request
クライアントは TGT が入手できたら、サービス チケットを要求する TGS Request を送信します。TGT はそのまま転送し、TGS Response 用に、改めて端末がサポートしている暗号化アルゴリズムを通知します。
TGS Request では TGT はそのまま転送します(クライアント端末側では復号しません)。TGT はパケットでは ticket の項目で確認できます。また、Authenticator は TGS Session Key で暗号化して送信します。Authenticator はパケットでは authenticator の項目で確認できます。
TGS Request でも、ユーザー プリンシパルがサポートしている暗号化アルゴリズムの一覧を送信します。暗号化アルゴリズムの一覧はパケットの “etype” の項目より確認できます。この etype は、クライアント端末の SupportedEncryptionTypes に基づいて利用可能な暗号化アルゴリズムを通知します。
⑥ TGS Response
KDC は TGS Request で指定された SPN のサービス チケットを発行し、サービスチケットと Session Key を TGS Response にてクライアントへ送信します。
サービス チケットは、パケットの ticket の項目にて確認できます。サービス チケットは Service Key で暗号化されます。その暗号化アルゴリズムは、TGS Request で提示された暗号化アルゴリズムの一覧と、KDC の SupportedEncryptionTypes の中から最も暗号強度が高いものが選択されます。ただし、アクセス先となるリソース アカウントに USE_DES_KEY_ONLY のフラグが指定されている場合には DES のみが利用可能です。
Session Key はパケットの enc-part の項目にて確認できます。Session Key の暗号化アルゴリズムには、TGS Request で提示された暗号化アルゴリズムの一覧と、リソース アカウントの SupportedEncryptionTypes の中から最も暗号強度が高いものが選択されます。ただし、アクセス先となるリソース アカウントに UF_USE_DES_KEY_ONLY のフラグが指定されている場合には DES のみが利用可能です。
⑦ AP Request
ユーザー プリンシパルはサービス チケットを入手したら、AP Request にてサービス チケットを提示して、サービス アカウントのサーバーにサービスの利用を要求します。
サービス チケットはパケットでは ticket の項目にて確認できます。サービスの利用を要求するために、クライアントはサービス チケットをそのまま転送します。また、認証情報として時刻情報やシーケンス番号などのデータを Session Key で暗号化して送信します。
⑧ AP Response
サービスを提供しているサーバーは、クライアントから提示されたサービス チケットを検証します。サービス チケットに問題がなければ、クライアントに利用を許可します。
サービス プリンシパルの正当性を証明するために、相互認証データとして Authenticator に含まれていた時刻情報を Session Key で暗号化したデータを送信します。相互認証データは enc-prt の項目にて確認できます。
ポチップ
