インストールしないで検証できる!Windows Server 2012 R2 バーチャルラボ

Windows Server 2012 R2 のあの画面どうだったかな?あの機能ってどこまでできたっけ? そんなことを思いながらも、「インストールめんどくせー」ってことありますよね。 評価版をダウンロードするのも時間かかるし。 そんな方のために、バーチャルラボが公開されています。 ちょっとわかりずらいところにあるので、以下でナビゲートします。 まずは以下のページに移動。   評価版のダウンロード:Windows Server 2012 R2http://technet.microsoft.com/ja-jp/evalcenter/dn205286.aspx 以下のプルダウンから「Windows Server 2012 R2 データセンター バーチャルラボ」を選択して、「今すぐダウンロードする」をクリック プロファイルセンターに移動するので、地域を「日本」に変更して「次へ」 以下のページに移動したら、お好きなラボをクリックしてください。   実を言えば、私も、ちょっとした画面ショットを撮りたいときには愛用していたりします。。。楽なので。。。

0

グループポリシー設定リファレンスガイド 日本語版 提供中

当キャンペーンは終了してしまいましたが、こちらからダウンロードできます! http://technet.microsoft.com/ja-jp/windowsserver/jj649374.aspx すっかり定番となった管理ツール「グループポリシー」ですが、日本語版の全設定項目リファレンスが無いってのがタマに瑕でした。 英語版はリリースされてるんですけどね。。。(参考)http://www.microsoft.com/en-us/download/details.aspx?id=25250 そこで、いま Windows Server 2012 R2 評価版ダウンロードに登録してくださったみなさま全員に、日本語版 グループポリシー設定リファレンスガイドをプレゼント中です。 ※評価版ダウンロードは以下からどうぞ。 http://technet.microsoft.com/ja-jp/windowsserver/jj649374.aspx   ご覧ください。しっかりと日本語化されています!ヘルプも完璧です。 実はこれ、"翻訳したんじゃないんです"。とある PowerShell プロフェッショナルな方にお願いして、スクリプトを作ってもらったんです。詳しくは後日。。。 さらに、評価版ダウンロード登録後にキャンペーンに応募してくださると、以下の書籍も抽選でプレゼント。 期間は1か月と短いのですが、この機会をお見逃しなく~

2

【IDM】Windows Server 2012 R2 の Web Application Proxy ってナニするためのもの? Device Registration Service との関係は?

Active Directory の最新情報をキャッチアップ! クラウド時代の Active Directory 次の一手シリーズ 第1回~6回 公開中! 第 1 回 Active Directory の位置づけ 第 2 回 Active Directory ドメイン サービスの新しい役割 第 3 回 Active Directory フェデレーション サービスの役割 解説編 第 4 回 Active Directory フェデレーション サービスの役割 構築編 第 5 回 認証のためのプロキシ Web Application Proxy 第 6 回 Microsoft Azure Active Directory とは Windows Server…

2

【Management】Windows Server 2012 R2/Windows 8.1 対応 グループポリシーリファレンス リリース

待ちに待ったリファレンスがやっとリリースされました。 Group Policy Settings Reference for Windows and Windows Server http://www.microsoft.com/en-us/download/details.aspx?id=25250 英語版なのですが、新項目は50個程度のようで、半分以上が IE11 関係ですね。 ついでに、Azure上で運営されている、Group Policy Search(こちらも英語版ですが。。)も Windows 8.1/Windows Server 2012 R2 のデータで更新されています。 http://gpsearch.azurewebsites.net/ さて、このリファレンスの日本語版なのですが。。。現時点では予定が見えておりません。 が、頑張って調整してみます。

0

【IDM】Active Directory Federation Service が起動できない場合にはサービスアカウントのパスワードをリセットしてみる

Active Directory の最新情報をキャッチアップ! クラウド時代の Active Directory 次の一手シリーズ 第1回~6回 公開中! 第 1 回 Active Directory の位置づけ 第 2 回 Active Directory ドメイン サービスの新しい役割 第 3 回 Active Directory フェデレーション サービスの役割 解説編 第 4 回 Active Directory フェデレーション サービスの役割 構築編 第 5 回 認証のためのプロキシ Web Application Proxy 第 6 回 Microsoft Azure Active Directory とは たったいまこんなことがありました。 Windows…

0

【IAM】DAC その5 ~ Dynamic Access Control のアーキテクチャ(3) - PAC と Kerberos Pre-authentication(RFC 6113)による拡張

