人気ブログランキング |
タグ:ActiveDirectory ( 40 ) タグの人気記事
Hyper-V上でドメインコントローラ作るときは時刻同期に注意!
複数ドメインコントローラが有る環境で、PDCエミュレータ機能を有するドメインコントローラにこの設定をしたんですが、他のドメインコントローラがPDCドメコンのNTPに同期してくれません。(PDCエミュレータのドメインコントローラは、ドメインコントローラを外部のNTPサーバと時刻同期で外部NTPサーバに同期するよう設定し、正常に動いています。)

ちなみにPDCエミュレータのドメインコントローラは実サーバ、その他のドメインコントローラは Hyper-V の仮想マシンとして構築しています。

PDCエミュレータに時刻同期できないFSMO以外のドメインコントローラのイベントビューアをみると、下記のエラーと警告が延々とでてます。

タイム プロバイダ NtpClient は到達できないか、現在 pdcDC.hogedomain.local (ntp.d|192.168.0.111:123->192.168.0.100:123) から有効な時間データを受信中です
 ↓
タイム プロバイダ NtpClient: ドメイン コントローラ pdcDC.hogedomain.local へのアクセスを 8 回試行し ましたが、有効な応答が得られませんでした。このドメイン コントローラは、タイム ソースとしては破棄され、NtpClient は同期先となる新しいドメイン コントローラの 発見を開始します。
 ↓
1 つまたは複数のタイム ソースから時間を取得するようにタイム プロバイダ NtpClient は 構成されていますが、どのソースも現在アクセスすることはできません。 ソースへのアクセスの試行は、あと 15 分間実行されません。NtpClient が正しい時間を 参照できるソースがありません。


いろいろ調べたところ、ゲストOSのWindowsServer2003でw32timeエラーが多発に原因と解決策が載ってました。

それは Hyper-V の仮想インスタンス毎の設定にある、統合サービスの「時刻の同期」が有効になっていたためでした。
確かにこれを有効にしてると、ゲストOSはホストOSの時刻に合わせようとします。しかし、ドメインのメンバサーバたるホストOSは近いところにある(つまり今回の環境ではHyper-V上の)ドメインコントローラに時刻を合わせようとします。

これにより、時刻同期がうまくできなかったわけですね。

この統合サービスの時刻の同期チェックを外すと問題なくPDCに同期できるようになりました。


まぁ注意深く考えたらすぐに原因がひらめきそうなもんですが、結局原因わかるまで1日かかっちゃいました。
最近ボケ気味の3流PGです。
by jehoshaphat | 2010-09-24 01:52 | 豆知識
(WindowsServer2003)PDCマスタのドメインコントローラを確認する方法
ドメインコントローラを外部のNTPサーバと時刻同期でドメインコントローラの時刻同期設定を書きましたが、複数ドメインコントローラがある場合はどのDCに対して時刻同期の設定をすればいいのだろうという話です。

複数DCが有る場合はPDCエミュレータ(PDCマスタ)のドメインコントローラに対して設定を行う必要があるようです。
(PDCエミュレータはNTドメイン時代のプライマリドメインコントローラをエミュレートするサーバ)

さて、このPDCエミュレータですが FSMO (操作マスタ) という特定の一台のDCだけが担当する役割に含まれるようです。
(余談ですが、FSMOにはPDCエミュレータのほかに、スキーマ・マスタ、ドメイン名前付けマスタ、RIDマスタ、インフラストラクチャ・マスタの機能が含まれます。。また通常は最初に導入したドメインコントローラがFSMOとなります)

本題のPDCマスタであるドメインコントローラを確認する方法ですが一番楽だと思ったのは netdom.exe を使う方法です。
(ただしサポートツールが入ってないと使えません。サポートツールはWindows 2000,XP,2003のインストールメディアに含まれるほかに、WEBからダウンローできます。参照:netdomコマンド - 管理者必見! ネットワーク・コマンド集:ITpro)

下記のように netdom コマンドを打つとFSMOの各機能がどのドメインコントローラが担っているかがわかります。

C:\>netdom.exe query fsmo
Schema owner hogedc01.hogedomain.local
Domain role owner hogedc01.hogedomain.local
PDC role hogedc01.hogedomain.local
RID pool manager hogedc01.hogedomain.local
Infrastructure owner hogedc01.hogedomain.local
The command completed successfully.

hogedc01 がPDCマスタを担っているので、hogedc01に時刻同期の設定をすればいいということが分かります。

