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 して再起動すると、今作成したエントリから無事起動することができました。
冷や汗かきました。
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 がなぜ企業のアクセスコントロールにおいて重要であるのか。。について解説します。
その２ へ
※この投稿は、あくまでも現在公開されているドキュメントや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. あらためて、サインインのための電話がかかってくるので正しく応答すればサインイン完了です。
万が一、電話がかかってこなかったりショートメッセージが送られてこない場合には、「その他の検証オプション」をクリックして別の電話を選択したり、応答の方法を変更してみてください。
なお、プレビューなのでいつトラブルかわかりません。本番環境では全員に設定するなんてことはせず、かならずテストアカウントで検証を行いましょう。
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 です。
便利になるのはいいんですけどねぇ。トラブルと面倒なんですよね。。。