Kerberos 認証とは、ネットワーク認証方式の一つです。
Active Directory のドメイン環境では、ユーザーやコンピューターなどのリソースを一元管理できますが、その際の認証方式の基盤は Kerberos 認証で実現されています。Kerberos 認証の仕組みによりシングル サインオン(SSO)が実現でき、一度の認証で、ドメイン内にある様々なリソースにアクセスできるようになります。
ドメイン環境の運用や管理において、Kerberos 認証は切り離せない技術となりますので、基本的な仕組みを理解しておくことは重要です。
今回は、Kerberos 認証の基本的な仕組みについて紹介したいと思います。
Kerberos 認証とは
Kerberos(ケルベロス)認証とはネットワーク認証方式の１つで、Active Directory ドメイン サービスでメインで利用されている認証方式です。MIT で開発された認証方式で「RFC 4120」で標準化されており、認証方式の名前はギリシャ神話にでてくる「地獄の番犬ケルベロス」(頭が３つあるキモい犬)から由来しています。現在は、Kerberos バージョン 5 が主に使用されています。
Kerberos 認証の特徴としては、接続元のクライアントと接続先のサーバーの両方とも認証できる仕組み(相互認証)となっています。Kerberos 認証では、ID/パスワードまたは証明書などでクライアントの認証が完了した後、認証されたことを示すチケットを発行し、サーバーへアクセスする時はそのチケットを提示して接続します。一度取得したチケットは保存して利用できるため、サーバー接続する時に再度ユーザーへの認証が求められることはありません。
Kerberos 認証の構成要素
Kerberos 認証を仕組みを理解するにあたって、Kerberos 認証の構成要素を示す用語を紹介します。
Kerberos 認証は、基本的には以下の３者で構成されます。(構成がケルベロスっぽいですね)
〇 KDC (Key Distribution Center)
Kerberos 認証では、認証に成功した証明となるチケットが発行することで認証を実現しています。
KDC はチケットを発行する役割を持ったサーバーのことを示します。
Active Directoryドメイン サービスにおいては、ドメイン コントローラーが KDC の役割を担っています。
KDC には、以下の 2 つの役割ごとの呼び名がつけられています。
- AS (Authentication Server)
TGT という種類のチケットを発行するサーバー - TGS (Ticket Granting Server)
サービス チケット(ST)という種類のチケットを発行するサーバー
〇 ユーザー プリンシパル
ユーザー プリンシパルとは、接続元のユーザーのことです。
ユーザー「ねこねこ」がファイル サーバーのファイル共有へアクセスするシナリオの場合、ユーザー プリンシパルは「ねこねこ」となります。
ユーザー プリンシパルの識別子には、UPN(User Principal Name) を利用します。
UPN は nekoneko@nekomaru.com のような表記形式となります。
〇 サービス プリンシパル
サービス プリンシパルとは、接続先のサービスのことです。
ユーザー「ねこねこ」がファイル サーバーのファイル共有へアクセスするシナリオの場合、サービス プリンシパルは「ファイル サーバー」となります。
ただし、厳密に言うと、サービス プリンシパルはファイル サーバー自体ではなく、ファイル共有のサービスを提供しているアカウントがサービス プリンシパルです。
ファイル共有の場合は、ファイルサーバー上の Server サービスがファイル共有のサービスを提供しており、このサービスの実行アカウントはローカル システム アカウントとなります。
サービス プリンシパルの識別子には、SPN(Service Principal Name)を利用します。
SPN とは、サービス プリンシパルの名前であり、<サービス>/<プリンシパル>@<Kerberos のレルム> の形式で表記します。例えば、 cifs/sv01.nekomaru.com のような表記形式となります。
Kerberos チケット
Kerberos 認証では、KDC が認証したことを示す証明するためにチケットを発行して、認証の仕組みを実現しています。Kerberos 認証で登場するチケットとして、以下の 2 つのチケットがあります。
〇 TGT (Ticket Granting Ticket)
TGT(ティージーティーと呼びます)は、認証の対象であるユーザー プリンシパルが本人であることを証明するチケットです。
TGT は免許証のような、本人の身分証明を行えるものとなります。
〇 サービス チケット(ST)
サービス チケットは接続先のサービスにアクセスするときに必要となるチケットとなります。
美術館の入場チケットのような、サービスを利用するために必要なものとなります。
Kerberos 認証では、接続元のユーザー プリンシパルの認証のみではなく、接続先のサービスへアクセスするためのサービス チケットを発行することで、接続元と接続先の「相互認証」することができます。
サービス チケットはサービス プリンシパルのアカウントのパスワードで暗号化されているため、正当なサービス以外、チケットを正常に受領することはできません。
接続先のサービスが正常にサービス チケットを受領できたら、ユーザーだけではなく、サービス側の認証も行うことができるという仕組みになります。
Kerberos のチケットは盗聴によるなりすましを防ぐために、時刻同期の仕組みが用意されています。
チケットにはタイムスタンプ(送信時刻)が記録されており、チケットを受領したコンピューターがチケットのタイム スタンプと、端末のシステム時刻が 5 分以上のずれがあるとチケットは無効と判断されて認証は失敗します。
Kerberos 認証の流れ
Kerberos 認証では、KDC から TGT とサービス チケットを発行して認証を行う仕組みとなります。
KDC から TGT、サービス チケットを取得する時は、TCP 88 ポートの通信を利用します。
Kerberos 認証のフローは、以下の通り、[A] ～ [F] のフローで行われます。
[A] AS Request
接続元のクライアント(ユーザー プリンシパル)が、KDC の AS に対して TGT の発行を要求します。
AS Request には、認証を行うユーザーのユーザー名(UPN)、認証情報が含まれております。
上図の例では、ユーザー「ねこねこ」は KDC に対して、ユーザー名「nekoneko@nekomaru.com」の TGT を発行してくださいと要求している状況となります。
[B] AS Response
KDC の AS は TGT の発行要求(AS Request)を受け取ったら、要求に含まれる認証情報をもとにユーザーの認証を行います。認証情報よりユーザーの正当性が確認とれたら、KDC は TGT を発行してクライアントへ送信します。
上図の例では、KDC は nekoneko@nekomaru.com の TGT を発行して、ユーザー「ねこねこ」へ送信します。
[C] TGS Request
次に接続元のクライアント(ユーザー プリンシパル)は、KDC の SGT に対してサービス チケットの発行を要求します。
[A]、[B] のフローによりユーザーは本人証明となる TGT が KDC から発行されています。
サービス チケットを要求する際には、ユーザー認証は完了していることを示すために TGS Request に TGT を含めて送信します。
また、TGS Request には利用するサービス名を指定するために、SPN(Service Principal Name)を指定します。ファイル サーバー上のファイル共有を指す SPN は、cifs/<ファイル サーバー> となります。
上図の例では、ユーザー「ねこねこ」がファイル共有へアクセスする場合、取得済みの TGT を添えて TGS Request を KDC へ要求しますが、その際に指定する SPN は cifs/sv01.nekomaru.com となります。
[D] TGS Response
KDC の TGS はサービス チケットの発行要求(TGS Request)を受け取ったら、まず TGT に問題がないことを確認します。TGT に問題がないことを確認がとれたら、TGS Request に指定されている SPN を確認し、対象のサービスへアクセスするためのサービス チケットを発行します。
この時、サービスの一部の情報は、SPN が紐づいているアカウントのパスワードで暗号化されています。。
上図の例では、KDC は nekoneko@nekomaru.com の TGT を確認して、SPN で指定されている cifs/sv01.nekomaru.com のサービス チケットを発行して、ユーザー「ねこねこ」へ送信します。
[E] AP Request
接続元のクライアント(ユーザー プリンシパル)は、KDC から発行されたサービス チケットをサービスに提示して利用を要求します。
[F] AP Response
サービスを提供するサーバーは、クライアントから提示されたサービス チケットを検証します。
サービス チケットはサービス アカウントのパスワードで暗号化されているため、復号できるかを確認します。
確認の結果、サービス チケットに問題がなければ、Kerberos 認証が成功したことを示す結果を応答します。
Kerberos 認証の各フローの詳細な動作については、以下の記事でも紹介しております。
Kerberos 認証とは、ネットワーク認証方式の一つです。 Active Directory のドメイン環境では、ユーザーやコンピューターなどのリソースを一元的に管理できますが、その際の認証方式の基盤は Kerberos 認証で実現されて[…]
Kerberos 関連ポリシー
Windows OS では、Kerberos 認証に関連するポリシーが定義されています。
Kerberos 認証において発行されたチケットの有効期間や、チケットの時刻のずれの許容時間の定義を行うためのポリシーがあります。
パス：[コンピューターの構成] – [ポリシー] – [Windows の設定] – [セキュリティの構成] – [アカウント ポリシー] – [Kerberos ポリシー]
|
ポリシー名 |
既定値 |
説明 |
|
チケットの最長有効期間 |
10(時間) |
TGT の有効期限 |
|
サービス チケットの最長有効期間 |
600(分) |
サービス チケットの有効期限(※) |
|
ユーザー チケットを更新できる最長有効期間 |
7(日) |
TGT を更新できる有効期限 |
|
コンピューターの時計の同期の最長トレランス |
5(分) |
有効期限の誤差の許容範囲 |
※ 有効期限が切れた場合は新規作成
klist コマンド
Windows OS では Kerberos 認証において発行されたチケットは、チケットの発行要求を行ったアカウントごとに保持されます。Windows OS にて Kerberos 認証に使用されたチケットの情報の確認や、キャッシュの削除は klist コマンドにより行えます。
klist tickets
保持するサービス チケットの一覧を表示
klist tgt
TGT の情報を表示
klist purge
保持する全てのチケットを削除
-li 0x3e4 … NETWORK SERVICE アカウント
klist purge -li 0x3e7
認証と認可
システムへの不正アクセスを防ぐためのセキュリティ対策として、「認証」とセットで「認可」の仕組みを組み合わせて利用します。Kerberos 認証は「認証」の技術の一つですが、組み合わせて利用される「認可」も併せて理解が必要です。
認証とは？
認証とは、対象の正当性や真正性を確かめることです。
人やコンピューター、サービス アカウントなど様々な種類のものが認証の対象となり、その対象が名乗った通りの本人であるかを確認するプロセスが「認証」です。
例えば、コンピューターへログオンする時に、本人確認としてパスワードを入力したり、ATM から現金を引き落とす際に入力する暗号番号(PIN)を入力するなどの場面は認証のシナリオの一つです。
認証を行う方法として、パスワードや PIN など、本人のみが把握している情報を利用して本人確認をする方法が広く利用されています。ただし、何等かの方法で本人から情報を引き出したり、パスワード入力字の盗み見や、通信データの盗聴により、パスワードや PIN の情報を入手されたら、悪意のある第三者による「なりすまし」が可能となってしまいます。
そのため、最近では、セキュリティ トークン(USB トークン)や IC カードなどのデバイスを利用した認証、指紋や顔、静脈など生体認証の利用も広まりつつあります。
認可とは？
認証済みの利用者に対して、アクセス権の設定などを参照し、その利用者に与えられた適切な権限による操作を許可することを「認可」と呼びます。
認証済みのユーザー全てに対して、リソースへの参照や変更、実行の権限を与えるのではなく、その操作を許可されたユーザーにだけ操作を許すことです。
例えば、人事部のユーザーは各社員の履歴書や年収などの情報が含まれる資料を参照する権限を与えますが、営業部のユーザーには参照の権限は与えないというものです。
Windows OS では、「認可」の仕組みはアクセス制御リスト(Access Control List：ACL)の機能により実現されています。対象のデータのプロパティ画面を開いて、[セキュリティ] タブにてアクセス制御リストを設定することができます。
ポチップ
ポチップ