後は、ntdsutil.exe コマンドを使う方法も有りますが、ちょっと入力が多いので面倒です。

C:\>ntdsutil
ntdsutil: roles←入力
fsmo maintenance: connections←入力(サーバに接続)
server connections: connect to domain hodgedomain.local←(接続先ドメイン入力)
\\hogedc02.hodgedomain.local に結合しています...
ローカルでログオンしているユーザーの資格情報を使って \\hogedc02.hodgedomain.local に接続しました。
server connections: quit←入力
fsmo maintenance: select operation target←入力
select operation target: list roles for connected server←入力
サーバー "\\hogedc02.hodgedomain.local" は 5 個の役割を認識しています
スキーマ - CN=NTDS Settings,CN=HOGEDC01,CN=Servers,CN=hodgedomain,CN=Sites,CN=Configuration,DC=hodgedomain,DC=local
ドメイン - CN=NTDS Settings,CN=HOGEDC01,CN=Servers,CN=hodgedomain,CN=Sites,CN=Configuration,DC=hodgedomain,DC=local
PDC - CN=NTDS Settings,CN=HOGEDC01,CN=Servers,CN=hodgedomain,CN=Sites,CN=Configuration,DC=hodgedomain,DC=local
RID - CN=NTDS Settings,CN=HOGEDC01,CN=Servers,CN=hodgedomain,CN=Sites,CN=Configuration,DC=hodgedomain,DC=local
インフラストラクチャ - CN=NTDS Settings,CN=HOGEDC01,CN=Servers,CN=hodgedomain,CN=Sites,CN=Configuration,DC=hodgedomain,DC=local
select operation target: quit←入力
fsmo maintenance: quit←入力
ntdsutil: quit←入力
\\hogedc02.hodgedomain.local から切断しています...


参考:
@IT:Active DirectoryのFSMO役割を担当するサーバを調査する(コマンド・プロンプト編)
ntdsutilコマンドでの操作マスタ(FSMO)の確認
TechNet:操作マスタの役割
by jehoshaphat | 2010-09-18 22:19 | サーバがらみ
(ActiveDirectory)GPTの同期の方法は?
複数のドメインコントローラが有って、グループポリシーやActiveDirectoryのテストを行いたいときは手動で情報を複製したい時があります。

ActiveDirectoryデータベースのドメインコントローラ間の複製はMMCの「ActiveDirectoryサイトサービス」から Sites → ドメイン名 → Servers → DC名 → NTDS Settings で右ペインに表示されたオブジェクトを右クリック→「今すぐレプリケート」からできることは以前どこかで聞いたので知ってました。

ITPro:【解説】グループ・ポリシーの変更をすぐにクライアントへ反映させるには?によると、グループポリシーの設定はActive Directoryと結びついた情報である「グループ・ポリシー・コンテナ(GPC)」と、「グループ・ポリシー・テンプレート(GPT)」との二つに分かれてるようです。

GPTの方はSYSVOL共有フォルダにファイルとして保存されるようです。

おそらくGPCの方は、「ActiveDirectoryサイトサービス」でレプリケートしたときにドメインコントローラ間で同期されてるんでしょうが、GPTが入っているSYSVOL共有フォルダの方が、どうすれば同期できるのかがわかりません。

今回ログインスクリプトを下記のSYSVOL共有フォルダに保存しました。
\\domainname.local\SysVol\domainname.local\Policies\{xxxxx-xxxx-xxxx-xxxx-xxxxxx}\User\Scripts\Logon

この時、ドメインコントローラ1台目はログインスクリプトを差し替えると更新されたんですが、ドメインコントローラ2台目が更新されません。
しばらく放置してると更新されてました。

いろいろ調べたんですが、結局わからずしまいだったんで、直に2台のドメインコントローラにログインスクリプトファイルを差し替えることとしました。
SYSVOL共有フォルダは \\ドメインコントローラ名\SYSVOL\ でもアクセスできるようです。

SYSVOLの手動同期の方法なんか無いでしょうか?
by jehoshaphat | 2010-09-12 23:22 | サーバがらみ
(ActiveDirectory)グループポリシーのセキュリティフィルタとWMIフィルタ
フォルダリダイレクトと移動ユーザープロファイルで、フォルダリダイレクトについて特定のサーバ利用時だけリダイレクトを行いたいという要件があり、これをグループポリシーのセキュリティフィルタで実装しようとしましたが、ダメでした。

