Windows PowerShell

[アーティクル]
08/25/2016

Windows Server 2008 R2 以外の OS で Windows PowerSell 2.0 を使用して Active Directory をスクリプトで管理する

Don Jones

IT プロフェッショナルが必要としているソリューションをマイクロソフトが構築するのに、途方もなく時間がかかっているように思えることがあります。というのも、世界中に何万人もの従業員がいるにもかかわらず、まだ Halo 4 がリリースされていないからです。しかし、適切なソリューションを構築するために、開発が遅れている場合もあります。Active Directory のスクリプト対応と自動化については、待っていたかいがありました。Windows Server 2008 R2 には Windows PowerShell 2.0 のモジュールが同梱されているので、Active Directory 関連の処理をスクリプトを使用して自動化できるようになりました。

システム要件に関する事実と通説

新しい Windows PowerShell の Active Directory 関連のコマンドを実行するには、Windows PowerShell 2.0 が必要です。このコマンドは、PSSnapin としてではなく、モジュール形式で配布されています (これは Windows PowerShell 2.0 の新機能です)。モジュールは、インストールや登録の必要がなく、PSSnapin よりも簡単に配布できます。必要な作業は、モジュールのファイルを、シェルの Modules フォルダーにコピーし、Import-Module コマンドを使用してモジュールをシェルに追加するだけです。

Windows PowerShell 2.0 は、Windows 7 と Windows Server 2008 R2 に組み込まれています。2009 年末近くか 2010 年初頭あたりには、Windows Server 2008、Windows Vista、Windows XP、および Windows Server 2003 でも使用できるようになります。Active Directory モジュールは Windows Server 2008 R2 に組み込まれていますが、このコマンドを使用するために、環境内のすべてのドメインコントローラー (DC) で Windows Server 2008 R2 を実行している必要があるというのは、誤った通説です。実際は、無償の Active Directory 管理ゲートウェイサービスが DC にインストールされていれば、Windows Server 2003 を実行している DC と (Windows Server 2008 R2 ではなく) Windows Server 2008 を実行している DC で、コマンドは正常に機能します (このサービスは、microsoft.com/downloads/details.aspx?displaylang=ja&FamilyID=008940c6-0296-4597-be3e-1d24c1cf0dda からダウンロードできます) 。Active Directory コマンドは、このゲートウェイサービスに対して指示を出します。このゲートウェイサービスは、Windows Server 2003 R2 SP2 以降または Windows Server 2008 SP2 以降を実行しているコンピューターにインストールできます。

今のところ、クライアントコンピューターでは Windows 7 か Windows Server 2008 R2 を実行している必要があります。というのも、現時点では、これ以前のバージョンに Active Directory モジュールをインストールすることができないからです。

認証

Active Directory を操作するにあたっていくらか注意が必要なものの 1 つは認証です。自分がログインするドメイン以外のドメインを管理する必要があったり、管理しなければならないすべてのドメイン間で信頼関係が確立されていないことがあります。また、別のドメインの管理者権限を持っていても、その管理者権限を行使するには別のユーザーアカウントを使用しなければならない場合もあります。Windows PowerShell 2.0 では、このようなさまざまな資格情報をすべて保持するためのメカニズムが提供されていません。そのため、Active Directory モジュールの開発チームは、ある技法を考え出す必要がありました。そこで設計された技法は、簡単であるだけでなく、的確でもあります。Active Directory モジュールには、Windows PowerShell の PSDrive プロバイダーが含まれているので、Active Directory ドメインにドライブを割り当てることができます。ドライブの割り当てには資格情報が含まれるので、シェルセッションの間、資格情報を保持することが可能です。モジュールがシェルに読み込まれると、Windows PowerShell 2.0 の実行に使用した資格情報を使用して、ログインドメインが自動的に割り当てられます (注: ユーザーアカウント制御が適用されるので、シェルは必要に応じて管理者として実行するようにします)。新しいドメインを割り当てるには、New-PSDrive コマンドレットを使用します。このコマンドレットでは、資格情報を指定するコマンドラインパラメーターがサポートされています。

