ダイナミックアクセス制御におけるトークンのフロー

ダイナミックアクセス制御はWindows Server 2012のActive Directoryの新しい機能として紹介されていますが、
実際に使うことになると、ドメインコントローラーだけが2012であればよいわけではなく、ダイナミックアクセス制御を利用するファイルサーバーやクライアントはどのような要件が必要になってくるのかということが重要になります。

そこで要件について、調べてみたところ、次のようなことがわかりました。
(正しくはマイクロソフトのWebサイトを確認してください)

■Windows Server 2003以上のドメイン機能レベルが設定されていること
■1台以上のWindows Server 2012 ドメインコントローラーがドメイン内にあること
■デバイスクレームを利用する場合はクライアントOSがWindows 8であること
■ファイルサーバーはWindows Server 2012であること

この要件を見て、私は思いました。
デバイスクレームに関わらず、クライアントOSはWindows 8でなければダメなのでは?
結論から先に言うと、ユーザーのクレームだけを利用してダイナミックアクセス制御を利用すれば、
Windows7でも良いのです。
理由は次のとおりです。

ダイナミックアクセス制御の基本的なフロー

ドメインコントローラー/ファイルサーバーがWindows Server 2012、クライアントがWindows 8の場合、
次のようなフローでダイナミックアクセス制御の処理が行われます。

DACArc1

■参考までに
ダイナミックアクセス制御をもとにアクセス制御を行う場合、NTFSアクセス許可とは異なり、
誰に対してどのようなアクセス許可を与えるかの設定は、Active Directoryデータベースの中に格納されます。
しかし、ユーザーからのアクセス要求に対して、いちいちファイルサーバーがADに問い合わせをしていたら、
時間ばかり費やすことになります。そこで、ファイルサーバーではアクセス許可設定を事前に
ADから取得しておきます(グループポリシーを利用して取得)。
そして、ユーザーからのアクセスがあった時には事前に取得しておいた
アクセス許可を参照し、アクセス可否の判断を行います。

クライアントがWindows 8以外のクライアントの場合の処理

クライアントがWindows 8以外の場合、Kerberosチケット(トークン)の内容は拡張できません。
(ちなみにトークンの内容はwhoamiコマンドで確認できます。)
では、クレームを持っていないWindows 7クライアントがどうやってダイナミックアクセス制御を利用するか?
それは、Windows7でアクセスしてきたユーザーのクレーム情報(属性情報)をファイルサーバーが代理で取得するのです。

DACArc2 
↑ファイルサーバーがアクセス制御の判断に必要な属性情報をADから取得

これにより、Windows7は自分のトークンにダイナミックアクセス制御で必要な情報が
入っていなくてもアクセス制御がきちんと行えるのです。
では、続いてこんなケースはどうでしょうか?

Windows Server 2012以外のファイルサーバーの場合

ダイナミックアクセス制御がサポートしないパターンです。
しかし、Windows Server 2012と前のバージョンのサーバーが混在するケースは
この先、いくらでも考えられるわけで。どのような動作になるのかチェックしておく必要があるでしょう。
結論は「ダイナミックアクセス制御を無視する」です。

クライアントは通常のファイルサーバーにアクセスするための手続きをとりますが、
「ダイナミックアクセス制御」を知らないファイルサーバーは何事もなかったかのように、
普通のファイルサーバーと同じくNTFSアクセス許可と共有アクセス許可だけをチェックします。

このことは注意が必要です。
なぜなら、
ダイナミックアクセス制御でしっかりアクセス許可設定をしておけば、
NTFSアクセス許可など、どうでもいいや

と考えてしまう可能性があるからです。

DACArc3

混在環境になる可能性がある場合には、NTFSアクセス許可もしっかり設定しておきましょう。
(言うまでもないことですが)

ダイナミックアクセス制御のトークンでクラウドへアクセスできるか?

「トークン」という言葉を聞くと、一部の方はOffice365のシングルサインオンなどを思い浮かべるかもしれませんが、
残念ながら、ダイナミックアクセス制御で使われるトークンと、Office365のシングルサインオンで使われるトークンは
全く別のものです。(ダイナミックアクセス制御のトークンはKerberosチケットをベースにしたトークンであるのに対し、
Office365のシングルサインオンのトークンはSAMLという規格に基づくトークンを採用しています。)
ということで、クラウドへのアクセスにはSAMLトークンを発行するADFSサーバー等の存在が必要になります。

■参考 – TechEd 2012 Australia WS2012 Dynamic Access Control Overview and Tips
http://channel9.msdn.com/Events/TechEd/Australia/2012/WSV334