ちょっと面倒な連載が続いたので、今回は遊びます。
「マイクロソフトが大好きで、自ら MS 人事マニアであると自負されている方」向けに問題です。
この方は誰でしょう？
わかりました？
↓
答えは、Steve Guggenheimer（スティーブ グッゲンハイマー）です。
え？それは誰かって？群馬県とは関係ありません。
私が所属している部門が「日本マイクロソフト株式会社 デベロッパー＆プラットフォーム エバンジェリズム」なのですが、その親玉である Microsoft Corporation Developer & Platform Evangelism の親分です。我々から見れば、とーっても偉い人なわけです。はい。
でもって、我々エバンジェ��ストの最上級をあらわす、Chief Evangelist でもあります。
世界中のさまざまなカンファレンスのキーノートに登壇しているので、ご覧になったことがある方も多いかもしれませんし、6月の BUILD に参加される方は、そこでお目にかかることになるでしょう。
そんな彼が日本にやってきて、登壇する日があります。
それも、BUILD はかなり高価なカンファレンスですが、これは無償です。
Chief Evangelist のべしゃりってやつを聴いてやろうじゃないか！という方、是非とも以下のイベントにご参加ください！
6/3(mon) 13:00 ～ Microsoft Innovation Meetup! @秋葉原 です。
久しぶりに Windows Update をスクリプトから実行しようかなぁと思って PowerShell のコマンドレットを探していたら、標準では提供されていないんですねぇ。全く気づいておりませんでした。
となると、VBScript のように Microsoft.Update.Session を呼び出すしかないものかと思っていると、なんと便利なモジュールが提供されていました。
Windows Update PowerShell Module http://gallery.technet.microsoft.com/scriptcenter/2d191bcd-3308-4edd-9de2-88dff796b0bc
さっそく使ってみましょう。
まずはダウンロードして ZIP ファイルを開いてみてください。PSWindowsUpdate フォルダが格納されているはずです。この中にこのモジュールを構成するスクリプト群が格納されています。
これらのファイルは「インターネットゾーンからダウンロードしたファイル」なので、必ず「ブロックの解除」を実行しておきましょう。でないと実行できません。
ブロック解除が完了したら、PSWindowsUpdate フォルダを、PowerShell のモジュール用フォルダに保存します。
モジュール用フォルダの場所を確認するには、以下のように PowerShell コンソールから環境変数 PSModulePath を確認します。
PS C:\windows\system32> $env:PSModulePath C:\Users\junichia\Documents\WindowsPowerShell\Modules;C:\windows\system32\WindowsPowerSh ell\v1.0\Modules\;C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\
（参考）Windows PowerShell: Windows PowerShell のカスタム ツールをパッケージ化して配布する
ここでは3つのパスが指定されています。
以下のパスはユーザーの個人的なモジュールパスで、今回はモジュールを追加するのでこの配下に PSWindowsUpdate フォルダを移動してください。なお、既定ではこのパスは存在しないので、自分で作ってください。
以下のパスはシステムモジュール用のパスです。
以下は Windows Azure 用コマンドレットをインストールしたときに作成されたパスでしょう。既定では存在しませんので、無くても不安にならないでください。
PSWindowsUpdate フォルダを移動したら、コンソールから Import しましょう。
ブロック解除が行われていれば、特にエラーは出力されないはずです。
次に、コマンドレットの一覧を見てみましょう。以下の用の出力されたら問題ありません。
CommandType Name ModuleName ----------- ---- ---------- Function Add-WUOfflineSync pswindowsupdate Function Get-WUHistory pswindowsupdate Function Get-WUInstall pswindowsupdate Function Get-WUInstallerStatus pswindowsupdate Function Get-WUList pswindowsupdate Function Get-WURebootStatus pswindowsupdate Function Get-WUServiceManager pswindowsupdate Function Get-WUUninstall pswindowsupdate Function Hide-WUUpdate pswindowsupdate Function Remove-WUOfflineSync pswindowsupdate Function Test-ElevatedShell pswindowsupdate
それぞれのコマンドレットの用途は、なんとなーくわかりますよね。
具体的な使い方は次の投稿で。
以前の投稿につづき、今回は Windows Servevr 2012 が提供する DAC のアーキテクチャについて解説します。この辺をご理解いただくと、多くのエンジニアの方に「おぉ、やってみたい」と思っていただけるかと。
まずは以前の投稿でも使用した以下の図をご覧ください。DAC では「リソース側の属性」と「ID 側の属性」のマッチングを行い、条件が合致したときにアクセス権が適用されます。
ちょっと運用イメージが想像しずらいでしょうか？
現実の世界にもこのような仕組みは存在しています。例えば"ある種の結婚相談所"を思い浮かべてみてください。
あくまでも私の想像ですが、結婚相談所の場合、女性は出会いたい男性の属性を事前に定義しておく必要があるのでしょう（たぶん）。結構相談所側は、女性の要求と、条件に合致した男性から女性へのコンタクト権限（アクセスルール）を定義しておきます。もちろん、このときアクセスルールにはある程度女性側のニーズを反映させる必要があるので、複数のルールを作成しておく必要があるかもしれません。男性はどういった女性が登録されているかは把握可能ではあるものの、アクセスルールに合致しなければインスタントメッセージさえも送ることは不可能です。
このモデルでは、結婚相談所が両者のニーズの中間地点でアクセス管理を行っています。もし結婚相談所によるアクセス管理が無かったとしたら、一切のアクセス制御は女性自身が行う必要があります。これはとても面倒です。
えっと何の話でしたっけ？あ、DACですね。DAC に話を戻しましょう。
DAC によるアクセス管理の全体像をざくっと図にすると以下の通りです。
ここで3人の主要な登場人物について理解しておきましょう。
ソースとは、リソースにアクセスする主体を指します。つまり、ユーザーやデバイスのことです。ソースは Active Directory ドメインに定義されたオブジェクトであり、ldap 属性を持っています。
リソースとはファイルサーバー上の”フォルダ”や”ファイル”のことです。リソースには「分類属性」と呼ばれる特別な属性を定義することができ、これを使用してアクセス可能なソースを制限することができます。
アクセスポリシーとは、その名の通りアクセスを制御するためのポリシーです。正式日本語名称「集約型アクセスポリシー（Central Access Policy）」と呼ばれ、その名称から”集中管理された”アクセスポリシーであることがわかります。「集中管理」が何を意味するかといえば、もちろん「Active Directory ドメイン による集中管理」のことです。
上の図を、さらに詳しく書いたのが以下の図です。
アクセスポリシーにはアクセスルール（正式日本語名称：集約型アクセス規則）が格納されています。アクセスルールによって「ソース側の属性」とリソース側の「分類属性」が比較されるとともに、条件が合致した場合のアクセス権限（ReadとかWriteとか）が与えられます。
ちょっと面倒な話なのですが、ソース側の属性は、アクセスルール内では「クレームタイプ（要求の種類）」と呼ばれます。AD FS（Active Directory Federation Service）に慣れた方であれば違和感がないかと思います。アクセスポリシーを策定する管理者は、ソースが持つldap属性の中からアクセス制御に使用するものを選定し、クレームタイプとして定義します。
さらに、クレームタイプと比較したいリソース側の属性（分類属性）を「リソースプロパティ」として定義します。言い方を変えれば、リソースプロパティがアクセス制御の対象となるリソース側の条件となります。つまり、ここで定義したリソースプロパティを持たないリソースは、このアクセスルールによるアクセス制御の対象とはなりません。
リソースプロパティが1つであるとは限らないので、アクセスルール内では「リソースプロパティ リスト」として定義されることになります。
用語が大量に登場して頭が混乱しますよね。わかります。私も最初は相当混乱しました。今は我慢のときです。あきらめずに読み進めてください。
アクセスポリシーの定義は、Active Directory 管理センターから行います。Active Directory 管理センターの「ダイナミック アクセス制御」を開くと、上で説明した各項目の定義画面が用意されています。それぞれが英語表記になってしまっているのがアレなのですが。。。
この画面で最初に行うのは「Claim Types（クレームタイプ、要求の種類）」の定義です。以下の例では、ldap属性の department をクレームタイプとして定義しています。これにより、アクセス権判定の際には、ユーザーのdepartment 属性が参照されます。
次に、「Resource Properties（リソースプロパティ）」を定義します。以下の例では、クレームタイプ同様、Department というプロパティを定義しています。なお、ここで定義するプロパティは、現時点でファイルサーバー上のリソースに存在している必要はありません。ここで定義したプロパティが、ファイルサーバー上のリソースに追加されます。
作成した Resource Properties は、Resource Propertiy Lists（リソースプロパティ リスト）に追加しておく必要があります。
復習しておきましょう。ここまでの作業で、以下が作成されました。
今度は、クレームタイプとリソースプロパティを関連付けて、アクセス権を定義します。これが「 Central Access Rules（集約型アクセスルール」です。以下の画面ショットを穴が開くほど眺めてください。「ターゲット リソース」については説明するまでもないでしょう。わかりずらいのが「現在のアクセス許可」として定義されている項目です。
「現在のアクセス許可」の設定画面を開いたものが以下です。Domain Users の中で Department 属性が「IT」または「SALES」のユーザーに対して「読み取りと実行」権限を与える。。。という意味になります。
どうでしょう？理解できたでしょうか。
ここで定義したアクセスルールは、Central Access Policy（集約型アクセスポリシー）に格納します。
これで、ひととおりの定義は完了です。
さて、ここで疑問が出てきます。
安心してください。上の図に書かれている通り、答えはグループポリシーです（素敵！）。グループポリシーの中には、「集約型アクセスポリシー」と呼ばれる定義が用意されています。ここに、作成したアクセスポリシーを定義します。
なお、このポリシーはコンピューターに対して適用する必要があります。したがって、Default Domain Policy のような汎用ポリシーに定義してしまうよりは、「DAC Policy」などの独立したGPO を作成しましょう。そして、以下のように適用先のフィルタ設定を必ず行ってください。既定では、Authenticated Users に適用されてしまいます。
ポリシーが正しく適用されると、ファイルサーバー上のフォルダやファイルには、以下のように分類属性が追加されます。なお、分類属性タブが表示されない。。。。という方は「ファイルサーバーリソースマネージャー」をファイルサーバーにインストールしてください。「役割と機能の追加」から追加することができます。
いかがでしょう？
なんとなーく、全体の動きが見えたでしょうか？
次回は、分類属性についてもう少し詳しく解説します。
＜その２ その４＞
Windows Server 2012 から利用可能になった ダイナミックアクセス制御 に関して、細々と掲載を続けるシリーズです。前回までの投稿は以下の通りです。
今回は、DAC を利用するのにファイルサーバー側に FSRM（ファイルサーバー リソースマネージャー）が必要な理由について解説しておきたいと思います。
FSRM（ファイルサーバー リソースマネージャー）は既にご存知かと思いますが、念のために紹介しておきます。詳細は以下を参照ください。
ファイル サーバー リソース マネージャーの概要 http://technet.microsoft.com/ja-jp/library/hh831701.aspx
FSRM はもともと Windows Server 2003 R2 で初めて実装されました。それが 2008 → 2008 R2 →2012 と進化し続け、今に至っています。
FSRM はひとことで言えばストレージをより高度かつ合理的に管理するための機能セットです。Windows Server 2012 FSRM の機能をザクッと洗い出すと以下の通りです。
ファイルサーバーに FSRM がインストールされることにより、FSRM Protocol と呼ばれる専用のプロトコルが組み込まれ、これにより FSRM と ファイルシステム間、FSRM クライアントと FSRM サーバー間のやり取りが可能になります。
さて、上に挙げた FSRM の機能のうち、DAC にとって最も重要なのは「ファイル分類インフラストラクチャー（FCI, File Classification Infrastructure）」です。
FCI は、「分類属性（Classification Properties）」を使用してファイルを分類する機能です。例えば、ファイルの中に個人情報（電話番号や住所、メールアドレスなど）だと思われるデータが格納されている場合、FCI は自動的にファイルの分類属性（例えば Importance という名前の属性）を「High」に設定することができます。さらに、「Hight」に設定されたファイルを自動的にセキュアな格納庫に移動するといったことも可能です（詳細はまた別の投稿で）。
DAC は 「分類属性」を使用してユーザーやデバイスからのアクセスを制御していることはこれまでに解説しましたが、分類属性を使用するための基盤として FSRM が必要になります。
分類属性について、もうすこし詳しく書いておきます。
分類属性のタイプにはローカルとグローバルの2種類が存在しています。いずれのタイプでも FCI で使用することができますが、DAC によるアクセス制御に使用できるのはグローバルタイプの分類属性のみです。
FSRM の管理コンソールや Windows PowerShell の New-FsrmClassificationPropertyDefinition コマンドレットを使用するとローカルタイプの分類属性を作成することが可能ですが、グローバルタイプの分類属性は作成できません。
実は、グローバルタイプの分類属性のソースは Active Directory に格納されており（グローバル リソース プロパティ）、既定では「無効」に設定されています。新規にグローバルタイプの分類属性を作成する必要がある場合は、Active Directory 管理センターの Dynamic Access Control 管理コンソールを使用するか、Windows PowerShell の New-ADResourceProperty コマンドレットを使用します。既定で用意されているグローバル属性は、Set-ADResourceProperty を使用すれば有効化することが可能です。
では、Active Directory に格納されたグローバル リソース プロパティはどのようにファイル サーバーに反映されるのでしょう。Windows Server 2012 および Windows 8 でリニューアルされた FSRM Protocol は、Active Directory からグループ ポリシーまたは、Update-FsrmClassificationPropertyDefinition コマンドレット を使用してグローバル リソース プロパティを受け取り、グローバルタイプの分類属性として自身の属性ストアに反映できるようになりました。逆に言えば、グローバルタイプの分類属性を使用するには、ファイルサーバーが Windows Server 2012 / Windows 8 でなければなりません。
以上のように、DAC は FSRM を通じてリソースの属性を確認するとともに、Active Directory Domain Service が発行した Kerberos チケットに格納されているユーザークレームおよびデバイスクレームを比較することでアクセス制御を行っています。
＜その３ その５＞
なんだかどんどん深みにはまりつつある ダイナミックアクセス制御の解説シリーズです。。。でもお好きな方にはたまらないですよね（と信じつつ）。
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 http://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）を核としたセキュリティソリューションで、分散コンピューティング環境で安全にそして利便性を保ちつつリソースを使用するために研究が重ねられてきた仕組みです。
ユーザーが、Active Directory ドメインに参加している Windows クライアントにログオン（サインイン）する場合も Kerberos を使用して認証/認可が行われます。つまりユーザーは、KDC から「ローカル PC というリソースにアクセスするためのチケット」を発行してもらうのです。これによって、ユーザーはローカルPCの使用権限が与えられます（＝ログオン）。
ネットワークコンピューターについても同様に、チケットを発行してもらうことによってファイルサーバーやメールサーバーへのアクセス権を得ることができます。
チケットを受け取るには、基本的にユーザーのクレデンシャル（ユーザーIDとパスワードの組み合わせ）が必要です。しかし、サーバーにアクセスするたびに入力していたのでは利便性は高まりません。そこで、TGT（Ticket Granting Ticket） という事前発行チケットをローカルに保持しておくことで、次回以降はこれを提示し、リソースにアクセスするためのチケット（サービス チケット）を受け取ることができます。もちろん、一度発行された TGT が永遠に使い続けられることは危険なので、定期的に更新されます。
ここまでの話で、チケットには 2 種類存在することがわかりました。
この 2 つのチケットの認可データフィールド領域には PAC（Privilege Attribute Certificate）と呼ばれる情報が格納されています。「Privilege」とあるとおり、PAC にはユーザーの「権限」にかかわる情報が格納されています。実は、PAC はマイクロソフトによって拡張された仕様であり、以下にその詳細が書かれています。
[MS-PAC]: Privilege Attribute Certificate Data Structure http://msdn.microsoft.com/en-us/library/cc237917.aspx [MS-KILE]: Kerberos Protocol Extensions http://msdn.microsoft.com/en-us/library/cc233855.aspx
[MS-PAC]: Privilege Attribute Certificate Data Structure http://msdn.microsoft.com/en-us/library/cc237917.aspx
[MS-KILE]: Kerberos Protocol Extensions http://msdn.microsoft.com/en-us/library/cc233855.aspx
PAC には具体的には以下の要素が含まれています。
Windows Server 2012 Active Directory Domain Service の Kerberos では、新たに以下の機能が実装されました。
これらの機能は既定では無効であり、使用するにはドメインコントローラーに関連付けられているグループポリシーの[コンピューターの構成] - [ポリシー] - [管理用テンプレート] - [システム] – [KDC] – [KDC で信頼性情報、複合認証および Kereberos 防御をサポートする]を有効にする必要があります。つまり、DAC を使用するときにはこのポリシーを有効にしておく必要があります。
では、拡張されたそれぞれの機能について、少し補足しておきます。
PAC へのユーザークレームとデバイスクレームの格納
従来、リソースの認可は、PAC に格納されている SID やグループメンバーシップ等をベースに判断していました。ところが、今回の PAC の拡張によって内部に自由に「クレーム」を保持できるようになりました。 クレームについては前回も触れたのでここでは詳しく解説しませんが、要はユーザーおよびデバイスの「属性」のことです。当然これは Active Directory Domain Service に格納されているユーザーやコンピューターの属性を指しています。 この機能により、AS-Request や TGS-Request のタイミングで発行されるチケット（TGTおよびサービスチケット）のフォーマットが拡張され、ユーザーやデバイスのクレームが格納できるようになります。もちろん、ドメインコントローラが RODC（Read-Only Domain Contoroller）であっても対応しています。
従来、リソースの認可は、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 の発行をより安全に実行することができます。
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 デバイスアカウントのグループメンバーシップ デバイスアカウントのクレーム が格納されるので、ユーザーのクレームと合わせてリソースへのアクセス制御が可能になります。ユーザーとデバイスの両方の属性が使用できるので「複合」なんですね。
PAC の拡張によりチケットのフォーマットが拡張され、クレームが格納できる領域が用意されました。ただ、ここにクレームを格納するためのプロセスが用意されていなければ、拡張された意味がありません。
複合認証は、前出の FAST の拡張機能です。この機能が有効になると、TGS-Request 時にデバイスのサービスチケットを要求できるようになります。KDC から返される TGT には、
が格納されるので、ユーザーのクレームと合わせてリソースへのアクセス制御が可能になります。ユーザーとデバイスの両方の属性が使用できるので「複合」なんですね。
グループポリシーには「KDC で信頼性情報、複合認証および Kereberos 防御をサポートする」と書かれており、なんだかよくわからなかった方も多いと思います。ひも解いてみると、上記のような理由でそれぞれの機能が密接に絡み合っていたのですねぇ。
＜その４