なんだかどんどん深みにはまりつつある ダイナミックアクセス制御の解説シリーズです。。。でもお好きな方にはたまらないですよね(と信じつつ)。 2013 年 7 月以降には、DAC Deep Dive 1日コースのセミナーを開催しようかと考えております。東京以外でも開催したいのので、ぜひご要望をお寄せくださいませ。 さて、前回までの投稿は以下の通りです。 【IAM】ダイナミックアクセス制御(DAC)を理解するための解説&演習手順書 http://blogs.technet.com/b/junichia/archive/2012/12/17/3541225.aspx 【IAM】DAC その 1 ~ グループベース RBAC の破たん? http://blogs.technet.com/b/junichia/archive/2013/03/29/3561744.aspx 【IAM】DAC その 2 ~ なぜ企業のアクセス管理に DAC が必要なのか http://blogs.technet.com/b/junichia/archive/2013/04/01/3562095.aspx 【IAM】DAC その 3 ~ Dynamic Access Control のアーキテクチャ(1) http://blogs.technet.com/b/junichia/archive/2013/05/07/3571125.aspx 【IAM】DAC その 4 ~ Dynamic Access Control のアーキテクチャ(2) ー FSRM が必要な理由 http://blogs.technet.com/b/junichia/archive/2013/05/10/3571884.aspx 前回は「なぜダイナミック アクセス 制御」に「FSRM(File Server Resource Manager」が必要なのか?について解説しました。その中で、DAC…

0

【IAM】DAC その3~Dynamic Access Control のアーキテクチャ(1)

以前の投稿につづき、今回は Windows Servevr 2012 が提供する DAC のアーキテクチャについて解説します。この辺をご理解いただくと、多くのエンジニアの方に「おぉ、やってみたい」と思っていただけるかと。   【IAM】ダイナミックアクセス制御(DAC)を理解するための解説&演習手順書 http://blogs.technet.com/b/junichia/archive/2012/12/17/3541225.aspx 【IAM】 DAC その1 ~ グループベース RBAC の破たん? http://blogs.technet.com/b/junichia/archive/2013/03/29/3561744.aspx 【IAM】 DAC その 2 ~ なぜ企業のアクセス管理に DAC が必要なのか http://blogs.technet.com/b/junichia/archive/2013/04/01/3562095.aspx まずは以前の投稿でも使用した以下の図をご覧ください。DAC では「リソース側の属性」と「ID 側の属性」のマッチングを行い、条件が合致したときにアクセス権が適用されます。 ちょっと運用イメージが想像しずらいでしょうか? 現実の世界にもこのような仕組みは存在しています。例えば"ある種の結婚相談所"を思い浮かべてみてください。 あくまでも私の想像ですが、結婚相談所の場合、女性は出会いたい男性の属性を事前に定義しておく必要があるのでしょう(たぶん)。結構相談所側は、女性の要求と、条件に合致した男性から女性へのコンタクト権限(アクセスルール)を定義しておきます。もちろん、このときアクセスルールにはある程度女性側のニーズを反映させる必要があるので、複数のルールを作成しておく必要があるかもしれません。男性はどういった女性が登録されているかは把握可能ではあるものの、アクセスルールに合致しなければインスタントメッセージさえも送ることは不可能です。 このモデルでは、結婚相談所が両者のニーズの中間地点でアクセス管理を行っています。もし結婚相談所によるアクセス管理が無かったとしたら、一切のアクセス制御は女性自身が行う必要があります。これはとても面倒です。 えっと何の話でしたっけ?あ、DACですね。DAC に話を戻しましょう。 DAC によるアクセス管理の全体像をざくっと図にすると以下の通りです。 ここで3人の主要な登場人物について理解しておきましょう。 ソース アクセスポリシー リソース ソースとは、リソースにアクセスする主体を指します。つまり、ユーザーやデバイスのことです。ソースは Active Directory ドメインに定義されたオブジェクトであり、ldap 属性を持っています。 リソースとはファイルサーバー上の”フォルダ”や”ファイル”のことです。リソースには「分類属性」と呼ばれる特別な属性を定義することができ、これを使用してアクセス可能なソースを制限することができます。 アクセスポリシーとは、その名の通りアクセスを制御するためのポリシーです。正式日本語名称「集約型アクセスポリシー(Central Access Policy)」と呼ばれ、その名称から”集中管理された”アクセスポリシーであることがわかります。「集中管理」が何を意味するかといえば、もちろん「Active Directory ドメイン による集中管理」のことです。 上の図を、さらに詳しく書いたのが以下の図です。…

0

【Deployment】 WDS だけで Windows 8 を仮想マシンに自動展開するとキーボードレイアウトが英語配列(101/102)になってしまう

##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 =…

0

【Management】DHCP フェールオーバーの構成が解除できない場合

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 を忘れずに指定してください。 警告が表示されることがあるのですが、フェールオーバー構成が削除されているはずです。 これで、スコープを削除することもできるようになっているはずです。  

0

【IAM】 DAC その 2 ~ なぜ企業のアクセス管理に DAC が必要なのか

前回の投稿は以下の通りです。 【IAM】 DAC その1 ~ グループベース 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)…

0