具体的にGPMC(グループポリシーの管理)でスコープタブからもセキュリティフィルタ処理をかけれるんですが、より詳細に設定したいときは フォルダリダイレクトを設定したグループポリシー → 編集 → ツリールートのプロパティ → セキュリティタブからできるようです。

ここで、Authenticated Users をリストから除け、リダイレクトをしたいサーバ(コンピュータ)に「グループポリシーの適用」を許可とし、その他のコンピュータを拒否にしました。
(Authenticated Users をのけたのは、TechNet:GPMC を使用してセキュリティ フィルタ処理を行うに「Authenticated Users グループには、ユーザーとコンピュータの両方が含まれます。」とあったからです。このグループにコンピュータが含まれるのは知りませんでした。)

こうすると、リダイレクトさせたいサーバでも、そうじゃないコンピュータでもリダイレクトされません。
おそらく、Authenticated Usersグループを外したため、対象ユーザがいなくなったからでしょう。

そう思って、新たなセキュリティグループを作成し、そこにリダイレクト対象ユーザをメンバとして所属させ、グループポリシーのセキュリティフィルタに「グループポリシーの適用」を許可として追加しました。

そうすると今度はその他のコンピュータを拒否にしているにも関わらず、その他コンピュータでも、本来リダイレクトさせたいサーバでもリダイレクトされてしまいます。

ここからは憶測なので断言ではできませんが、セキュリティフィルタでコンピュータを追加した場合は、グループポリシーのコンピュータの構成に対してフィルタがかかり、セキュリティフィルタにユーザを追加した場合は、グループポリシーのユーザの構成に対してフィルタかかるというような仕様じゃないんでしょうか。。

ということで、セキュリティフィルタは今回の要件では使えないということに。。。


グループポリシーにはセキュリティフィルタの他にWMIフィルタというものがあるようです。
これを使うとより細かい単位でグループポリシーの適用範囲を定義することができるようです。
(ただ、パフォーマンスの影響や適用対象が動的に変わるので、適用範囲の見極めしずらくなったりするようです)

ということで、WMIフィルタを使ってみました。

WMI(Windows Management Instrumentation)クエリはSQLのクエリ構文に似た感じで、自身のコンピュータの状態を取得することができます。

今回は特定のコンピュータでだけグループポリシーを実行したいので、ホスト名を取得し、実行したいコンピュータと一致するかどうかのWMIクエリを作成してみます。

しかし、WMIは膨大な数のプロパティやメソッドがあるので、なかなか簡単には探せません。
そこで役立つのが、マイクロソフトが提供しているWMI Code Creator v1.0というツールです。

このツールを使うと比較的容易にWMIの目的のプロパティを探すこともできますし、WMIスクリプトも作成できます。
使い方は、WMIを使うスクリプトを簡単に作成する - @ITが参考になります。

で、今回作成したWMIフィルタは下記のような感じです。
名前空間:
root\CIMv2
クエリ:
SELECT * FROM Win32_ComputerSystem WHERE  Name ='TestSV1' OR Name = 'TestSV2'

これをGPMCでグループポリシーに関連付けしていざ評価してみたところ、想定通りの動きとなりました。
つまり、TestSV1,TestSV2でログイン(ローカル、リモート関係なく)したときのみ、フォルダリダイレクトが動作するようになりました。
しかし、この WMI フィルタなんですが、クライアントPCが Windows 2000 の場合は、フィルタが効かずグループポリシーが適用になってしまうようなので、Windows 2000 のPCがドメイン内にいる場合は要注意です。


補足:
WMIフィルタで特定のPCやユーザだけグループポリシーの対象にしたくない時は下記のようにWMIクエリを書けばいいようです。
SELECT * FROM Win32_ComputerSystem WHERE  Name <> 'TestSV1' AND UserName <> 'hoge\userA'


参考:
TechNet:セキュリティ グループを使用してフィルタ処理を行う
TechNet:セキュリティ グループ メンバシップに応じてグループ ポリシーのスコープをフィルタ処理する
リンクの継承と優先度およびフィルタ機能 - @IT
TechNet:GPMC を使用して WMI フィルタ処理を行う
by jehoshaphat | 2010-08-24 04:28 | サーバがらみ
(ActiveDirectory)画面ロックを強制する
ActiveDirectoryグループポリシーを使って一定時間放置してたら画面ロックする方法です。


Windowsのスクリーンセーバーのパスワードの保護機能を使うことで、画面ロックを行うことができます。

