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 でタスクシーケンスを使用すれば、インストール完了後に実行できるかも

やっていることは単純です。

仮想マシンへのインストールが完了したことを見計らって（ここを動判定するかは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 を指定しました。 

1. Specifies the PC/AT Enhanced keyboard (101/102-key).
2. Specifies the Korean PC/AT 101-Key Compatible keyboard or the Microsoft® Natural keyboard (type 1).
3. Specifies the Korean PC/AT 101-Key Compatible keyboard or the Microsoft Natural keyboard (type 2).
4. Specifies the Korean PC/AT 101-Key Compatible keyboard or the Microsoft Natural keyboard (type 3).
5. Specifies the Korean keyboard (103/106-key).
6. Specifies the Japanese keyboard (106/109-key).

最後に、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 とか）指定するわけではないということです。あくまでも対象となるリソースの「条件」を定義するのだという点に注意してください。

条件には、所属以外にも、担当プロジェクトや役職などが考えられますし、単純なところではデータの重要性（外部公開、社外秘、社員のみ など）を定義する必要もあるでしょう。また、より厳密に管理するのであれば「データがどういったコンプライアンスフレームワークに属するか」といった定義も必要になるでしょう。例えば以下のようなフレームワークが考えられます（日本にとっては重要でないものもあったりなかったりですが。。。）。

• CObIT
  http://ja.wikipedia.org/wiki/COBIT
• EU Data Protection Directive（EU データ保護指令）
  http://www.caa.go.jp/seikatsu/kojin/H21report1a.pdf
• FACTA（外国口座税務コンプライアンス法）
  http://www.nri.co.jp/opinion/kinyu_itf/2011/pdf/itf_201108_6.pdf
• FERC/NERC CIP
• FISMA(Federal Information Security Management Act of 2002)
  http://www.ipa.go.jp/security/publications/nist/fisma.html
• GAPP
• GLBA
• HIPAA/HITECH（Health Insurance Portability and Accountability Act/Health Information Technology for Economic and Clinical Health Act）
  http://www.mhlw.go.jp/shingi/2010/06/dl/s0616-4g.pdf
• HITECH CSF
• ISO 27002
  http://ja.wikipedia.org/wiki/ISO/IEC_27002
• ITAR
• Japan Personal Information Protection Act（個人情報の保護に関する法律）
  http://ja.wikipedia.org/wiki/%E5%80%8B%E4%BA%BA%E6%83%85%E5%A0%B1%E3%81%AE%E4%BF%9D%E8%AD%B7%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E6%B3%95%E5%BE%8B
• NIST SP 800-53
  http://www.ipa.go.jp/security/publications/nist/
• PCI DSS（PCIデータセキュリティスタンダード）
  http://ja.wikipedia.org/wiki/PCI%E3%83%87%E3%83%BC%E3%82%BF%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E3%82%B9%E3%82%BF%E3%83%B3%E3%83%80%E3%83%BC%E3%83%89
• PIPEDA（Personal Information Protection and Electronic Documents Act ）
  http://www.soumu.go.jp/denshijiti/pdf/jyumin_p_s1.pdf
• SOX（上場企業会計改革および投資家保護法）
  http://ja.wikipedia.org/wiki/%E4%B8%8A%E5%A0%B4%E4%BC%81%E6%A5%AD%E4%BC%9A%E8%A8%88%E6%94%B9%E9%9D%A9%E3%81%8A%E3%82%88%E3%81%B3%E6%8A%95%E8%B3%87%E5%AE%B6%E4%BF%9D%E8%AD%B7%E6%B3%95
• US-EU Safe Harbor
  http://export.gov/safeharbor/

2. 策定したセキュリティポリシーをリソース管理者に通達する

リソースにどのような属性が用意され、それがどのように設定されていると、どのような属性を持ったユーザーに、どのようなアクセス権が与えられるのかという内容を通達します。通達されたポリシーをどのリソースに適用するかはリソース管理者の裁量となりますが、少なくともリソース管理者は公開するデータがどのような種類のデータであるかを把握しておく必要があります。社外秘なのか部門限定情報なのかなどです。逆に、それが判断できない人はリソース管理者であってはなりません。。。。つまりリソース管理者にもそれなりのリテラシーが要求されるわけです。

。。。と書くとかなり敷居が高いように思えますが、リソース管理者自身が「社外秘情報の判別と、そのアクセス権まで管理していた」ACLベースのアクセス管理手法と比較すれば、はるかに容易ですし、安全性は高まります。

3. 策定したセキュリティポリシーを ID 管理者に通達する

アクセスルールはユーザーの属性をベースに判定されるので、ID 管理者には常に最新の ID 情報を保持してもらう必要があります。重要なデータであればあるほど迅速性が求められるため、それなりの ID管理基盤（ユーザープロビジョニングシステム等）が必要となる場合もあるでしょう。もしかするとアクセスポリシーを適用するために最適な属性が存在せず、Active Directory のスキーマに手を入れざるをえない可能性もあります。

ただし、あまりに複雑なルールは運用に破たんを招きますので、極力既存のID管理手法を維持しつつ、アクセスルール側で複雑な設定は吸収したほうがよいでしょう。

各種法令は無駄に複雑なプロセスを求めるものではありません。

基本は、中央のセキュリティポリシーがリソースに対して強制力もち、参照や編集できる権限を持った人が限定的でありかつ明確であること。そしてそれがトラッキング（監査）できることです。権限を持たない人間が絶対にアクセスできないようになっていることが重要です。

4. セキュリティポリシーをシステムに反映する

システムに反映するには DAC のお作法にのっとって作業する必要があります。これについては次回詳しく解説しますが、「セキュリティポリシーの集中管理」と聞けば何を使うかはだいたいわかりますよね？そう、グループポリシーです。作成したアクセスルールをグループポリシーにのせて、社内のリソースに配信するわけです。

このように、DAC は ACL ベースのアクセス管理では行えなかった「ID 管理」「リソース管理」「全社アクセスルールの管理」の 3 者を分離し、それぞれの専門部隊の相互連携によって最大限の効果を発揮できるようにするための仕組みです。

DAC にはアクセス権を管理する以外にも、監査ルールを集中管理したり、FCI（File Classification Infrastructure）との連携による自動分類が可能です。FCI と連携することで、社外秘データを暗号化したり、法廷保存期間に沿って特定フォルダに保管したりといった作業を自動化することもできます。これらについて詳しくは別投稿で。

＜その１     その３＞