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 2012 R2 に新しく実装された機能の1つに Web Application Proxy があります。

非常に地味～な名称のため、正直なところあまり目立たないのですけどね。

Web Application Proxy とは何かといえば、ぶっちゃけ、リバースプロキシーです。

リバースプロキシーなんて古くからあるテクノロジーですから、中には「何を今さら !?」と思われる方もいらっしゃるかもしれません。マイクロソフトもその昔 MS PROXY という製品を販売していましたし、その後継製品として現在は超高機能な Forefront UAG（Unified Access Gateway）を持っています。

なのに、なぜ今さら Web Application Proxy なのかといえば、これがマイクロソフトの「デバイス＆サービス戦略」においてとても重要な位置を占めているからです。

Windows Server 2012 R2 に実装されている Web Application Proxy の最大の特徴とは何かといえば、

AD FS による事前認可機能

これにつきます。

さまざまなリバースプロキシー製品が Active Directory ドメインサービスに「認証依頼」を飛ばすことができますが、Web Application Proxy は AD FS に「認可依頼」を飛ばすことができます。

Web Applicaiton Proxy と AD FS の連携による認可処理は、社内へのアクセスに先立って行われるため「事前認可」と呼んでいます。

この機能により、ユーザーがインターネットから社内リソースアクセスする前に、「ユーザー認証」するだけでなく AD FS から発行されたクレームを使用して「認可」することができるのです。

ここでちょっとだけ整理しておきましょう。

• ユーザー認証でできること

• ユーザーIDとパスワードの正当性チェック
• ユーザーが所属しているセキュリティグループの正当性チェック

• ユーザー認可でできること

• ユーザーのさまざまな属性によるアクセス可否判定

「認可」では、ユーザーが持っている属性を使ってアクセス可否を判定することができるため、きめの細かな制御が可能です。

ユーザー属性は通常 Active Directory に格納されていますが、AD FS は標準で SQL Server に格納された情報を検索できるため、例えば人事データベースが SQL Server で構築されていれば、それらの情報も判定基準として利用できるということです。

アクセス制御のための複雑なビジネスロジックを大量のセキュリティグループによって実現することは、とても大変ですし面倒です。

しかし、ユーザー属性をアクセス制御の判定基準に利用できれば、今まで以上に要望実現への距離を短縮することができます。

「え？それだけ？なんかピンとこないな。」

そう思われた方も多いでしょう。

当然、話はこれだけでは終わりません。

Windows Server 2012 R2 には新たに「DRS：Device Registration Service（デバイス登録サービス）」という機能が実装されました。

これはその名の通り、ユーザーのデバイス（PCやタブレット）を Active Directory に登録するためのサービスです。

これはドメイン参加とは違いますので気を付けてください。

ドメインに参加した PC は、AD ドメインによる「デバイス認証」がサポートされることに加え、「ドメインのポリシーを強制適用」したり「管理者がリモートから管理」することができます。

しかし、DRS によってドメインに登録されたデバイスは、ADドメインによって「デバイス認証」のみが行われます。

デバイスを登録したからといって、ドメインのポリシーが適用されたり、管理者がリモートから入り込むということはできません。

では、なんのためのデバイス登録なのか。。。

実は、DRS は AD FS と連携して動作しています。

ということは、デバイスが AD ドメインで認証の結果、デバイスのクレーム（デバイスの属性）が発行されます。

ちなみに、デバイスを登録する処理のことを、Windows 8.1 では Workplace Join と呼んでいます。

「デバイスのクレームが発行される」と聞いて、先の Web Application Proxy の AD FS 連携と結び付けられた方はすばらしいです。

デバイスクレームが発行されるということは、Web Application Proxy を通過する際に ユーザーに対する認可に加えてデバイスに対する認可も行えるということです。

つまり、ユーザーが正しく認可されても、デバイスが認可されなければ社内にアクセスすることができません。

従来、これと同じことを行うためには、サードパーティ製品を導入する必要がありました。

しかも、個人デバイスは Active Directory に登録されていないため、別途管理DBを用意してメンテナンスしなければなりませんでした。

でも、今後新しく構築する際にはその必要はありません。

Workpalce Join を使用すれば、ユーザーは自分自身で社内 AD にデバイス登録が行えます。

しかも、何か特別なアプリケーションやドライバーをインストールする必要はなく、OS 標準機能で行えてしまうのです。

必要な証明書は、Workplace Join したときに自動的にインストールされます。

もちろん、誰でも彼でもデバイス登録ができてしまうことは危険ですので、DRS に登録要求ができるユーザーやユーザーグループを制限することもできます。

その辺のアクセス制御は AD FS を使用してきめ細かに行えます。

いかがでしょう？

ちょっと評価してみたくなりましたよね？

ただ、構築のために求められるスキルは、かなり難易度が高いです。