ディレクトリを割り当てられたドメインに変更するには、おなじみの Cd コマンドを使用します。たとえば、Cd AD: というコマンドを実行すると、シェルのフォーカスが、既定で割り当てられているドメインに変更されます。既定では、その時点でシェルがフォーカスしているドメインの資格情報が、すべての Active Directory コマンドで使用されるので、ドメインを変更することは重要です。これは、資格情報を毎回手動で指定することなく Active Directory コマンドを実行できる、非常に見事な技法です。別のドメインに対して同じコマンドを実行する必要がある場合は、そのドメインにフォーカスを変更し、↑キーを 2 回押して Active Directory コマンドを呼び戻し、Enter キーを押してコマンドを新しいドメインに対して再度実行します。

ただし、Active Directory コマンドは、必ずしもこのように実行する必要があるというわけではありません。各コマンドでは、状況に応じて資格情報を指定する際に必要となる、コマンドラインパラメーターがサポートされています。自分の好きな方法でコマンドを使用できるので、私はこの柔軟性を非常にありがたく思っています。製品チームでは、どちらか一方の技法だけを採用することもできましたが、両方の技法を含めることにしたのは、Active Directory コマンドのユーザーの幅広さを物語っています。

コマンド

Active Directory モジュールでは、New-ADUser のようなわかりやすいコマンドから、Install-ADServiceAccount のようなもう少し難解なコマンドまで、合計 82 個の新しいコマンドがシェルに追加されます。すべてのコマンドレットには、AD というプレフィックスが付いています。このプレフィックスには、2 つの重要な役割があります。まず、これらのコマンドレットを他の類似コマンドレットと区別するのに役立ちます。たとえば、New-ADUser コマンドレットは、新しいローカルユーザー、新しい SQL Server ユーザーなどのユーザーではなく、新しい AD ユーザーを作成します。次に、このプレフィックスはすべてのコマンドレットを簡単に見つけるのに役立ちます。たとえば、「Help *–AD*」というコマンドを実行すると、82 個すべてのコマンドレットの一覧を取得できます。

それぞれの Active Directory コマンドには、複数のコマンドラインパラメーターが用意されていますが、多数のパラメーターが用意されているコマンドもあります。たとえば、New-ADUser コマンドレットには、膨大な数のパラメーターが用意されているので、内部スキーマの属性名を覚えることなく、Office や Organization などのディレクトリ属性を設定することが可能です (スキーマで姓が sn と表されることなど私にはとうてい覚えられません)。

この Active Directory コマンドのすばらしい点は、誤った操作を実行できないようにするところです。たとえば、Get-ADUser コマンドレットを実行する際には、ディレクトリ内のすべてのユーザーが一覧表示されることを期待するかもしれません。大規模なドメインでは、この操作を実行するのに時間がかかるだけでなく、DC に著しい影響を及ぼすこともあります。このような状況を回避するには、コマンドの –filter パラメーターを使用して、開始点 (組織単位など) やその他の条件を指定する必要があります。もちろん、コマンドでは実行する必要がある処理を妨害することはありません。「–filter *」というコマンドを実行すると、実際に、ディレクトリ内のすべてのユーザーを取得できます。ただし、ドメインユーザーのすべての属性を自動的に取得することはありません。というのも、この場合も、この処理が DC に少し悪影響を及ぼすことがあるからです。一度に取得する結果の件数を指定する –ResultPageSize や、取得する属性の種類を指定する –Properties などの追加のパラメーターは、パフォーマンスと取得する必要がある情報のバランスを微調整するのに役立ちます。

非常に便利な技法

20 数行もの VBScript コードを使用して Active Directory に新しいユーザーを作成して設定していたころが懐かしく思い出されます (実際にはそれほど昔のことではありませんが)。現在は、次のように単純なコマンドで同じ操作を実行できます。

PS AD:\> new-aduser -name DonJ -CannotChangePassword $True -Department IT -DisplayName 'Don Jones' -EmployeeNumber 42 -GivenName Don -Office 'Las Vegas' -Organization 'Concentrated Technology' -PasswordneverExpires $True

あるすばらしい技法を使用すると、新しいユーザーを作成してから、そのユーザーオブジェクトに対して追加の処理を実行できます。–passThru スイッチをコマンドに追加すると、新しく作成したユーザーオブジェクトがパイプラインに出力され、そのユーザーオブジェクトを別のコマンドレットで入力として受け取ることができます。たとえば、次のような処理を実行できます。

New-ADUser ... -passThru | Set-ADAccountPassword ... -passThru | Enable-ADAccount