ユーザの構成→管理用テンプレート→コントロールパネル→画面 で下記の設定を行います。
 スクリーンセーバーを使用する:有効
 スクリーンセーバーパスワードで保護する:有効
 スクリーンセーバーのタイムアウト:有効(秒数で指定。0秒だとスクリーンセーバ無効となる)

これでユーザがログインし、画面のプロパティからスクリーンセーバーを(なし)にしても、スクリーンセーバーのタイムアウト で設定した時間が経てばちゃんとロックされます。

上記の設定をすると、それに関連する画面のプロパティはユーザからは変更できなくなるのでその点は注意が必要です。
by jehoshaphat | 2010-06-13 11:58 | サーバがらみ
グループ・ポリシー管理コンソール(GPMC)を使ってみた
WindowsServer2003ですが、いつもグループポリシーの管理として"Active Directoryユーザーとコンピュータ"を使っているんですが、OUのコンテキストメニューからプロパティ出してグループポリシータブ選択して、対象のグループポリシー選択して編集という感じで、非常に面倒です。。


で、"グループ・ポリシー管理コンソール"使うと使いやすくできるらしいので入れてみました。

ダウンロードはダウンロードの詳細 : GPMC SP1からできます。

左側に各OUツリーがあり、各OUにどのグループオブジェクトがリンクしているかがすぐ分かります。
ツリーには "グループポリシーオブジェクト" があり、そこに全グループポリシーの一覧があるので、全体が見渡せます。

任意にOUについて、どのグループポリシーオブジェクトやポリシーが適用されるかのシミュレーションやレポートが使えるのも非常にうれしいですね。
(今までは別の管理表等作らないと把握できませんでしたからね)

またバックアップ・復元もできるのもたすかります。

クライアント上にインストールして、管理者権限動かせば事足りるので、サーバ上にはインストールしづらいって場合にも使えます。
参考:
@IT:Windows TIPS -- Tips:グループ・ポリシー管理を強力に支援するGPMCを活用する
by jehoshaphat | 2010-05-20 23:41 | サーバがらみ
グループポリシーのソフトウェアインストールが実行されない原因は意外にも。。
グループポリシーのコンピュータの構成で、ソフトウェアインストールのテストをしてたんですが、どうも適用されないPCが数台ありました。
しかもその数台とも同じDELLの同じ型のPCです。

とりあえずイベントビュアーを見てみるとこんなエラー吐いてました。

イベントの種類: エラー
イベント ソース: NETLOGON
イベント カテゴリ: なし
イベント ID: 5719
日付: 2010/02/25
時刻: 09:00:00
ユーザー: N/A
コンピュータ: test-pc
説明:
次の理由のためドメイン hogehoge のドメイン コントローラは利用できません:
現在、ログオン要求を処理できるログオン サーバーはありません。 。
コンピュータがネットワークに接続されていることを確認し 再実行してください。問題が解決されない場合はドメイン管理者に問い合わせてください。


最初は下記のような問題かと思っていました。
MSサポート:Windows Server 2003、Windows XP、および Windows 2000 で Kerberos に UDP ではなく TCP を使用するように強制する方法
MSサポート:Windows で TCP/IP のメディア検出機能を無効にする方法
解決策を実施してしましたが、どうもダメです。

で、最終的に見つけたのが、MSサポート:ギガビット イーサネット デバイスで、ドメイン コントローラに接続できず、グループ ポリシーを適用できないです。

確かに、今回の問題となっているPCのNICはギガビットです。
「メディア検出を無効にしても、Active Directory ドメインに参加できない場合、またはグループ ポリシーをダウンロードできない場合は、ネットワーク アダプタ用の最新のドライバを実行していることを確認してください。」とあるので、ネットワークアダプタのドライバを最新にしてみました。

ちなみに、ネットワークアダプタは、Realtek RTL8168C(P)/8111C(P) PCI-E Gigabit EthernetNIC です。
古いバージョンのドライバは、5.694.507.2008 です。
更新後のドライババージョンは 5.718.323.2009 でした。

ドライババージョンアップ後は、PC起動時にも問題なくグループポリシーが適用されるようになりました。

犯人は、Realtek のダメダメドライバだったということですね。
こういうハードに近い問題がある場合は、ほんと原因わかるまで時間かかるんで、勘弁してほしいです。
by jehoshaphat | 2010-05-15 21:47 | サーバがらみ
OpenOfficeをActiveDirectoryで展開する
OpenOffice3.2が出たのでWindowsドメイン内で一斉展開することになりました。
ただ、手動で各クライアントにインストールすのではなく、グループポリシーを使って展開することにします。

