なんだかどんどん深みにはまりつつある ダイナミックアクセス制御の解説シリーズです。。。でもお好きな方にはたまらないですよね（と信じつつ）。
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 防御をサポートする」と書かれており、なんだかよくわからなかった方も多いと思います。ひも解いてみると、上記のような理由でそれぞれの機能が密接に絡み合っていたのですねぇ。
＜その４
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 チケットに格納されているユーザークレームおよびデバイスクレームを比較することでアクセス制御を行っています。
＜その３ その５＞
以前の投稿につづき、今回は 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 8 のコマンド系小ネタ その2です。
たぶん、99%の方が「ふーん、で？」と反応されると思いますが、微妙に楽しいコマンドなのでご紹介します。
例えば、readme.txt ファイルをダブルクリックすると通常はメモ帳が開きます。
メモ帳以外のアプリケーションで開きたい場合には、ファイルを右クリックしてコンテキストメニューから「プログラムから開く」を選択します。誰でも知っています。
では、バッチファイルの中からテキストファイルを開きたい場合を考えてみます。
通常は単純に以下のように書けばOKです。自動的に対応ずけられているアプリケーションで readme.txt が開きます。
readme.txt
もしアプリケーションを指定したいのであれば、以下のように書くこともできます。
"%ProgramFiles%\Windows NT\Accessories\wordpad.exe" readme.txt
では、開きたいアプリケーションをユーザーに選ばせたい場合にはどうしたらよいでしょう？（そんなニーズがどれほどあるかはアレですが）
なんと、OpenWith.exe というコマンドが用意されています。
コマンドプロンプトから以下のように入力してみてください。
openwith readme.txt
すると、以下のようにアプリケーション選択用のメニューが表示されます。
利用者は、このメニューから好きなアプリケーションを選択することができます。
とっても便利な機能のような気がするのですが、実は広い用途で使えるコマンドではないです。
でも知ってると、ちょっと自慢できます。
コマンド系の小ネタをいくつか。まずは1つ目。
多くの方がご存知の通り、Windows 8 には既定では .NET Framework 3.5 がインストールされていません。
そして、これも多くの方がご存知の通り、インストールするには「プログラムと機能」から「Windows 機能の有効化または無効化」を選択して、おなじみの画面から「.NET Framework 3.5」をチェックします。
またはコマンドプロンプトから以下のコマンドを実行します。NetFx3 は .NET Framework 3.5 を表す機能名です。
Dism /online /enable-feature /featurename:NetFx3 /All
上記のいずれの場合も、Windows Update サイト（またはWSUSサイト）からファイルをダウンロードしてインストールしようとします。
もしネットワークが使用できず、Windows 8 のメディアからインストールしたい場合には、以下のように使用します。/Source はメディアのパス、/LimitAccess はWindows Updateに接続しないことを意味しています。
Dism /online /enable-feature /featurename:NetFx3 /All /Source:”D:\Sources\sxs” /LimitAccess
もちろん、Windows PowerShell から実行することもできます（どちらかというと、こちらのほうが推奨されています）。
Enable-WindowsOptionalFeature -Online -FeatureName NetFx3 –All
Enable-WindowsOptionalFeature -Online -FeatureName NetFx3 –All –Source ”D:\Sources\sxs” -LimitAccess
まぁ、だいたいこんなところかなぁ。。。。と思っていたら、もう1つありました。
Fondue コマンドというなんともおいしそうなコマンドが、Windows 8 に提供されています
コマンドプロンプトから以下のコマンドを実行すると、アプリケーションのインストール時にときどき表示されるダおなじみのイアログが表示されます。この画面の雰囲気と、/Caller-Name オプションを指定してSQM（ソフトウェア品質管理）レポートをマイクロソフトに送付できるようになっていることから、アプリケーションやスクリプトの内部から呼び出すことを前提としているようです。
fondue.exe /enable-feature:netfx3
もちろん、ダイアログが出ないようにすることもできますし、自動的に再起動することも可能です。
fondue /enable-feature:netfx3 /hide-ux:all
ただ、このプログラムは DISM や Enable-WindowsOptionalFeature のように /Source を指定してメディアからインストールすることができないのですねぇ。なので、場合によってはちょっと使い勝手がわるいかもです。
ただ、バッチファイルやスクリプトから簡単に上記画面を表示できるので、ちょっとプロっぽい感じを演出できるところがメリットでしょうかね（ほんとか？）。
##2013.4.19 スクリプトを修正
Windows Deployment Service（WDS） で Windows 8 を仮想マシンに自動展開しようとすると、キー配列が英語（101/102）になってしまいます。そのため、初回ログオン時にキーボードドライバを 106/109 に変更しなければなりません。
何とかこの現象を回避し、日本語でインストールしようと試みているのですがなかなかうまくいかず試行錯誤しておりました。
本件に関し、MVP の 小澤 真之 氏が BLOG にて以下の記事を投稿してくださいました。
WDS で Windows 8 を展開する際に日本語キーボードを設定する http://engineermemo.wordpress.com/2013/04/11/wds-%e3%81%a7-windows-8-%e3%82%92%e5%b1%95%e9%96%8b%e3%81%99%e3%82%8b%e9%9a%9b%e3%81%ab%e6%97%a5%e6%9c%ac%e8%aa%9e%e3%82%ad%e3%83%bc%e3%83%9c%e3%83%bc%e3%83%89%e3%82%92%e8%a8%ad%e5%ae%9a%e3%81%99/
要約すると、インストールに使用する install.wim ファイルに対して以下のコマンドを実行することで、既定のレイヤードドライバーを 106/109 に変更しておくという方法です。
dism /Image:C:\mount /Set-LayeredDriver:6
これならば言語ごとに install.wim を用意しておけば済むので、今のところ小澤さんが提案してくださったこの方法がベストだろうなぁ考えています。
が、そうはいっても別の（もうすこし変態的な）方法を考えたくなるのが人情というものです。
そこで、以下の PowerShell スクリプトを”インストール完了のタイミングを見計らってホスト側から"実行するってのはどうでしょう。※MDT 2012 Updat1 でタスクシーケンスを使用すれば、インストール完了後に実行できるかも
##仮想マシン名 $VMName = "test"
##設定したいLayeredDriver の値 $LayerdDriver = 6
##仮想マシンの仮想ハードディスクのパスを取得 $HDD = (Get-VMHardDiskDrive $VMName | Select-Object Path).Path
##仮想マシンを停止 Stop-VM $VMName
##仮想マシンのシャットダウンが完了するまで待ち合せる Do { Start-Sleep -Seconds 1 } Until(( Get-VM $VMName ).State -eq "Off")
##仮想ハードディスクをマウント Mount-DiskImage $HDD $Image = Get-DiskImage $HDD
##仮想ハードディスクからパーティション情報を取得 $Partitions = Get-Partition -DiskNumber $Image.Number
##マウントしたドライブにWindowsフォルダがあるかどうかをチェック if (Test-Path $WindowsPath){ $AttachedDrive = $p.DriveLetter+":" }
Remove-PSDrive $p.DriveLetter }
dism /Image:$AttachedDrive /Set-LayeredDriver:$LayerdDriver
Dismount-DiskImage $HDD Start-VM $VMName
##DiskPart をスクリプトモードで実行する際に使用するスクリプトファイル #$ScriptFileName = "c:\tmp\setlay.txt" #Echo "select vdisk file=""$HDD""" | Out-File -FilePath $ScriptFileName -Encoding utf8 #Echo "attach vdisk" | Out-File -FilePath $ScriptFileName -Encoding utf8 -Append #diskpart /S $ScriptFileName #dism /Image:$AttachedDrive /Set-LayeredDriver:$LayerdDriver #Echo "select vdisk file=""$HDD""" | Out-File -FilePath $ScriptFileName -Encoding utf8 #Echo "detach vdisk" | Out-File -FilePath $ScriptFileName -Encoding utf8 -Append #diskpart /S $ScriptFileName #Start-VM $VMName
やっていることは単純です。
仮想マシンへのインストールが完了したことを見計らって（ここを動判定するかはSEの腕の見せ所）、仮想マシンを一旦シャットダウンします。このとき、かならずシャットダウン完了を待ち合せてください。マシンがシャットダウンされていないと、次の処理がエラーとなります。
※MVP 牟田口さんのアドバイスににより、Mount-DiskImage コマンドレットを使用する方法に変更しました シャットダウンが正常に完了したら、仮想マシンのハードディスクをホストにマウントします。仮想ハードディスクをマウントするには、Mount-DiskImageコマンドレットを使用します。 仮想ハードディスクをマウントするには、Diskpartコマンドで Attach Vdisk サブコマンドを実行するのですが、これをバッチ処理するには事前に「スクリプトファイル」を作成しておく必要があります。このとき、スクリプトファイルは utf8 で保存する必要があるので注意してください。Windows PowerShell の Out-File コマンドレットには –Encoding パラメタが用意されているので便利ですね。
次に、マウントしたドライブからパーティション情報を取り出し、DriveLetterプロパティでどのドライブにマウントされたかを確認します。ただし、複数のパーティションが含まれている可能性があるので、Foreachを使用してパーティションに Windows フォルダが含まれているかどうかを確認します。パスの確認に使用するのは Test-Path コマンドレットですが、このコマンドレットに指定できるパスは PSDrive でなければなりません。試しに、VHDX ファイルをマウントした状態で Get-PSDrive コマンドレットでドライブの一覧を表示しても、マウントしたドライブは表示されません。そこで、New-PSDrive コマンドレットを使用してファイルシステム上のパスをPSDriveとして登録する必要があります。
ドライブが特定できたら、dism コマンドを使用して LayeredDriver の値を 6 に設定します。LayeredDriver に指定できる値は以下の通りです。今回は、Japanese Keyboard を使用したいので 6 を指定しました。
最後に、Diskpart で Attach した仮想ハードディスクを Detach して、仮想マシンを起動すれば完了です。
うーん、どう考えても小澤さんの方式のほうがよいです。
PowerShell を勉強したい方はチャレンジしてみてください。
Windows Server 2012 ではDHCP サーバーの構成をクラスタリングすることができることは、10万人位の方がご存知かと思います。
念のために簡単に紹介しておきます。
いままでの Windows Server DHCP サービスでは フェールオーバーすることはできず、1台の DHCP サービスが死んでしまった時のために、スコープを変えて別の DHCP サービスを用意しておく必要がありました。
Windows Server 2012 では、同じスコープを複数の DHCP サービスで共有し、ロードバランスならびにフェールオーバーが可能となりました。これにより、DHCP サービスの設計や導入が非常に楽になりました。
で、これはこれで便利なのですが、困ったこともあります。
一方の DHCP サーバーが死んでしまったとき、以下のようにスコープが消せないという問題が出ることがあります。
「スコープがフェールオーバーリレーションシップに含まれています。このスコープを関係から削除してください」
じゃぁ、ということで「フェールオーバーの構成解除」をしようとすると、以下のように「対象となるコンピューター上で、DHCP サーバーが実行されていません。」というエラーが出てしまい、にっちもさっちもいきません。
対象となるコンピューター上で、DHCPサーバー サービスが実行されていません。 フェールオーバーの構成を解除できませんでした。エラー: 1722
困ったときは Windows PowerShell です。間違いありません。
まずは、削除したいスコープのプロパティを開いて「フェールーバー」タブを確認しておきます。ここに書かれている「関係名」と「パートナーサーバー」をコマンドレットのパラメタとして使用します。
管理者モードで Windows PowerShell のコンソールを開き、以下の通りコマンドを入力します。
Remove-DhcpServerv4Failover -Name <関係名> –Force
-Force を忘れずに指定してください。
警告が表示されることがあるのですが、フェールオーバー構成が削除されているはずです。
これで、スコープを削除することもできるようになっているはずです。
前回の投稿は以下の通りです。
【IAM】 DAC その１ ～ グループベース RBAC の破たん? http://blogs.technet.com/b/junichia/archive/2013/03/29/3561744.aspx
この投稿では、前回の投稿をふまえ、「なぜ企業のアクセス管理にDACが必要なのか」という点について書きたいと思います。
DAC が「Expression（式）ベースのルールによるアクセス管理」であることは前回の投稿で書いた通りです。
ここで疑問を持つ方がいらっしゃると思います。
「アクセスルールを管理するのは誰なのよ？」
当然の疑問です。
IDの属性を管理するのは「ID管理者」。リソースの属性を管理するのは「リソース管理者」です。両者を結び付ける「アクセスルール」を誰が管理するのか?
従来の ACL ベースのアクセス管理では、ルールを管理していたのは「リソース管理者（またはリソースのオーナー）」です。それが最も合理的であると考えられてきました。しかし、「社内統制」という観点では、しばしば不合理な問題が発生しうるのもこの方式です。
各所に IT が浸透し多く部門間でデータを共有するようになると、その取扱いが極めて煩雑になります。リソースの提供者の多くは「アクセス権の管理手法」を正確に理解していませんから、しばしば設定ミスや怠慢等によってセキュリティ上重大なリスクが発生してしまうことがあります。
こうした問題を軽減するために「企業レベルのアクセスルール管理」へのニーズが高まっています。企業内の専門部隊が、社内リソースのアクセスルールを集中的に管理するという考え方です。
もちろん、すべてのリソースがその対象となるわけではないでしょう。しかし、確実に社内統制が必要なリソースは存在します。そうしたリソースに対しては、統制されたアクセスルールを適用することで、これまでよりも安全にリソースを管理できるようになります。
ということで、冒頭の疑問への回答は以下の通りです。
「アクセスルールを管理するのは、社内のセキュリティチームである」
セキュリティチームがリソースのアクセス権に関して行う作業は以下の通りです。
1. 重要な社内リソースへのアクセス権に関してセキュリティポリシーを策定する
ここで注意していただきたいのは、対象リソースを明に（C:\Data とか）指定するわけではないということです。あくまでも対象となるリソースの「条件」を定義するのだという点に注意してください。 条件には、所属以外にも、担当プロジェクトや役職などが考えられますし、単純なところではデータの重要性（外部公開、社外秘、社員のみ など）を定義する必要もあるでしょう。また、より厳密に管理するのであれば「データがどういったコンプライアンスフレームワークに属するか」といった定義も必要になるでしょう。例えば以下のようなフレームワークが考えられます（日本にとっては重要でないものもあったりなかったりですが。。。）。
ここで注意していただきたいのは、対象リソースを明に（C:\Data とか）指定するわけではないということです。あくまでも対象となるリソースの「条件」を定義するのだという点に注意してください。
条件には、所属以外にも、担当プロジェクトや役職などが考えられますし、単純なところではデータの重要性（外部公開、社外秘、社員のみ など）を定義する必要もあるでしょう。また、より厳密に管理するのであれば「データがどういったコンプライアンスフレームワークに属するか」といった定義も必要になるでしょう。例えば以下のようなフレームワークが考えられます（日本にとっては重要でないものもあったりなかったりですが。。。）。
2. 策定したセキュリティポリシーをリソース管理者に通達する
リソースにどのような属性が用意され、それがどのように設定されていると、どのような属性を持ったユーザーに、どのようなアクセス権が与えられるのかという内容を通達します。通達されたポリシーをどのリソースに適用するかはリソース管理者の裁量となりますが、少なくともリソース管理者は公開するデータがどのような種類のデータであるかを把握しておく必要があります。社外秘なのか部門限定情報なのかなどです。逆に、それが判断できない人はリソース管理者であってはなりません。。。。つまりリソース管理者にもそれなりのリテラシーが要求されるわけです。 。。。と書くとかなり敷居が高いように思えますが、リソース管理者自身が「社外秘情報の判別と、そのアクセス権まで管理していた」ACLベースのアクセス管理手法と比較すれば、はるかに容易ですし、安全性は高まります。
リソースにどのような属性が用意され、それがどのように設定されていると、どのような属性を持ったユーザーに、どのようなアクセス権が与えられるのかという内容を通達します。通達されたポリシーをどのリソースに適用するかはリソース管理者の裁量となりますが、少なくともリソース管理者は公開するデータがどのような種類のデータであるかを把握しておく必要があります。社外秘なのか部門限定情報なのかなどです。逆に、それが判断できない人はリソース管理者であってはなりません。。。。つまりリソース管理者にもそれなりのリテラシーが要求されるわけです。
。。。と書くとかなり敷居が高いように思えますが、リソース管理者自身が「社外秘情報の判別と、そのアクセス権まで管理していた」ACLベースのアクセス管理手法と比較すれば、はるかに容易ですし、安全性は高まります。
3. 策定したセキュリティポリシーを ID 管理者に通達する
アクセスルールはユーザーの属性をベースに判定されるので、ID 管理者には常に最新の ID 情報を保持してもらう必要があります。重要なデータであればあるほど迅速性が求められるため、それなりの ID管理基盤（ユーザープロビジョニングシステム等）が必要となる場合もあるでしょう。もしかするとアクセスポリシーを適用するために最適な属性が存在せず、Active Directory のスキーマに手を入れざるをえない可能性もあります。 ただし、あまりに複雑なルールは運用に破たんを招きますので、極力既存のID管理手法を維持しつつ、アクセスルール側で複雑な設定は吸収したほうがよいでしょう。 各種法令は無駄に複雑なプロセスを求めるものではありません。 基本は、中央のセキュリティポリシーがリソースに対して強制力もち、参照や編集できる権限を持った人が限定的でありかつ明確であること。そしてそれがトラッキング（監査）できることです。権限を持たない人間が絶対にアクセスできないようになっていることが重要です。
アクセスルールはユーザーの属性をベースに判定されるので、ID 管理者には常に最新の ID 情報を保持してもらう必要があります。重要なデータであればあるほど迅速性が求められるため、それなりの ID管理基盤（ユーザープロビジョニングシステム等）が必要となる場合もあるでしょう。もしかするとアクセスポリシーを適用するために最適な属性が存在せず、Active Directory のスキーマに手を入れざるをえない可能性もあります。
ただし、あまりに複雑なルールは運用に破たんを招きますので、極力既存のID管理手法を維持しつつ、アクセスルール側で複雑な設定は吸収したほうがよいでしょう。
各種法令は無駄に複雑なプロセスを求めるものではありません。
基本は、中央のセキュリティポリシーがリソースに対して強制力もち、参照や編集できる権限を持った人が限定的でありかつ明確であること。そしてそれがトラッキング（監査）できることです。権限を持たない人間が絶対にアクセスできないようになっていることが重要です。
4. セキュリティポリシーをシステムに反映する
システムに反映するには DAC のお作法にのっとって作業する必要があります。これについては次回詳しく解説しますが、「セキュリティポリシーの集中管理」と聞けば何を使うかはだいたいわかりますよね？そう、グループポリシーです。作成したアクセスルールをグループポリシーにのせて、社内のリソースに配信するわけです。
このように、DAC は ACL ベースのアクセス管理では行えなかった「ID 管理」「リソース管理」「全社アクセスルールの管理」の 3 者を分離し、それぞれの専門部隊の相互連携によって最大限の効果を発揮できるようにするための仕組みです。
DAC にはアクセス権を管理する以外にも、監査ルールを集中管理したり、FCI（File Classification Infrastructure）との連携による自動分類が可能です。FCI と連携することで、社外秘データを暗号化したり、法廷保存期間に沿って特定フォルダに保管したりといった作業を自動化することもできます。これらについて詳しくは別投稿で。
＜その１ その３＞
DAC と書くと「 discretionary access control（随意アクセス制御）」を思い浮かべてしまう方も多いと思いますが、ここでは「Dynamic Access Control（ダイナミックアクセス制御）」を指しています。
※ちなみに RBAC とは Role-Based Access Control の略ですが、詳しくは本文中で。
Windows Server 2012 から実装された新しい機能「ダイナミックアクセス制御」。みなさんご利用でしょうか？以前以下の投稿をしましたが、あまり見られていないですね（笑）。なんか、あのころの AD FS を見るようだなぁと。。。
【IAM】ダイナミックアクセス制御（DAC）を理解するための解説&演習手順書 http://blogs.technet.com/b/junichia/archive/2012/12/17/3541225.aspx
そこで、なぜ DAC なるものが必要なのか？という点についてまとめておきたいと思います。
ACL ベースのアクセス制御
「アクセス制御」という言葉があります。アクセス制御については説明するまでもありませんが、「ユーザーがアクセスしてもよいかどうかを評価するプロセス」のことです。
ご存知の通り、従来マイクロソフトが採用しているアクセス制御方式は、「ACL 方式」です。
ACL とは Access Control List の略で、中には 「ACE（Access Control Entory）」と呼ばれるエントリーが格納されています。ACE にはユーザーやグループを識別するための SID（Security ID）とアクセス権が格納されており、これによってユーザーのアクセス権が識別されます。ACL に複数のACEが格納されている場合、これらは基本的に「OR」で評価されます（ただし、同じSIDが複数のACEに格納されている場合には、その中の一番厳しいアクセス権が採用されるという大原則があります）。
ACL は「静的」です。つまり、誰かが手で設定しなければ変わることはありません。つまり一度アクセス権が与えられたら、ACL から ACE を削除するか、ACE を変更するまで永遠に現在のアクセス権が与えられ続けます。そこで、組織間で人材が移動してもリソース側に直接手を入れる必要が無いようにするため、マイクロソフトでは「グループにアクセス権を与える」方法を推奨しています。グループにアクセス権を与えることで、アクセス権の制御を「グループのメンバーシップの変更」で置き換えようという考え方です。こうすれば、リソース側のアクセス権を直接操作する必要はなくなります。こうしたアクセス権管理の方式を AGDLP と呼んでいます。
ただ、これで何も問題がないわけではなく別の問題が浮上することになります。「グループ管理の煩雑さ」です。
組織が「静的」であれば問題はありませんが、そんなはずはありません。人材の流動化が進むにつれ組織は日々変化します。つまり、組織は「動的」なのです。それでも、年に1回であれば担当者ががんばってバッチ処理を回せばなんとかなるかもしれません。しかし人の出入りが短いスパンで発生するマイクロソフトのような企業では、バッチ処理では「迅速で正確な」対応が難しくなります。これは安全性を維持するための「アクセス制御」にとって致命的です。
ユーザー プロビジョニング システムによる管理
そこで、これを解決するために採用されているのが「メタデータをベースにしたユーザープロビジョニング」システムです。論理的に中央に置かれたメタデータベースにはすべてのユーザーや組織情報が集中管理されています。マイクロソフトでいえば、Forefront Identity Manager（FIM）が該当します。
こうしたシステムを使用すると、静的な ACL を「動的」に管理することができるようになります。たとえば、ユーザーの属性が「営業部」から「マーケティング部」に変更されたとします。これにともない、内部のワークフローエンジンは、「営業部グループ」に所属していた当該ユーザーを「マーケティンググループ」に自動的に移動します。
ここで使用されるのが「Expression-Based グループ」と呼ばれるものです。Expression とは「式」のことで、グループのメンバーであるための条件を「式」で表現しておくことができるのです。たとえば「所属が営業部」かつ「役職がManager」と設定しておけば、所属と役職が合致したユーザーが、自動的にメンバーとして追加されます。
こうした仕組みによって、アクセス権の管理をある程度自動化できます。
グループを使用した RBAC の破たん ?
役割によってアクセス権を管理することを一般的に RBAC（Role-Based Access Control）と呼びます。
企業内でアクセス権を管理する場合、グループには「役割」という意味付けがなされます。つまり、適切な役割を持ったユーザー��対してリソースへのアクセス権を与えるという考え方です。それを既存のシステムに反映しようとすれば、必然的に「役割＝グループ」となります。
RBAC 自体合理的な考え方ではありますが、この「役割」というのが案外曲者です。部署ごとや役職ごとにグループを作成している分にはさほど面倒ではありません。しかし、グループの設計につきものなのが「グループ数の膨張」です。
リソースの管理者からすれば、「厳密にアクセス権を管理したい」と考えるのは当然ですが、残念ながらグループには汎用性がありません。メンバーが一人でも異なれば（つまり役割が異なれば）別のグループ（役割）を作成する必要があります。中にはメンバーが一人しかいないグループが多数存在することにもなります。
そうなると ID 管理側は超大変です。リソースの管理者がグループを作成する権限を持っていない場合、要求に応じて次々とグループを作成しなければなりません。それでも作成までは何とかなるかもしれませんが、「棚卸」となるともうお手上げです。どのグループが使われていて、どのグループを削除してもよいのか、設計したリソース管理者でさえもわけがわからなくなっているはずです。これでは、合理的にセキュリティを維持するはずの RBAC の思想が完全に破たんします。不必要なグループを（念のため～とか言いながら）残しておくほど安全性を脅かすものはありません。
Expression-Based アクセス制御
そうした問題を軽減するため、マイクロソフトは Windows Server 2012 に「ダイナミックアクセス制御」と呼ばれる機能を実装しました。このベースとなっているのが、Expression-Based Access Control です。
Expression-Based については先に書いた通り「式」によって表現する方式ですが、ダイナミックアクセス制御の場合には「式」によってアクセスルールを定義します。
例えば、ユーザーが Country 属性とDepartment 属性を持っているとします。そして、リソース側にも同じ属性が用意されているとします。アクセスルールとして「(user:country = resource:country) and (user: department = resource: department)」と定義しておけば、ユーザーは自分と同じ属性の値を持ったリソースに対してアクセス権を持つことができます。
もちろんこれは単純な例ですが、もっと複雑に記述することも可能です。
ACL ベースでは「OR」評価のみでしたが、DAC の場合には「OR」も「AND」も思いのままです。もちろん、MemberOf を使用して「グループのメンバーだったら」といった表現も可能なので、ACLベースのアクセス制御で蓄積してきたグループを引き継ぐこともできます。
さらに言えば、アクセス制御にはデバイスを含めることもできます。
この方式の利点は柔軟性だけではありません。ID管理側とリソース管理側で分業が行えます。リソース側は「使わせたい人やデバイスの条件（要求）」をリソースのプロパティとして定義しておけばよく、ID管理側はユーザーやデバイスの属性を正確に管理しておけばよいのです。もちろん、こうなると両者にスピードと品質が求められることは言うまでもありません。
。。。。ここで AD FS を使用したクレームベースのアクセス制御を思い浮かべた人は「非常に正しい」です。実は、DAC で使用しているテクノロジーというのは、AD FS 2.1 で新たに実装されたテクノロジーと密接に関係しているのです。
【IDM】Active Directory Federation Service 2.1 の新機能 http://blogs.technet.com/b/junichia/archive/2012/12/10/3539674.aspx
以上のように、非常に柔軟な「ダイナミックアクセス制御」なのですが、いかんせん実装にたどり着くまでの「理解」が難しい！！！！AD FSと初めて対峙したときのような難解さです。
次回の投稿では、DAC がなぜ企業のアクセスコントロールにおいて重要であるのか。。について解説します。
その２ へ
VHDBOOT で使用していた VHDX ファイル（Windows 8 Enterprise）をメンテナンスしようと、Hyper-V 上の仮想マシンのシステムディスクとして設定し起動しようとしたところ、以下のようなエラーが発生して起動できなくなってしまいました。
回復
お使いの PC は修復する必要があります。 要求されたデバイスが接続されていないか、デバイスにアクセスできません。
エラーコード: 0xc000000e
仰せの通りに回復ツールで回復しようと思い「PCのリフレッシュ」を実行しようとしたところ、今度は以下のエラーが出ました。
Windows がインストールされているドライブがロックされています。ドライブのロックを解除してやり直してください。
VHDX ファイルをマウントして確認してみても、特におかしなところはみあたらず。
調べてみると、0xc000000e エラーは BCD ストアの破損に類するトラブルらしく、ここを修復しないことにはどうにもなりません。
(参考)ブート構成データ（BCD）ストアを理解すれば VHDブート は簡単 http://blogs.technet.com/b/junichia/archive/2009/10/26/3289120.aspx
ひとまず仮想マシンに Windows 8 の ISOイメージをマウントして、ISOから起動します。
「今すぐインストール」を脊髄反射でクリックせずに、おちついて「コンピューターを修復する」をクリック。
「トラブルシューティング」を選択。
「詳細オプション」を選択。
「コマンドプロンプト」を選択。
コマンドプロンプトが表示されたら、すかさず bcdedit コマンドでBCDストアの状態を確認してみます。
すると。。。なんと、device エントリと osdevice エントリが unknown ! これじゃ、起動するはずがありません。
ということで、bcdedit コマンドでエントリを正しく修正します。対象となるエントリの Identifier が {1b09e76-2efa-11e2-aca3-e1d02980083a} であることは、以下に表示されているとおりです。
起動したい Windows 8 は D ドライブとして見えています。
よって、以下のコマンドで正しい情報を登録します。
bcdedit /set {1b09e76-2efa-11e2-aca3-e1d02980083a} device partition=D:
bcdedit /set {1b09e76-2efa-11e2-aca3-e1d02980083a} osdevice partition=D:
Exit して再起動すると、今作成したエントリから無事起動することができました。
冷や汗かきました。
Windows Azure を Windows PowerShell をはじめとするコマンドラインから管理するためのモジュールが以下からダウンロードしてインストールすることができます。
http://www.windowsazure.com/en-us/downloads/?fb=ja-jp
これにより、Windows PowerShell のコマンドレットや、Azure.cmd コマンド等が使える用意なり、それはそれは大変便利な環境になります。
が、難点は、コマンドがどこを触っているのかさっぱりわからないこと。
特に、以前は証明書の作成も含めて自分でやらなければならなかった管理証明書（API証明書）のインストールやアップロードなんかは、以下のコマンドレットを使用して簡単に行えるようになりました。
Import-AzurePublishSettingFile コマンドレットを実行して .publishsettings ファイルを取り込むと何が行われるかというと、以下の通りです。
ここに保存したサブスクリプション情報が裏で使用されて管理プロセスが動きます。
これ、非常に便利なのですが、「環境をきれいにしよう」なんつってうっかりローカルの証明書を消してしまったりするとさぁ大変。
以下のようなエラーが出て、コマンドレットがことごとく使えなくなります
PS C:\windows\system32> Select-AzureSubscription コマンド パイプライン位置 1 のコマンドレット Select-AzureSubscription 次のパラメーターに値を指定してください: (ヘルプを表示するには、「!?」と入力してください。) SubscriptionName: junichia Select-AzureSubscription : No certificate was found in the certificate store with thumbprint 4EAAE4F5CF86FEA8625A9688A6E05DBA79363882 発生場所 行:1 文字:1 + Select-AzureSubscription + ~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : CloseError: (:) [Select-AzureSubscription]、ArgumentException + FullyQualifiedErrorId : Microsoft.WindowsAzure.Management.Cmdlets.SelectAzureSubscriptionCommand
原因は、publishSettings.xml と DefaultSubscriptionData.xml ファイルに書き込まれた管理証明書がローカル無いためです。
かといって削除してしまったものは復活できないので、仕方ありません。いさぎよく、この２つのファイルを消してしまう。。。またはテキストエディタで開いて、当該サブスクリプションに関するエントリを削除します。その後、再度 Import-AzurePublishSettingFile を実行しなおしてファイルを再生成すれば OK です。
便利になるのはいいんですけどねぇ。トラブルと面倒なんですよね。。。
※この投稿は、あくまでも現在公開されているドキュメントやBLOG、および自身による動作検証をもとにしたものであり、マイクロソフトが正式にドキュメント化しているものではありません。あくまでも「ご参考」ということでよろしくお願いいたします。検証作業等の参考になれば幸いです。
Windows Azure Active Directory と Office 365 の関係を調べていると疑問がつきません。
特に、Access Control Service との関係など、なにがどうなっていて、どこまで認証部分をカスタマイズできて、何ができなくて。。。といったことで夜も眠れなくなります。
そこで、「こんなかんじなんじゃないか?」という予想をまとめたものが以下の図です。
なんとなく、Access Control Service（ACS） が使われているように思いがちなのですが、従来 MFG（Microsoft Federation Gateway）と呼ばれていた STS（Security Token Service）が使われているような気がします（MFGと呼んでいるかどうかは定かではありません）。ただ、MFG の Endpoint が以下のURLなので、全くACSを使っていないというわけでもなさそうで。。。
https://account.accesscontrol.windows.net/<テナントのURL>
ちなみに、ACS の Endpoint は以下のような URL になります。
https://<Namespace名>.accesscontrol.windows.net/
ちなみに、以下の図で赤丸を付けた部分は、Set-MsolDomainAuthentication というコマンドレットを使用して関連付けることができます。選択できるプロトコルは WS-Federation と SAML 2.0 なので、いずれかに対応した独自 STS を開発すれば「理論上」は MFG の IdP として関連付けることができるはずです。
逆に、MFG の RP として ACS を登録する方法については Vittorio の blog で紹介されています。
Provisioning a Windows Azure Active Directory Tenant as an Identity Provider in an ACS Namespace http://blogs.msdn.com/b/vbertocci/archive/2012/11/07/provisioning-a-directory-tenant-as-an-identity-provider-in-an-acs-namespace.aspx
つまり、以���のようにAzure ADをACSのIdPとして登録することができるわけですね。
では、逆に、以下のようなことはできるのか？？？？？？
つまり、Facebook の ID を使用してOffice 365 を使用するために、MFG に IdP として ACS を登録するというものです。理論上できそうなのですが、成功しておりません。以下に Shibboleth を MFG と信頼関係を結ぶための手順が公開されていますので、これを参考にどなたかチャレンジしてみていただけないでしょうか～
http://technet.microsoft.com/ja-jp/library/jj205463.aspx
ということで、非常に怪しい話ばかりで恐縮なのですが、なんとなく「こうなんてるんだろうなぁ」的なところをうっすらご理解いただければと思います。
繰り返しますが、この記事は私の予想ですので、くれぐれもよろしくおねがいいたします。
Office 365 と Windows Azure Active Directory の組み合わせで、二要素素認証が使用できるようになりました（2013年3月5日現在 プレビュー）。
Windows Azure, now with more enterprise access management! http://blogs.msdn.com/b/windowsazure/archive/2013/03/04/more-identity-and-access-management-improvements-in-windows-azure.aspx
これはどのような仕組みかというと。。。。以下をご覧ください。
ユーザーがブラウザを使用して ID とパスワードを使用してサインインします。ここでIDとパスワードの検証が正しく行われると、事前に登録してある携帯電話やスマフォに電話がかかってきます。これに「#」を押して応答することで認証が成立するというものです。設定によっては、右側の図のように、ショートメッセージが送られてきて、そこに書かれているコードを入力して返信すれば認証することもできます。
この仕組みを使用するには、はじめに Office 365 を契約（評価版でもOK）します。この時にサインアップしたID（例 hogehoge@hogeorg.onmicrosoft.com）を使って Windows Azure の管理画面（例 https://manage.windowsazure.com/hogeorg.onmicrosoft.com/ ）にアクセスしてログオンします。
Windows Azure Active Directory の管理画面を開くと、Office 365 で作成したドメインが表示されています。
※この機能も新しく実装されたものです
ドメインをクリックしてユーザー一覧を開いてください。Office 365 で登録したユーザー一覧が表示されます。
二要素認証を使用したいユーザーをクリックして、プロファイルを開くと、以下のように「多要素認証が必要です」をチェックできるようになっています。
このまま保存すれば、以降、IDとパスワードに加えて電話による応答が要求されるようになります。
実際の流れは以下の通りです。
1. サインイン画面で ID とパスワードを入力
2. 以下のような画面が表示される
3. 電話番号が設定されていないと、以下の画面が表示されるので「今すぐ設定」をクリック
4.電話番号を入力。もし、SMSでの応答を希望するならば、「電話ではなくメッセージで通信」をチェックして、保存する。番号は、頭の「0」は取って保存する。
5. 設定が正しいかどうかの確認電話（録画音声）がかかってくるので「#」を押して応答するか、ショートメッセージが送信されてくるので、応答する。
※電話の場合には「マイクロソフトの検証システムをご利用いただきありがとうございます。つづけるには「#」を押してください」とメッセージが流れます。
6. 正しく応答すると、以下のように表示され「設定が完了」するので「閉じる」
7. あらためて、サインインのための電話がかかってくるので正しく応答すればサインイン完了です。
万が一、電話がかかってこなかったりショートメッセージが送られてこない場合には、「その他の検証オプション」をクリックして別の電話を選択したり、応答の方法を変更してみてください。
なお、プレビューなのでいつトラブルかわかりません。本番環境では全員に設定するなんてことはせず、かならずテストアカウントで検証を行いましょう。
既に多くの方がご存知の通り、WinRT アプリをインストールする方法は、以下のいずれかです。
図にすると以下の通りです。
サイドローディングを行うにはライセンス上の制約が存在しています。以下の通り、Windows 8 Enterprise であれば無償で、Windows 8 Professional または Windows RT の場合には、別途サイドローディング用のライセンスを購入してインストールしないとサイドローディングできません。つまり、企業のデバイスに Windows 8 を展開しようと考えている IT 部門の方で、業務アプリを WinRT アプリとして今後開発しようと考えていらっしゃる場合には、"無印の" Windows 8 を購入してはいけないということです。
さて、話を少し変えます。
WinRT アプリのサイドローディングについて調べていると、ときどき「プロビジョニング」という言葉が出てきます。これはなんでしょう？言葉自体は珍しくはないですが、従来のデスクトップアプリでは「プロビジョニング」という用語はあまり見られませんでした。あきらかに「インストール」とは異なる使い方をしています。
以下の図にまとめてみましたが、WinRT アプリは従来のデスクトップアプリとは異なり、「インストール」はユーザープロファイルフォルダ内に行われます。つまり、デスクトップアプリのように「誰かがインストールしたら、アイコンだけ表示させれば誰でも使える」というものではありません。
Windows ストアの場合、インストールしたアプリケーションは Microsoft アカウント（旧称 Live ID または Hotmail ID）ごとに管理され、他のユーザーには影響を与えないように管理されています。これはサイドローディングの対象となる業務アプリケーションでも同様で（サイドローディングの場合には Microsoft アカウントは関係ありません）、一人が業務アプリをサイドローディングしたからといって、同じデバイスを使用する別のユーザーが使えるようになるわけではありません。
では、デスクトップアプリのように、デバイスを使用する全ユーザーに使わせたい場合にはどうするかといえば「プロビジョニング」を行います。プロビジョニングとは、WinRT アプリを OS 上にステージングすることなのです。プロビジョニングを行うには、Windows PowerShell のコマンドレットに用意されている Add-AppxProvisionedPackage を使用します。
詳しくは以下の記事をご覧ください。
ITPRO のみなさん、新しい Windows Intune（インチューン）って使いましたか？すばらしいです。すばらしいの一言です。 最新バージョンでは値段も下がって、導入も手軽になりました。 安いプランで 490円（1ユーザー（PC5台まで、月額））。 ※最低契約期間は12か月ですので、この点はご注意を。でも安いですけどね～。 Windows Intune とは、SaaS 版の運用管理ツールです。SaaS で提供される簡易版 System Centerと考えていただけるとわかりやすいと思います（System Center そのものではないのでご注意を！）。 製品概要 http://www.microsoft.com/ja-jp/windows/windowsintune/explore.aspx 購入ガイド http://download.microsoft.com/download/0/F/F/0FFA03C3-20EF-4B8F-A151-8CE13D85787E/Windows_Intune_Purchase_Support_Guide_2013Jan_Final.pdf それはそうと、Windows 8 の WinRT アプリの配信について悩んでいらっしゃる方も多いと思います。 WinRT アプリの配信（ストアを使わずに）には、ざくっとですが、以下の4種類の方法が用意されています。 Windows PowerShell を実行してインストール Windows のマスターイメージに組み込んで、イメージごと配信 Windows Intune で配信 System Center Configuration Manager 2012 SP1 を使用する PowerShellによる手動は面倒だし、イメージ配信まで大がかりなことは考えていない。かといって、System Center はちょっと敷居が高い。。。という方は、ぜひとも Windows Intune を試してみてください。評価版で十分にテスト可能です。 手順を以下の PPT にまとめておきましたのでご覧ください。 http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-56-58/2043.WinRT-Apps-Deployment-w-Winows-Intune.pptx
ITPRO のみなさん、新しい Windows Intune（インチューン）って使いましたか？すばらしいです。すばらしいの一言です。
最新バージョンでは値段も下がって、導入も手軽になりました。
安いプランで 490円（1ユーザー（PC5台まで、月額））。
※最低契約期間は12か月ですので、この点はご注意を。でも安いですけどね～。
Windows Intune とは、SaaS 版の運用管理ツールです。SaaS で提供される簡易版 System Centerと考えていただけるとわかりやすいと思います（System Center そのものではないのでご注意を！）。
製品概要 http://www.microsoft.com/ja-jp/windows/windowsintune/explore.aspx
購入ガイド http://download.microsoft.com/download/0/F/F/0FFA03C3-20EF-4B8F-A151-8CE13D85787E/Windows_Intune_Purchase_Support_Guide_2013Jan_Final.pdf
それはそうと、Windows 8 の WinRT アプリの配信について悩んでいらっしゃる方も多いと思います。
WinRT アプリの配信（ストアを使わずに）には、ざくっとですが、以下の4種類の方法が用意されています。
PowerShellによる手動は面倒だし、イメージ配信まで大がかりなことは考えていない。かといって、System Center はちょっと敷居が高い。。。という方は、ぜひとも Windows Intune を試してみてください。評価版で十分にテスト可能です。
手順を以下の PPT にまとめておきましたのでご覧ください。
http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-56-58/2043.WinRT-Apps-Deployment-w-Winows-Intune.pptx
以前、以下の投稿をしました。
http://blogs.technet.com/b/junichia/archive/2012/12/10/3539674.aspx
ダイナミックアクセス制御はとても面白いテクノロジーなのですが、かなり複雑なので手を付けている方は少ないのではないでしょうか。
そこで、現在実施しているハンズオンセミナーで使用している資料から、ダイナミックアクセス制御の部分を抜粋して公開しました。
解説編と演習編に分かれています。
演習環境はシンプルで、以下の２つの仮想マシンを用意していただければOKです。
細かな設定は必要ありません。すべて演習の中で一から構築していきます。
Windows 8 の Hyper-V でも問題なく演習できます。
是非、社内の勉強会等���も活用してください！
Dynamic Access Control 解説編
Dynamic Access Control 演習編
※この投稿は Office 365 Advent Clendar 2012 に参加しています。
軽い話題ですんません。
私の大好きな Active Directory Federation Service 2.0 は、Office 365 の爆発的人気に伴い、今ではすっかりフィールドに浸透しました。もう、「AD FS なんて知らない、聞いたことない」という方はいらっしゃらないでしょう。
そんな中、いまひそかに熱い注目を集めているのが Windows Server 2012 に標準実装された Active Directory Federation Service 2.1 です。新しい Hyper-V や Failover Cluster の陰に隠れて目立たないことこの上ないですが、地味ながら確実に進化しています。
Active Directory フェデレーション サービス(2.1)の概要 http://technet.microsoft.com/ja-jp/library/hh831502.aspx
上記サイトにも書かれている通り、AD FS 2.1 の新機能として3つが挙げられています。
ここで大いに気になるのは 3 つ目です。「Kerberos チケットからクレームを取得する」とはどういうことでしょう?そして、どんな効用があるのでしょうか?
（参考）Using AD DS Claims with AD FS（英語） http://technet.microsoft.com/ja-jp/library/hh831504.aspx
上記英語サイトにも書かれている通り、Windows Server 2012 の Active Directory には大きく分けて2種類の「クレーム」が存在しています。
基本的に、AD FS 2.0 から見れば Kerberos チケットは「ユーザーが AD DS に認証された証」であり、AD FS が Kerberos チケットからクレームとして得られるのは、ユーザーの SID およびユーザーが所属するグループの SID でした。
AD FS 2.0 ではその他に、AD DS や AD LDS および SQL Server に格納された情報をクレームとして収集し SAML トークンに変化することができました。
しかし、その対象は「ログオンしているユーザー」をキーとしたものであり、例えばログオンしているデバイスに関する情報を収集することができませんでした。そのため、「ログオンしているコンピューターによってアクセスを制御する」ことが難しかったのです。
そんな中、革命ともいえる新たな機能が Windows Server 2012 に実装されました。それが Dynamic Access Control（ダイナミックアクセス制御）です。この機能は、Kerberos チケットにユーザーやグループ、そしてユーザーがログオンしているデバイスの属性をクレームとして格納し、それらの情報とファイルサーバーの ACL を比較することで、アクセスの可否を判断する機能です。従来のグループベースの静的なアクセス制御と異なり、日々変化するユーザーやデバイスの属性にダイナミックに対応できることから、新しいアクセス制御方式として注目されています。
※ただし、グループポリシーで「複合認証」を有効にする必要があり、これは Windows 8/Windows Server 2012/Windows RT でのみサポートされています
そして、この機能は AD FS 2.1 にとっても大きな革命なのです。
先に書いたように、AD FS 2.1 では、Kerberos チケットに格納されているクレームを読み取ることができるようになりました。
つまり、AD DS 側のダイナミックアクセス制御でデバイスポリシーが設定されており、かつ AD FS 側で Kerberos チケットからクレームを受け取るための要求規則が書かれていれば、ユーザーの属性だけでなくログオンしているデバイスの属性をもとに、クレームベースのアプリケーションに対するアクセス制御が行えるようになる。。。というわけです。
これは、今後、Office 365 ユーザーにとっても期待の大きな機能であるはずです。
。。。。とはいえ、具体的な設定に関する解説がどこにも掲載されていないため、これについては追ってまとめたいと思います。
また、ダイナミックアクセス制御についても、結構複雑なテクノロジーとうこともあって使ったことがある方は少ないと思います。こちらも概念を含めてまとめていきたいと思いますのでご期待ください。
※この投稿は、PowerShell Adcent Calender 2012 に参加しています!
Hyper-V 上の仮想マシンが使用しているリソースを計測するにはパフォーマンスモニターを使用することができました。
Measuring Performance on Hyper-V http://technet.microsoft.com/ja-jp/library/cc768535(v=bts.10).aspx
しかし、パフォーマンスモニターの利用になれた方であればまだしも、通常は使用するカウンターの選定など、ちょっと面倒な面も否めません。
そこで、Windows Server 2012、Windows 8 に実装されている Hyper-V では、ゲスト OS のリソース使用量を容易に計測できる Windows PowerShell コマンドレットが用意されました。Measure-VM です。
パフォーマンスモニターが仮想マシンの正常性を計測することを主目的としていたのに対し、このコマンドレットの主な目的は「課金」です。例えば、ホスティングを担当する企業による利用を想定しています。
Measure-VM コマンドレットを使用すると以下の数値を取得することができます。
ここで、CPUの「使用率」ではなく「使用量」であることに注意してください。先にも書いた通り、Mesure-VM の主目的は「課金」です。よって、CPU の使用率では意味がありません。なぜならば、使用している物理マシンによって使用率が変わる可能性が大きいからです。よって、Mesure-VM は使用率ではなく実際にゲスト OS が使用した CPU の使用量を MHz で出力するように設計されています。
ネットワークについても同様です。帯域の使用率ではなく、実際に送受信したデータ量を算出してることに注意してください。
いずれも、計測を開始してから Measure-VM コマンドレットを実行した瞬間までを計測します。
では使ってみましょう。
＜計測開始＞
計測を開始するには、ゲストOS のメータリング機能を有効にする必要があります。以下はゲストOS Server1 に対してメータリングを有効にしています。
Get-VM -Name Server1 | Enable-VMResourceMetering
または
Enable-VMResourceMetering –Name Server1
<使用量の出力>
Enable-VMResourceMetering を実行してからの使用率が出力するには Measure-VM コマンドレットを使用します。以下はその出力例です。
PS C:\windows\system32> Measure-VM -Name server1
VMName AvgCPU(MHz) AvgRAM(M) MaxRAM(M) MinRAM(M) TotalDisk(M) NetworkInbound(M) NetworkOutbound(M) ------ ----------- --------- --------- --------- ------------ ----------------- ------------------ Server1 3 1000 1000 1000 130048 178 112
<使用量のリセ���ト>
特定の時間間隔の使用量を出力するには、いったん前回までの使用量をリセットする必要があります。そのために Reset-VMResourceMetering コマンドレットが用意されています。以下のように入力することで、ゲストOS Server1 の使用量がいったんリセットされ、0から再計測が始まります。
Reset-VMResourceMetering –Name Serevr1
では、これらを使用して実際にゲストOSのコストを計測するにはどうしたらよいでしょう？
例えば、以下のようなスクリプトを作成します。
$VMName = "Server1" Calculate-VMCost($VMName)
function Calculate-VMCost($VMName) {
#ベースコストを設定 $BaseCost = 50
#各要素の単位コストを設定（例） $MemoryCostPerGB = 20 $ProcessosCostPerGHz = 30 $IncomingNetworkCostPerGB = 10 $OutgoingNetworkCostPerGB = 30
# 前回の取得から現時点までののリソース使用量を取得 $ChargebackData = Measure-VM $VMName
#ここまでの計測をリセット Get-VM $VMName | Reset-VMResourceMetering
#ベースコスト $VMCost = $BaseCost
#コストにメモリ使用コストを加える $VMCost += $ChargebackData.AverageMemoryUsage * $MemoryCostPerGB / 1024
#コストにCPU使用量を加える $VMCost += $ChargebackData.AverageProcessorUsage * $ProcessosCostPerGHz / 1024
#ネットワーク受信量を算出 $IncomingExternalTraffic = $data.NetworkMeteredTrafficReport | ` ? { ($_.Direction -eq "Inbound" ) -and ($_.RemoteAddress -eq "*.*")}
#ネットワーク送信量を算出 $OutgoingExternalTraffic = $data.NetworkMeteredTrafficReport | ` ? { ($_.Direction -eq "Outbound") -and ($_.RemoteAddress -eq "*.*")}
#コストにネットワークこすとを加える $VMCost += $IncomingExternalTraffic.TotalTraffic * $IncomingNetworkCostPerGB / 1024 $VMCost += $OutgoingExternalTraffic.TotalTraffic * $OutgoingNetworkCostPerGB / 1024
$VMCost }
こうしたスクリプトを使用することで、ゲストOSのコストを総合的に判断し課金額の算出に利用することができます。
（参考）
Hyper-V リソース メータリングに関するテクニカル プレビュー http://technet.microsoft.com/ja-jp/library/hh831661.aspx
Enable-VMResourceMetering http://technet.microsoft.com/ja-jp/library/hh848481.aspx
Introduction to Resource Metering http://blogs.technet.com/b/virtualization/archive/2012/08/16/introduction-to-resource-metering.aspx
もうすっかり古いはなしになるのですが、9月28日、MSC 2012 で SC-006 セッションにご参加くださった皆様、ありがとうございました。
冒頭で、Windows Server 2012 で構築した仮想ドメインコントローラーを Windows PowerShell を使用してクローンするデモを行いました。
その際に使用したスクリプトを掲載します。
（公開されている資料に書かれているものに若干不具合がございました…すみません）
それにしても、たったこれだけのスクリプトでDCが複製できてしまうなんて….Hyper-V 2012 + New AD すてきです。
スクリプトの実行環境は以下の通りです。（ITCAMP-FS は Hyper-V ホストです）
スクリプトの解説は以下をご参照ください。
仮想化した DC を PowerShell で複製する http://www.slideshare.net/junichia/dc-powershell
スクリプトは以下からダウンロードできます（大したもんじゃないですが…）
スクリプトのダウンロード http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-56-58/8233.CloneDC.ps1
$SourceDC = "ITCAMP-DC02"
$DistDC = "ITCAMP-DC03"
$distPDCEmu = "ITCAMP-DC01"
$SourceHyperVHost = "ITCAMP-FS"
$DistHyperVHost = "ITCAMP-FS"
$VMStore = "\\$DistHyperVHost\VMStore"
$ConfirmPreference = "none"
Move-ADDirectoryServerOperationMasterRole -Identity $distPDCEmu -OperationMasterRole PDCEmulator
Get-ADComputer $SourceDC | %{Add-ADGroupMember -Identity "Cloneable Domain Controllers" -Members $_.samAccountName}
Invoke-Command -ComputerName $SourceDC -ScriptBlock { Get-ADDCCloningExcludedApplicationList -GenerateXml -Force }
Invoke-Command -ComputerName $SourceDC -ScriptBlock { `
New-ADDCCloneConfigFile -Static -IPv4Address "192.168.210.52" ` -IPv4DNSResolver "192.168.210.50" ` -IPv4SubnetMask "255.255.255.0" ` -IPv4DefaultGateway "192.168.210.254" ` -CloneComputerName "$Args" ` -SiteName "Default-First-Site-Name" } ` -ArgumentList $DistDC
Stop-VM -ComputerName $SourceHyperVHost -Name $SourceDC
Get-VM -ComputerName $SourceHyperVHost -Name $SourceDC | %{ Export-VM $_ -Path $VMStore}
Start-VM -ComputerName $SourceHyperVHost -Name $SourceDC
$CFG = (Dir "$VMStore\$SourceDC\Virtual Machines\*.xml").FullName
MD \\$DistHyperVHost\F$\$DistDC
Import-VM -ComputerName $DistHyperVHost -Path $CFG -GenerateNewId -Copy-VhdDestinationPath F:\$DistDC
Get-VM -ComputerName $DistHyperVHost -Name $SourceDC |Where-Object {$_.State -EQ "Off"} | Rename-VM -NewName $DistDC
Start-VM -ComputerName $DistHyperVHost -Name $DistDC
システム管理者が待ち望んでいた RSAT がやっとリリースされました。
Windows 8 用のリモート サーバー管理ツール http://www.microsoft.com/ja-jp/download/details.aspx?id=28972
もちろん、日本語版です。
Windows Server 2012 には3種類のインストールモードが用意されています。
2番目の「最少GUI」構成を使用すると、サーバーマネージャーやMMCがインストールされ、管理に支障がない程度にはGUIを使用することができます。しかも、それぞれのモードを再インストールすることなく行き来できるのもGOODです。
なので、Windows Server のインストール後に基本的な初期設定を済ませ、その後GUIをアンインストールして Server Core モードに戻すこともできます。
では、Server Core 状態でGUIが使いたくなってしまったらどうするかといえば、もう RSAT しかないでしょう。
Windows Server 2012 に完全に対応したサーバーマネージャーを備えているので、いちいちリモートデスクトップで入りなおすことなく Winodws 8 RSAT のサーバーマネージャーから複数の Windows Server をリモートから管理できます。
すばらしいです。
仮想化の進行によってますますサーバーの数が増えるでしょから、今後は Winodws 8 を管理コンソールとして1台（仮想でもOKですが）設置し、どこから各サーバーを管理する…という手法が便利です。
すでにセキュリティチームの Blog にも掲載されていますが、こちらにも転載しておきたいと思います。
概要
暗号の 2010 年問題 (暗号の危殆化) や、Flame マルウェアによる証明書への脅威を背景に、マイクロソフトは RSA アルゴリズムに対する強化策として、2012 年 8 月 14 日 (米国時間) に、鍵長 1024 ビット未満の暗号鍵を持つ RSA 証明書をブロックする更新プログラム (KB2661254) を公開しました (マイクロソフト セキュリティ アドバイザリ 2661254)。この更新プログラムの適用により、鍵長 1024 ビット未満の RSA 証明書を使用する Web サイトが閲覧できなくなる、S/MIME メールの送受信ができなくなる、また 1024 ビット未満で署名された ActiveX コントロールやアプリケーションのインストールに失敗するなどの影響が出ます。影響の詳細は、「1024 ビット未満の暗号キーをブロックする更新プログラム (KB2661254) を 8/14 に公開 - その ２」でも解説していますのでご確認ください。
背景
2004 年 8 月に米国商務省国立標準研究所 (NIST) が発表した暗号強度強化に関する勧告 (NIST SP 800-57: Recommendation for Key Management) では、1024 ビット未満の RSA の危殆化 (解読可能性) に触れ、2011 年までに鍵長を 2048 ビットに強化する必要性を示しています。また日本政府も 2013 年度までに政府機関の情報システムにおいて使用されている暗号アルゴリズムを 2048 ビットに移行するという移行指針を発表しています。既に現在では、1024 ビット以上の証明書が主流になっており、マイクロソフト製品では Security Development Lifecycle (SDL) に基づき既定で 2048 ビット以上の証明書を使用しています。
全文は以下のページでお願いします。
1024 ビット未満の鍵長を持つ証明書を無効にする更新プログラム (KB2661254) の公開について http://technet.microsoft.com/ja-jp/security/jj656784
本日までなので念のために。
本日中に Windows Server 2012 RC 版をダウンロードしていただいた方に Windows Server 2012 製品評価版のオフィシャルDVDをプレゼントするという期間限定キャンペーンが9月4日17時をもって終了します。
ご希望の方は、お急ぎ、以下よりどうぞ。
Active Directory を Windows Azure 上の IaaS として展開するためのガイドラインが公開されていました。
元記事 Guidelines for Deploying Windows Server Active Directory on Windows Azure Virtual Machines（英語）
このガイドラインでは、Windows Azure 仮想マシン（Azure VM）上にADを展開する際の留意点について解説されています。
せっかくですので、内容を補足しつつ、ざくっと日本語で。
----
Windows 2000 とともに登場した Active Directory は、この10年で大きく進化しました。挙げればきりがありませんが、2012年はActive Directoryにとってさらに大きな飛躍の年になります。クラウドへの進出です。まさに飛躍ですね。
上の図でも触れられている通り、これまで Active Directory と Windows Azure の連携には「ハイブリッドクラウドシナリオ」が用意されてきました。Windows Azure上に展開したアプリケーションを利用するための独自に認証基盤を用意するのではなく、オンプレミスの Active Directory Domain Service（AD DS）で認証を行い、Active Directory Federation Service（AD FS）から発行されたセキュリティトークンを使用して、Azure 上のアプリケーションへのアクセスを認可するという方式です。これにより、クラウド上にパスワードを保存することなく、企業内から SSO でクラウドアプリが使用できます。
これに加えて、Windows Azure 上に Active Directory を展開するというオプションが用意されました。
“Windows Azure 仮想マシン” と “Windows Azure 仮想ネットワーク”は Windows Azure の IaaS の一部として提供される機能であり、この機能を使用することでWindows Azure を企業インフラの一部として活用することができ、ここに Active Directory を展開することができるようになります。
なお、Windows Azure Active Directory は従来の Windows Server AD とは、かなり趣が異なります。実体は AD DS ではなく AD LDS で、マルチテナントに対応した REST ベースのサービスです。Office 365 や Windows Intune が既に Windows Azure Active Directory を使用しており、Windows Azure に展開した独自のアプリケーションからも Windows Azure Active Directory を使用できるようになります。また、オンプレミスのWindows Server AD からユーザー情報を同期する仕組みもサポートする予定です。ちなみに、Windows Azure AppFabric ACS は、Windows Azure Active Directory ACS として統合されました。 よって、Windows Azure Active Directory とは、ID ストアでもあり、認証サービスであり、かつ他のアイデンティティプロバイダーと連携可能なアクセスコントロールサービスでもあるということです（ちょっと複雑ですが）。
Windows Azure Active Directory については以下をご覧ください。
Windows Azure Active Directory
では、Windows Azure VM に Active Directory を展開する際の留意点について詳しくみていきましょう。
はじめに
基本的には、オンプレミスの Hyper-V 上に Active Directory をインストールした場合と大きく変わることはありません。例えば、ネットワーク的に離れたブランチオフィスにドメインコントローラー（DC）を展開した場合、意識しなければならないのは「サイト」です。サイトとはすなわち…サブネットです。システム管理者はサイトを定義し、サブネットをサイトに関連付け、サイト間リンクを作成し、通信コストに応じて複製間隔を設定する必要があります。こうした留意点は、Active Directory の管理者であれば当然のリテラシですが、AD on Azure の場合にも同様の見当が必要です。
ただし、Windows Azure に特有の新しい概念が必要なので、はじめに”軽く”触れておきます。
1. Windows Azure 仮想ネットワーク
Windows Azure 仮想マシンがオンプレミスのネットワークと通信を行うには、Windows Azure 仮想ネットワークを使用する必要があります。Windows Azure 仮想ネットワークとは、クラウドとオンプレミスのサイト間通信を可能にする VPN です。なお、Windows Azure 仮想ネットワークは ピア・トゥ・ピア通信を可能にする Windows Azure Connect とは異なるので注意してください。 （参考）Networking （英語です。すんません）
Windows Azure 仮想マシンがオンプレミスのネットワークと通信を行うには、Windows Azure 仮想ネットワークを使用する必要があります。Windows Azure 仮想ネットワークとは、クラウドとオンプレミスのサイト間通信を可能にする VPN です。なお、Windows Azure 仮想ネットワークは ピア・トゥ・ピア通信を可能にする Windows Azure Connect とは異なるので注意してください。
（参考）Networking （英語です。すんません）
なお、すべてのアプリケーションサーバーがクラウド上にあり、かつオンプレミスと複製などの通信が発生しない場合、Windows Azure 仮想ネットワークを使用した通信経路を用意する必要が無いように思える場合がありますが、それはダメです。詳しくは以降で。
2. Windows Azure 仮想マシンでは静的IPアドレスがサポートされない
Windows Azure 仮想マシンでは静的なIPアドレスがサポートされません。よって、仮想マシンを展開する際にはDHCPを有効にしておかなければなりません。しかし Active Directory の経験者であれば、ここで疑問が出ます。「DC ってDHCPだとヤバイんじゃ？」そこで、Windows Azure 仮想ネットワークを使用して仮想マシンを作成すると、動的にIPアドレスが割り当てられ、これが永続化されます。一度割り当てられたIPアドレスは、仮想マシンが廃棄されるまで使用されるため、結果としてスタティックにIPアドレスを割り当てたのと同じ状態を維持することができます。 なお、これに関連してDNSに関する留意点もありますが、これについては後述します。
Windows Azure 仮想マシンでは静的なIPアドレスがサポートされません。よって、仮想マシンを展開する際にはDHCPを有効にしておかなければなりません。しかし Active Directory の経験者であれば、ここで疑問が出ます。「DC ってDHCPだとヤバイんじゃ？」そこで、Windows Azure 仮想ネットワークを使用して仮想マシンを作成すると、動的にIPアドレスが割り当てられ、これが永続化されます。一度割り当てられたIPアドレスは、仮想マシンが廃棄されるまで使用されるため、結果としてスタティックにIPアドレスを割り当てたのと同じ状態を維持することができます。
なお、これに関連してDNSに関する留意点もありますが、これについては後述します。
3. Windows Azure 仮想マシンは2種類の異なるディスクタイプを使用することができる
ディスクタイプの選択はドメインコントローラーにとってとても重要です。Windows Azure では、OSディスクとDataディスクという2種類のディスクを使用することができます。Dataディスクは、Writeキャッシュが無効に設定されており、データが確実にディスクに書き込まれるようになっています。ドメインコントローラーにおける書き込みミスはシステム全体に影響を耐える可能性があるため、このことは重要です。 よって、DC のデータベースおよびSysvol は Dataディスクに保存するようにしなければなりません。
ディスクタイプの選択はドメインコントローラーにとってとても重要です。Windows Azure では、OSディスクとDataディスクという2種類のディスクを使用することができます。Dataディスクは、Writeキャッシュが無効に設定されており、データが確実にディスクに書き込まれるようになっています。ドメインコントローラーにおける書き込みミスはシステム全体に影響を耐える可能性があるため、このことは重要です。
よって、DC のデータベースおよびSysvol は Dataディスクに保存するようにしなければなりません。
用語と定義
※ 以下は抜粋です。完全な用語集は Windows Azure Glossary を参照してください
オンプレミスのActive Directory では上記のようなことは発生しませんが、Windows Azure 仮想マシン上に Active Directory を展開した場合には、前述のように仮想ネットワークを使用して永続的なIP構成を手に入れておく必要があります。仮想ネットワークを使用すると、サービスヒーリングによってIPアドレスが変わることはありません。
つづく
久しぶりの投稿が業務連絡で恐縮です。
マイクロソフトは7月から新しい期が始まりました。
今年は Windows 8 や Windows Server 2012 等の新製品リリースを控え、その本格的な訴求に向けて着々と準備を進めております。
その一環として、ぜひとも皆様の声をおきかせいただきたく。
http://www.microsoft.com/japan/technet/survey/default.aspx
ほんの5分程度で済みますので、なにとぞよろしくお願いいたします!
p.s. 9月後半から Windows Server 2012 の無償ハンズオンを開始する予定です。詳細は追ってお知らせします。
Windows PowerShell 3.0 にはワークフロー機能が実装されています。もちろん、そのベースとなっているのは Windows Workflow Foundation 4.0 です。
例えば、以下のようなワークフローがあったとします。このワークフローでは、UserList.csv ファイルにの保存されたユーザー一覧を読みこんで、大量のユーザーを順次作成する処理を想定していると考えてください。
Workflow CreateUser { Get-Content -Path \\junichia-vdi\tools\ps\wf\UserList.csv -Encoding String | ` Out-File -Path .\UserList_Unicode.csv -Encoding unicode $UserList = Import-Csv -Path .\UserList_Unicode.csv foreach ($u in $UserList) { $UserID = $u.userID Echo -InputObject "$(Get-Date) $UserID を作成します" $password = convertto-securestring -Input $u.initialpassword -asplaintext -force $Department = $u.Department $FirstName = $u.FirstName $LastName = $u.LastName $HomeDirectory = \\Home\Share\$userID InlineScript { New-ADUser ` -Name $using:UserID ` -AccountExpirationDate 2012/12/31 ` -AccountPassword $using:password ` -ChangePasswordAtLogon $using:true ` -Department $using:Department ` -GivenName $using:FirstName ` -Surname $using:LastName ` -HomeDirectory $using:HomeDirectory ` -HomeDrive "Z:" ` -ErrorAction SilentlyContinue ` -ErrorVariable ERRORMESSAGE
If ($ERRORMESSAGE.Count -eq 0) { Echo -InputObject "$(Get-Date),$using:UserID を作成しました" } else { Echo -InputObject "$(Get-Date),$using:UserID $ERRORMESSAGE" } } Checkpoint-Workflow } }
ワークフローの実行までの流れは以下の通りです。
この例では、Invoke-Command を使用してリモートのドメインコントローラー上で、ワークフローをバックグラウンドジョブとして実行しています。
上図の左側に「Stopped」や「Running」と書かれているのはワークフローの状態です。
処理も半ばに差し掛かったころ、なんと停電の影響によりUPSからの指示でサーバーがシャットダウンを始めてしまいました。
このとき、ワークフローは自動的に「Syspended」という状態に移行します。
つまり、実行中のコマンドレットを、その状態ごとフリーズし保存してくれます。
ワークフロー内部で扱っていた変数や出力結果もそのまま残されています。
復電してドメインコントローラーが起動すると、ワークフローは自分ではレジュームできません。
管理者が再度ドメインコントローラーに接続して Resume-Job コマンドレットによりジョブを再起動してあげる必要があります。
通常、ジョブはサスペンドする直後からの処理を再開するので、ユーザー登録は漏れ無く実行することができます。
もし、UPS管理ソフトがコマンドを発行できるタイプであれば、シャットダウン前にジョブをサスペンドし、次回起動時に自動的にレジュームするようスケジューリングすることもできます。
VBSを使用していた時代は、サーバーが落ちたりクライアントが落ちると、ログを解析して続きのバッチを組みなおさなければなりませんでしたが、PowerShell 3.0 ではワークフローによって不測の事態の復旧が、とても簡単になりました。