なので、手順書を用意しました。

手順書を入手していただくには、まずは Windows Server 2012 R2 評価版ダウンロードを行ってください。

http://technet.microsoft.com/ja-jp/evalcenter/dn205286.aspx

評価版ダウンロードを開始してからすこしすると、「ダウンロードありがとう」的なメールが送られてきます。

※すでに評価版をお持ちの方はダウンロードを途中で止めてしまっても大丈夫です

そのメールの中に、手順書へのリンクが書かれています。

ぜひ Windows Server 2012 R2 評価版を使用して、手順を実施してみてください。

感動していただけるはずです。

一歩先の Active Directory の使い方によっていただければ幸いです。

多くの方が Windows PowerShell をお使いのことと思います。

PowerShell にはさまざまな「奥義」が存在しますが、「バックグラウンドジョブ」も奥義の一つです。これは究極奥義である「ワークフロージョブ」へとつながる大切な概念です。

まずは以下をご覧ください。

Get-Service  -ComputerName  Server01

何をやっているかは一目瞭然ですよね。

リモートコンピューター Server01 上のサービス一覧を取得しています。

通常 Get-Service は直ぐに結果を得られるので問題ないのですが、結果取得までに10分とか20分を要する場合にはコンソールを占有されてしまうことを回避するため、「バックグラウンドジョブ」と呼ばれる方法を使用します。

つまり、コマンドを投げっぱなしにしておいて（非同期実行）、あとから結果を取りに行く...という方法です。

バックグラウンドジョブを作成するには2つの方法があります。

• -AsJob パラメタを使用する
• Start-Job コマンドレットを使用する

いずれを使用しても得られる結果は同じですが、コマンドレットによっては -AsJob をサポートしていない場合もあり、その場合には Start-Job の引数にコマンドレットを指定します。

例えば、Get-Service の場合には -AsJob パラメタをサポートしていないため、バックグラウンドジョブ化するには以下のように書きます。

Start-Job -ScriptBlock { Get-Service -ComputerName  Server01 }

さて、ここまでは一般ピープルでも知っていることです。

エキスパートな方はここからが重要なのです。

さっそくですが、以下の2つの違いわかりますか？いずれも上の記述を書き換えたもので、同じ結果が得られます。

$S = New-PSSession  -ComputerName  Server01
Invoke-Command  -Session $S  -ScriptBlock { Get-Service }  -AsJob

$S = New-PSSession  -ComputerName Server01
Invoke-Command  -Session $S  -ScriptBlock {Start-Job  -ScriptBlock { Get-Service } } 

1 行目の 「$S = New-PSSession  -ComputerName  Server01 」はおわかりですよね。リモートコンピューター Server01 と PS セッションを張ってます。図にすると以下のような感じです。

問題は2行目です。同じことをやってそうなのですが、微妙に書き方が異なっています。-AsJob と Start-Job に何か秘密が隠れているようではあります。

Invoke-Command を使用すると、リモートコンピューター上でコマンドレットを実行することができます。今回の例では、事前に作成した Server01 とのセッションを使い、Server01 上で Get-Service を実行しています。

-AsJob を指定することで Invoke-Command 自体がバックグラウンドジョブ化され、リモートでのコマンド実行を待ち合せることなく、バックグラウンドで非同期に実行することができます。

結果は Invoke-Command を実行したローカルホストに保存されます（ここ重要！）。

図にすると以下のような感じです。

一方、-AsJob ではなく、ScriptBlock 内で Start-Job を実行した場合はどうなるでしょう。

Start-Job は Server01 上で実行されるため、バックグラウンドジョブ化されるのは Server01 上の Get-Service コマンドです。

では、結果はどこに保存されるかといえば、ジョブが実行された Server01 上です。

図にすると以下のようになります。

当然、結果を取りに行くときは、以下のように Server01 に対して Receive-Job する必要があります。

Invoke-Command -Session $S -ScriptBlock { Receive-Job <jobid> }

両者の違いを正しく理解しておくことはとても重要です。

例えば、「長く時間を要するバックグラウンドジョブを実行して、あとで結果を受け取ろう」と考えたとしましょう。

もし Invoke-Command -AsJob を使用してローカルコンピューター上に結果を保存するようにした場合、ローカルコンピューターはジョブが終わるまでネットワークから切り離すこともシャットダウンすることもできません。ネットワークから切り離されたり、シャットダウンした瞬間にジョブは消滅します。

しかし、後者（ Invoke-Command {Start-Job }）で実行すれば、ジョブはリモートで実行され、結果もリモートに保存されます。

ジョブを投げたあとはDisconnect-PSSession でセッションをいったん切断し、あとから Connect-PSSession でもとのセッションに再接続することができます。

（参考）

【Management】PowerShell V3.0 で向上したリモーティング機能 その1
http://blogs.technet.com/b/junichia/archive/2012/03/24/3488392.aspx