グループポリシーを使うとしても、バッチでやる方法と、ソフトウェアインストール機能を使う方法とがあります。(ソフトウェアインストール機能はMSIファイルが対象)

OpenOfficeはMSIを使っているので、ソフトウェアインストールが使えます。ということで、まずはソフトウェアインストールの方法です。

とりあえずグループポリシーで、コンピュータの構成→ソフトウェアの設定→ソフトウェアインストール からMSIを指定します。
展開の種類は"割り当て"とします。(ユーザの構成だと"公開"ってのも使えますが、これはコンパネのプログラムの追加と削除に出てくるだけで、ユーザが手動でインストールしなければならないようです。)

ソフトウェアインストールの参考:
@IT:MSIファイルをActive Directoryのグループ・ポリシーでインストールする
ソフトウェアインストール方法
GPOでのソフトウェアインストール

ソフトウェアインストールで定義すると、次回起動時(場合によってはその次の起動時)にインストールされます。
インストール中は下記のような画面となります。
OpenOfficeをActiveDirectoryで展開する_e0091163_21373431.jpg



インストール終わらないとログインできないのが難点ですね。OpenOffice並みの巨大ソフトになると、サーバから転送してインストールとなるとかなり時間かかりますから。。


後、要件で、OpenOffice初回起動時に登録ウィザードが上がるのが困るということだったんで、これを何とか無効化できないかと調査しました。
答えがOpenOffice.org 登録ウィザードの無効化 - OpenOffice.org Wikiにありました。
なるほど、拡張機能入れればいいようです。

実はこの拡張機能はOpenOfficeの設定ファイルを書き換えてるだけでした。
その設定ファイル(中身はXML)のパスは下記です。

%programfiles%\OpenOffice.org 3\Basis\share\registry\data\org\openoffice\Setup.xcu


そして、下記ノードを追加しています。
<node oor:name="Office">
<prop oor:name="LicenseAcceptDate" oor:type="xs:string">
<value>2008-12-30T08:14:11</value>
</prop>
<prop oor:name="FirstStartWizardCompleted" oor:type="xs:boolean">
<value>true</value>
</prop>
</node>

要はライセンス承認日付と、ウィザード完了のフラグを入れているだけみたいですね。

FirstStartWizardCompleted フラグにに関する参考資料:
JODConverter - azlab 開発Memo
faq/3/140 - OpenOffice.org Q&A

この拡張機能をバッチでインストールするようにし、グループポリシー コンピュータの構成でスタートアップスクリプトに登録します。

"%programfiles%\OpenOffice.org 3\program\unopkg.exe" add --shared \\servername\dirname\DisableFirstStartWzd.oxt

(なおスタートアップのパスはグループポリシーのGUID\Machine\Scripts\Startup というフォルダに入るようです)

例:
\\domain.local\SysVol\domain.local\Policies\{640C9106-4479-43C3-B205-C260ECC67AAA}\Machine\Scripts\Startup




余談ですが、グループポリシーのソフトウェアインストールを使わずに、バッチでのサイレントインストールもできるようです。(バッチというかMSIの機能ですが。。)
Microsoft Windows - OpenOffice.org Wiki

msiexec /qn /i \servername\dirname\openofficeorg32.msi



さて、これでも初回起動時にユーザー登録のダイアログと、2回目起動時にバグフィックスの送信設定画面が出てきます。
これを何とかしろということで、さらに調査。。。

どうやらバグフィックスの設定やユーザ登録のダイアログ情報は設定ファイルに持っているようなので、かなり強引な手法ですがいったん設定したファイル群をコピーする方法をとることとしました。
なお、設定ファイルは %appdata%\OpenOffice.org\3\user 配下に入ってます。
最初バッチはユーザの構成でログインスクリプトで動かす予定でしたが、展開完了後も全ユーザが使えるようにしたかったので、コンピュータの構成でスタートアップスクリプトで動かすこととしました。
バッチはこんな感じです。
@echo off
 
rem ウィザード無効拡張機能インストール
"%programfiles%\OpenOffice.org 3\program\unopkg" add --shared \\servername\dirname\DisableFirstStartWzd.oxt
 