... の部分には標準的なパラメーターが入るので、ここでは省略しました。このコードは、–passThru スイッチを使用して、引き続きユーザーオブジェクトをパイプラインに出力し、他のコマンドレットがユーザーオブジェクトに対してなんらかの処理を実行できるようにする方法を例示することを目的としています。このような技法を使用すると、非常に効率的な 1 行のコード (スクリプトではなく 1 つのコマンドライン) を実現できるので、はるかに効率的に作業を行うことができます。

いっそう優れた技法

私がオフィスで Active Directory コマンドの開発チームにとってのちょっとした聖地を開拓したことを紹介しましょう。そこで私が "パイプラインへのパラメーターのバインド" と呼ばれる小さな奇跡を発見したので、開発チームはこれを使用して最大限の効果を得ることになりました。「Help New-ADUser –full」というコマンドを実行して、各パラメーターのヘルプを見てみてください。Active Directory 属性に対応している、City、Office、Department などの各パラメーターの多くが、ByPropertyName パイプライン入力を受け付けていることがわかります。つまり、入力は New-ADUser コマンドレットにパイプすることが可能で、入力にパラメーター名と一致するプロパティが含まれている場合は、プロパティが自動的に照合されます。入力に City プロパティが含まれている場合、このプロパティは –City パラメーターにアタッチされ、入力に Department プロパティが含まれている場合、このプロパティは –Department パラメーターにアタッチされます。

Import-CSV コマンドレットのしくみを知っている方は、既に興奮し始めていることでしょう。次のような列で構成された .CSV ファイルを想像してみてください。

"Name","Department","Organization","City"

ファイルの各行には、これらの列の情報が含まれています。Microsoft Office Excel、Microsoft Office Access、Microsoft SQL Server などを使用して、この構造を作成してから、データを CSV 形式のファイルにエクスポートすることもできます。このファイルを作成すると、次のようなコマンドを実行して新しいユーザーを作成できます (列名と New-ADUser のパラメーター名が一致するように注意する必要があります)。

Import-CSV c:\new-users.csv | New-ADUser

入力する必要があるのはこれだけです。.CSV ファイルに必要なすべての列が含まれていれば (たとえば、–Name パラメーターが必須である場合に、Name 列が含まれていれば) は、New-ADUser コマンドレットによって、.CSV の正しい列と適切なパラメーターが魔法のようにリンクされます。50 文字未満の短いコマンドを入力して、100 人もの新しいユーザーを数秒でインポートすることができます。この時点でも、Windows PowerShell 2.0 が学習する価値のあるツールであることを心の底から認められない方は、[次へ] ボタンを何度かクリックして最後に [完了] をクリックする作業が本当に好きなのでしょう。

AD を適切に管理する

Windows PowerShell の基本原則の 1 つは、プログラマがシェルコマンドレットですべての管理機能 (Active Directory の管理など) を記述する必要があることです。基本的に、GUI はコマンドレットのフロントエンドになります。Microsoft Exchange Server 2007 では、このパターンが導入され、成功を収めました。この製品には、優れた GUI が用意されていますが、必要な操作を GUI で実行できない場合に常にコマンドラインを使用して操作を実行することができます。では、Active Directory ユーザーとコンピューターも、このように修正されたのでしょうか。

このユーティリティは修正されていませんが、正直なところ、これは非常に成熟したツールです。ですが、Windows Server 2008 R2 には、もう 1 つの革新的な機能として Active Directory 管理センターが導入されています。これは、Active Directory を管理するためのまったく新しい GUI です。この管理センターの基盤となっているのが、Active Directory コマンドレットです。つまり、この GUI で実行するあらゆる操作は、シェルから実行できます。そのため、繰り返し操作や単調な操作は、シェルスクリプトに任せることができます。

誕生から約 10 年たって、ようやく本当に必要な機能を備えた Active Directory が提供されるようになりました。GUI を使用してわかりやすく直感的な管理を行うか、すべての機能を備えたコマンドラインを使用して、より強力で自動化された管理を行うかを選択できるようになりました (率直に言うと、コマンドラインから管理しても、難易度は GUI を使用する場合とたいして変わりません)。適切なアドオンを使用すれば、Windows Server 2003 ドメインも同じように管理できるので、Windows Server 2008 R2 が展開されるまで待つ必要はありません。

Don Jones は、米国内で最も熟練した Windows PowerShell の指導者およびスクリプト作成者の 1 人です。ConcentratedTech.com (英語) でブログを公開しており、Windows PowerShell に関するヒントを毎週紹介しています。このブログでは、Don に連絡したり質問を投稿したりすることもできます。