【Management】PowerShell V3.0 で向上したリモーティング機能 その2
http://blogs.technet.com/b/junichia/archive/2012/03/26/3488520.aspx

「ジョブの実行場所が、結果の保存場所である」

.....ということをくれぐれも忘れないでください。

Linux/UNIX 系の方にはおなじみの Tail コマンドですが、これと同じことを Windows でできないものかとよく尋ねられます。

MVP のあおきさんが書かれているように、CodePlex で LogExpert というツールが公開されていますので、すでにこちらをお使いの方も多いことでしょう。

http://d.hatena.ne.jp/aoki1210/20120218/p1

※この記事の存在は石坂さんから教えていただきました。石坂さん、ありがとうございます！そしてあおきさん、ありがとうございます！

では、本当に Windows 標準ではできないのかといえば、実はそんなことはありません。

Windows PowerShell に用意されている Get-Content コマンドレットを使用すれば同じような処理が可能です。

例えば以下のように書きます。

Get-Content   .\FinaName.log  -wait  -tail  0

-wait は新しい行が追加されるまで待ち合せることを意味しています。

注意していただきたいのは、その後の -tail です。このパラメタは Windows PowerShell 3.0 からサポートされたものです。

以前は  Get-Content   .\FinaName.log  -wait などとやると、テキストファイルをいったん全部読み込んでから -wait 処理が始まるため、巨大なファイルを扱う場合には待ち時間が異常に長いという問題がありました。

しかし、-tail パラメタのサポートにより、「最後の○行だけ読み込む」という指定ができるようになったのです。もちろん、 -tail  0  は「0行読み込む」という意味なので、何も読み込まずにいきなり -wait 処理が始まります。

試しに、何か巨大なテキストファイルを用意してみてください。

手元にない方は、郵便局が用意している郵便番号データ（CSV ファイル）なんかがよいかもしれません。

http://www.post.japanpost.jp/zipcode/dl/oogaki.html

巨大な csv ファイルを用意したら Windows PowerShell のコンソール上で以下のコマンドを実行してみましょう（郵便番号データを使用しています）。

Get-Content .\KEN_ALL.CSV -wait

上記の通り、すべてのデータを読み込んだ後で wait がはじまります。私のマシンで実行すると、wait が始まるまで実に2分半！これじゃやってられません。

そこで、次に以下のように指定してみてください。-tail 0 がミソです。

Get-Content .\KEN_ALL.CSV -wait -tail 0

言わずもがなですが、いきなり wait してくれます。

Get-Content には、他にもいろいろな使い方がありますので、ぜひ末永くご愛顧ください。便利ですよ！

さて、ここでこんな要望も出てくるはず。

「Get-Content なんて長くて打ってられん！ tail と入力したいのだ！」

はい、もっともです。以下のコマンドを実行してみてください。

Set-Alias  tail  Get-Content

これで、Get-Content に tail というエイリアスが設定されました。今後は tail と入力すれば Get-Content と同じように使用できます。

が、ここで難点も。。。Set-Alias コマンドは現在のコンソール上でのみ有効なのです。つまり、一度コンソールを閉じると Set-Alias した内容が消えてしまいます。

そこで、PowerShell セッションが起動するたびに、上記コマンドが実行されるようにしましょう。

Windows PowerShell にはユーザーごとにプロファイルが用意されており、ここにコマンドを記述しておくとコンソールが開くたびに実行してくれます。

ログオンスクリプトみたいなものです。

試しに、以下のコマンドを実行してプロファイルをメモ帳で開いてみてください。

notepad $profile

おそらく、「ファイルが存在しません。新規に作成しますか？」と表示されるはずです。

もし以前作成したプロファイルが存在していたとしても、特に気にせず、以下のようにコマンドを実行してください。

Add-Content  $profile  "Set-Alias tail get-content"  -Force

これにより、$profile が存在しない場合には新規に作成して “Set-Alias tail Get-Content” を追記してくれます。

すでに $Profile が存在する場合には、ファイルの最後の行に “Set-Alias tail Get-Content” を追記してくれます。

これで、次回からは PowerShell コンソールを起動した直後から tail コマンドが使用できます。

なお、通常の PowerShell コンソールと、PowerShell ISE とではプロファイルのパスが異なります。

• PowerShell コンソールの場合 C:\Users\junichia\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
• PowerShell ISE の場合      C:\Users\junichia\Documents\WindowsPowerShell\Microsoft.PowerShellISE_profile.ps1

そのため、ISE側だけで設定してもコンソール側には反映されませんので注意してください。

ISE とコンソールの両方で Alias 登録を行ってください。

待ちに待ったリファレンスがやっとリリースされました。

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/

さて、このリファレンスの日本語版なのですが。。。現時点では予定が見えておりません。

が、頑張って調整してみます。