rem 各ユーザプロファイルのフォルダを探す
for /D %%i in ("%SystemDrive%\Documents and Settings\*") do (
rem echo %%i
rem OpenOffice3.2の設定フォルダが無ければ
IF NOT EXIST "%%i\Application Data\OpenOffice.org\3\user" (
rem サーバからOpenOfficeのユーザ設定データを取得する
xcopy "\\servername\dirname\Application Data" "%%i\Application Data" /e /c /q /y
)

rem デスクトップのショートカット削除
DEL /Q "%%i\デスクトップ\*OpenOffice.org Writer*.lnk"
DEL /Q "%%i\デスクトップ\*OpenOffice.org Calc*.lnk"
DEL /Q "%%i\デスクトップ\*OpenOffice.org Impress*.lnk"
DEL /Q "%%i\デスクトップ\*OpenOffice.org Math*.lnk"
DEL /Q "%%i\デスクトップ\*OpenOffice.org Base*.lnk"
DEL /Q "%%i\デスクトップ\*OpenOffice.org Draw*.lnk"
rem スタートメニューのショートカット削除
rmdir /Q "%%i\スタート メニュー\プログラム\OpenOffice.org 2.4"
DEL /Q "%%i\スタート メニュー\プログラム\スタートアップ\OpenOffice.org 2.4.lnk"
)
 
:end



さらに余談です。。

MSIにはMSTというのもあるらしいです。
例えばコマンドラインオプションを別に設定したいときとかに使えるようですね。
グループポリシーで展開する時に、オプション書いたMSTも指定しておくとより柔軟性が高まりそうです。
今回は使わなかったんで、細かい作成方法は不明ですが、参考になりそうなリンクだけのっけます。
グループポリシーを使ったアプリケーションのカスタムインストール
MSTファイルについて


MSI自体の編集は Orca というMS提供ツールを使えばできるらしいです。
OrcaはMSダウンロード:Windows Server 2003 SP1 Platform SDK Web Installの中に含まれるのでこれをインストールし、さらに、%programfiles%\Microsoft Platform SDK\Bin\Orca.Msi からインストールしないといけないすね。
インストール手順詳細は、Orca(msiファイルの編集ツール)をインストールする方法で説明されています。

またOpenOfficeのMSIの引数で、関連付けに関する設定もできるようです。
たとえばこんな感じ。

start "" /wait "openofficeorg30.msi" /passive ALLUSERS=1 SELECT_WORD=0 SELECT_EXCEL=0 SELECT_POWERPOINT=0 ADDLOCAL=ALL REMOVE=gm_o_Quickstart

↓にかかれてました。
OpenOffice 3.0.0 Silent - MSFN Forums(英文)
by jehoshaphat | 2010-05-15 21:44 | サーバがらみ
グループポリシーのスタートアップはどの権限?
ActiveDirectoryのグループポリシーでコンピュータの構成とユーザーの構成のそれぞれにスタートアップスクリプトとログインスクリプトがあります。

それがどの権限で動くのかがちょっと疑問になったので調査。。

ちなみに、スタートアップスクリプトはグループポリシーの → コンピュータの構成 → Windowsの設定 → スクリプト となります。
スタートアップスクリプトは、コンピュータのローカルシステムアカウント権限で動くみたいです。自身のPCに対しての処理なら大抵何でもできそうですね。

一方ユーザーの構成のログインスクリプトはログオンしているユーザの権限で動くようです。これはまぁ当たり前の話ですね。

参考:
スタートアップ スクリプトの権限 | Port 4403
by jehoshaphat | 2010-05-12 23:54 | サーバがらみ
(.Net,ADSI)OUを取得する際のLDAP条件
ActiveDirectoryの情報を参考にする方法については、(.Net,ADSI)Active Directroyの情報を参照。を参考にしてください。

OUの一覧を取得するLDAP条件は下記でできるようです。(C#)

// LDAP検索オブジェクトを作成
DirectorySearcher drSearch = new DirectorySearcher(mDrctEntry);
// アカウントフィルターを設定 Userオブジェクトだけ取得するように
drSearch.Filter = "(ObjectCategory=organizationalUnit)";
 

//ちなみにユーザオブジェクトを取得する時のLDAPクエリは下記
//drSearch.Filter = "(ObjectCategory=user)";


ただ、親子関係は考慮してないので、階層として表現するのは難しいかもしれません。
ただ単にOUが列挙されるだけみたいです。

階層も含めて取得するいい方法ありませんかね。。。。
by jehoshaphat | 2010-04-29 23:14 | .Net開発