【IAM】DAC その5 ～ Dynamic Access Control のアーキテクチャ(3) － PAC と Kerberos Pre-authentication（RFC 6113）による拡張

  • Article

なんだかどんどん深みにはまりつつある ダイナミックアクセス制御の解説シリーズです。。。でもお好きな方にはたまらないですよね（と信じつつ）。

2013 年 7 月以降には、DAC Deep Dive 1日コースのセミナーを開催しようかと考えております。東京以外でも開催したいのので、ぜひご要望をお寄せくださいませ。

さて、前回までの投稿は以下の通りです。

前回は「なぜダイナミック アクセス 制御」に「FSRM（File Server Resource Manager」が必要なのか？について解説しました。その中で、DAC は Kerberos のチケット内に格納されたユーザークレームおよびデバイスクレームを使用してアクセス権を判定していると書きました。これは Windows Server 2012 Active Directory の Kerberos が発行するチケットが拡張されたことによって実現されています。

今回は、以下のドキュメントに書かれている「Support for claims, compound authentication, and Kerberos armoring」をベースに、Windows Server 2012 および Windows 8 でエンハンスされた Kerberos について解説します。

What's New in Kerberos Authentication
https://technet.microsoft.com/en-us/library/hh831747.aspx

ご存知の通り、Windows Server Active Directory には Kerberos version 5 認証プロトコルが実装されています。そして、Kerberos がチケットを使用して認可を行うことはご存知の通りだと思います。。。。。が、Kerberos についてごくごく簡単に復習しておきましょう。

Kerberos とは、1983 年に始動した MIT Project Athena に起因する KDC（Key Destribution Center）を核としたセキュリティソリューションで、分散コンピューティング環境で安全にそして利便性を保ちつつリソースを使用するために研究が重ねられてきた仕組みです。

image

ユーザーが、Active Directory ドメインに参加している Windows クライアントにログオン（サインイン）する場合も Kerberos を使用して認証/認可が行われます。つまりユーザーは、KDC から「ローカル PC というリソースにアクセスするためのチケット」を発行してもらうのです。これによって、ユーザーはローカルPCの使用権限が与えられます（＝ログオン）。

image

ネットワークコンピューターについても同様に、チケットを発行してもらうことによってファイルサーバーやメールサーバーへのアクセス権を得ることができます。

チケットを受け取るには、基本的にユーザーのクレデンシャル（ユーザーIDとパスワードの組み合わせ）が必要です。しかし、サーバーにアクセスするたびに入力していたのでは利便性は高まりません。そこで、TGT（Ticket Granting Ticket） という事前発行チケットをローカルに保持しておくことで、次回以降はこれを提示し、リソースにアクセスするためのチケット（サービス チケット）を受け取ることができます。もちろん、一度発行された TGT が永遠に使い続けられることは危険なので、定期的に更新されます。

image

ここまでの話で、チケットには 2 種類存在することがわかりました。

  • TGT（Ticket Granting Ticket）
    ユーザーからの AS-Request によって発行されるチケット。AS とは Authentication Service（認証サービス）のこと。
  • サービス チケット（Service Ticket）
    リソースにアクセスするためのチケット。TGT を使用した TGS-Request によって発行される。TGS とは Ticket Granting Service（チケット公布サービス）のこと。

この 2 つのチケットの認可データフィールド領域には PAC（Privilege Attribute Certificate） と呼ばれる情報が格納されています。「Privilege」とあるとおり、PAC にはユーザーの「権限」にかかわる情報が格納されています。実は、PAC はマイクロソフトによって拡張された仕様であり、以下にその詳細が書かれています。

[MS-PAC]: Privilege Attribute Certificate Data Structure
https://msdn.microsoft.com/en-us/library/cc237917.aspx

[MS-KILE]: Kerberos Protocol Extensions
https://msdn.microsoft.com/en-us/library/cc233855.aspx

PAC には具体的には以下の要素が含まれています。

  • ユーザーの SID
  • ローカルグループのメンバーシップ
  • ドメイングループのメンバーシップ
  • プロファイル情報
  • 各種クレデンシャル など

Windows Server 2012 Active Directory Domain Service の Kerberos では、新たに以下の機能が実装されました。

  • PAC へのユーザークレームとデバイスクレームの格納
  • 複合認証（Compound Authentication）
  • Kerberos 防御（Kerberos Armoring）

これらの機能は既定では無効であり、使用するにはドメインコントローラーに関連付けられているグループポリシーの[コンピューターの構成] - [ポリシー] - [管理用テンプレート] - [システム] – [KDC] – [KDC で信頼性情報、複合認証および Kereberos 防御をサポートする]を有効にする必要があります。つまり、DAC を使用するときにはこのポリシーを有効にしておく必要があります。

image

では、拡張されたそれぞれの機能について、少し補足しておきます。

PAC へのユーザークレームとデバイスクレームの格納

従来、リソースの認可は、PAC に格納されている SID やグループメンバーシップ等をベースに判断していました。ところが、今回の PAC の拡張によって内部に自由に「クレーム」を保持できるようになりました。

クレームについては前回も触れたのでここでは詳しく解説しませんが、要はユーザーおよびデバイスの「属性」のことです。当然これは Active Directory Domain Service に格納されているユーザーやコンピューターの属性を指しています。

この機能により、AS-Request や TGS-Request のタイミングで発行されるチケット（TGTおよびサービスチケット）のフォーマットが拡張され、ユーザーやデバイスのクレームが格納できるようになります。もちろん、ドメインコントローラが RODC（Read-Only Domain Contoroller）であっても対応しています。

Kerberos 防御（Kerberos Armoring）

Kerberos には FAST（Flexible Authentication Secure Tunneling）という拡張規格が定義されています（RFC 6113）。KDC および KDC クライアントが FAST を実装してる場合、AS-Reust による TGT の発行に先駆けて、KDC とクライアント間で Pre-Authentication と呼ばれるメカニズムが実行されます。具体的には、クライアントが padata（pre-authentication data）と呼ばれる特別なデータを作成し、これを KDC に送信します。KDC は padata に正しい情報が格納されているかどうかを解析し、問題が無ければ改めて AS-Reust が実施されます。

このプロセスによって、KDC とクライアント間で安全なチャネルが構築され、TGT の発行をより安全に実行することができます。

複合認証（Compound Authentication）

PAC の拡張によりチケットのフォーマットが拡張され、クレームが格納できる領域が用意されました。ただ、ここにクレームを格納するためのプロセスが用意されていなければ、拡張された意味がありません。

複合認証は、前出の FAST の拡張機能です。この機能が有効になると、TGS-Request 時にデバイスのサービスチケットを要求できるようになります。KDC から返される TGT には、

  • デバイスアカウント（コンピューターアカウント）の SID
  • デバイスアカウントのグループメンバーシップ
  • デバイスアカウントのクレーム

が格納されるので、ユーザーのクレームと合わせてリソースへのアクセス制御が可能になります。ユーザーとデバイスの両方の属性が使用できるので「複合」なんですね。

グループポリシーには「KDC で信頼性情報、複合認証および Kereberos 防御をサポートする」と書かれており、なんだかよくわからなかった方も多いと思います。ひも解いてみると、上記のような理由でそれぞれの機能が密接に絡み合っていたのですねぇ。

＜その４