会社や組織でActive Directoryを運用していると、異なるドメインに所属する上司をユーザーの「Manager（上司）」属性として設定する場面が出てきます。通常のADUC上では同じドメインのユーザーしか検索できず、設定がスムーズにいかないことも多いものです。今回は、ドメイン間トラスト環境下でManager属性をクロスドメインで設定する方法や注意点を中心に解説します。
異なるドメインにおけるManager属性設定の背景
異なるドメイン同士でユーザーのManager属性を設定したいケースとしては、組織再編や複数ドメイン・フォレストを運用している大規模環境などが挙げられます。実際に運用する場面では、次のような理由でManager属性を跨(また)いで設定したいことがあります。
- グループ会社間で上司部下の関係を可視化したい
- 部署異動により、従来とは異なるドメインのユーザーが上司になる
- 組織図ツリーを正しく反映させたい
Manager属性は、組織の階層を示す上で非常に重要な情報です。しかし標準のActive Directoryユーザーとコンピュータ（ADUC）の「組織」タブやプロパティ画面では、基本的に同一ドメイン内のユーザーしか選択できません。そこで、以下の方法を活用することで別ドメインのユーザーを指定できるようになります。
Manager属性を設定する代表的な方法
1. 属性エディタ (Attribute Editor) の利用
ADUCの表示オプションで「詳細設定（Advanced Features）」を有効化すると、ユーザーオブジェクトのプロパティに「属性エディタ」タブが追加されます。通常は見られない細かな属性を編集できるため、ここでmanager属性に異なるドメインのユーザーのDN（Distinguished Name）を手動で設定します。
属性エディタの表示手順
- Active Directoryユーザーとコンピュータ(ADUC)を起動
- メニュー「表示(View)」から「詳細設定(Advanced Features)」を有効にする
- 目的のユーザーアカウントを右クリック→「プロパティ」を選択
- プロパティ画面に「属性エディタ (Attribute Editor)」タブが表示される
manager属性の編集手順
- 「属性エディタ」タブでmanager属性を探し出す
- manager属性をダブルクリックし、文字列を入力できるテキストボックスにアクセス
- 異なるドメイン側のユーザーのDNを完全修飾ドメイン名で入力（例：
CN=UserB,OU=Sales,DC=DomainB,DC=local） - OKボタンを押して保存
この方法は手作業での編集となりますが、急ぎの対応や台数が少ない場合は比較的簡単です。ただし、この時点でドメイン間の信頼関係が正しく確立されており、グローバルカタログ(以下GC)の検索が問題なく行われる必要があります。また、属性を直接操作するため、必要な権限があるアカウントで操作することも大切です。
2. PowerShellスクリプトによる設定
より多くのユーザーに対して一括変更を行う場合や、運用を自動化したい場合はPowerShellが便利です。Windows Serverに搭載されている「Active Directoryモジュール」を利用すれば、Set-ADUserコマンドレットでmanager属性を直接指定できます。
代表的なコマンド例
Set-ADUser -Identity "UserA" `
-Manager "CN=UserB,OU=Sales,DC=DomainB,DC=local"
このとき-IdentityパラメータにはSamAccountNameやUserPrincipalName、あるいはオブジェクトのDNを指定可能です。
Managerとして指定するユーザーは以下のように表記を行います。
| 要素 | 例 |
|---|---|
| CN | UserB |
| OU | Sales |
| ドメイン部 | DC=DomainB,DC=local |
CN=UserB,OU=Sales,DC=DomainB,DC=local のように記述し、文字列で渡します。もし一括処理したい場合にはCSVファイルなどを活用し、ForEachループ内でSet-ADUserを呼び出すことで効率的に変更できます。
設定に必要なドメイン間信頼と権限のポイント
異なるドメイン間での属性設定を行うためには、以下のポイントを事前にチェックしておく必要があります。
1. ドメイン間のトラストが双方向であること
Trust(信頼関係)は「片方向」「双方向」「外部」「フォレスト」など複数の種類があります。Manager属性のように異なるドメインのオブジェクトを参照する場合、少なくとも双方向の信頼関係が設定されていることが望ましいです。
一方向の信頼関係だけだと、参照先のオブジェクトを見つけられずエラーになる場合があります。
2. グローバルカタログ(GC)の構成
ADオブジェクトを検索する際、多くの場合グローバルカタログに問い合わせて存在を確認します。GCサーバーが正しく構成されていない、もしくはポート3268(デフォルト設定)が通信不可な状態だと、クロスドメインのユーザーを見つけられないことがあります。
GCが有効化されたドメインコントローラが複数のサイトに配置されている環境では、サイト間のレプリケーションの遅延や障害が原因で一時的にオブジェクト情報が取得できない場合もあります。そうしたケースは、レプリケーションの状況を確認しましょう。
3. 適切な権限がある管理者アカウント
manager属性を編集するには、該当ユーザーオブジェクトのプロパティを書き換える権限が必要です。通常はAccount Operators以上の権限や、ユーザーに対するフルコントロール権限を持っていれば編集可能ですが、クロスドメインの場合は信頼の設定によっては追加権限が求められる場合もあります。
権限が足りない場合、PowerShellでコマンドを実行しても「アクセスが拒否されました」となったり、属性エディタに値を入力しても反映されないといった現象が起こり得ます。
運用時に押さえておくべき注意点
1. マネージャー属性は相互参照になる場合がある
Manager属性の設定により、他ドメインのユーザーが上司に設定された場合、そのユーザーのDirectReports属性には当該ユーザーが追加されます。異なるドメインであっても、この相互参照が成立するため、組織図のツリー構造に影響が及びます。
2. オフライン環境やネットワーク制限
複数ドメインを管理するネットワークがVPN越しだったり、ファイアウォールの制限が厳しい場合は、GCやLDAPのポートに対する通信を許可していなければ参照ができません。特に複数のActive Directoryサイトにまたがるケースでは、Site & Servicesやファイアウォール設定を入念に見直す必要があります。
3. ユーザーのオブジェクト移動
ドメインA側のユーザーが異動してOU構成が変わったり、ドメインB側のユーザーが退職したりするとManager情報が正しく反映されないことがあります。定期的にレポートを生成して、Manager属性が不整合を起こしていないか確認することが望ましいです。
4. 名前解決とDNSの確認
ドメイン間での名前解決が不安定な場合、PowerShellでmanagerを設定しようとすると「オブジェクトが見つからない」等のエラーが出る場合があります。DNSのフォワーダーや条件付きフォワーダー設定を確認し、相手ドメインのSRVレコードを正しく引けるか検証しておくと安心です。
代替案：Contactオブジェクトの活用
どうしても異なるドメインのユーザーを直接参照できない環境（信頼関係が構築できない、あるいは参照したくない）がある場合、Contactオブジェクトを作成する方法があります。
片方のドメインにもう一方のユーザーに対応するContactを新規作成することで、あたかも同一ドメイン内のユーザーのように検索・選択できるようになります。ただし運用が煩雑になり、ユーザーとContactの情報が重複管理となるため、管理コストが増大しやすい点に注意が必要です。
Contactオブジェクトを用いた手順イメージ
- ドメインA上に、ドメインBのユーザー「UserB」のContactオブジェクトを作成
- Contactオブジェクトには「名前」「メールアドレス」などを設定
- ADUC上からドメインAのユーザーに対し、ManagerとしてContactを割り当て
この場合、実ユーザーとContactオブジェクトの間にズレが生じる可能性があるため、小規模かつ一時的な用途以外ではあまり推奨されません。
運用例：PowerShellスクリプトで一括設定
大規模環境では、数百・数千ユーザーのManager属性を同時に変更する必要があるかもしれません。ここでは簡単なスクリプト例を示します。
Import-Module ActiveDirectory
# CSVファイル例:
# UserSamAccountName,ManagerDN
# userA, CN=UserB,OU=Sales,DC=DomainB,DC=local
# userC, CN=UserD,OU=Marketing,DC=DomainB,DC=local
$csvData = Import-Csv -Path "C:\Temp\ManagerList.csv"
foreach($line in $csvData){
$userSam = $line.UserSamAccountName
$managerDN = $line.ManagerDN
Set-ADUser -Identity $userSam -Manager $managerDN
Write-Host "Manager for $userSam was set to $managerDN"
}
このようにCSVファイルを用意し、1行につきユーザーのSamAccountNameとManagerDNを登録すれば、一括でManagerを変更できます。大量変更の場合は実行前にテスト環境やステージング環境で十分に検証しましょう。
トラブルシューティングのポイント
実際に設定してみると、さまざまなエラーや想定外の挙動に出会うことがあります。以下に代表的なトラブルシューティングをまとめます。
1. 「オブジェクトが見つかりません」エラー
PowerShellや属性エディタでmanager属性を設定しようとした際、以下のようなエラーが出る場合があります。Set-ADUser : Cannot find an object with identity "..." under: "DC=..."
原因として考えられるのは、DNの綴り間違い、参照先ユーザーが存在しない、DNS解決不備などが代表的です。まずは指定したDNが正しいかをよく確認し、必要に応じて Get-ADUser -Identity "..." -Server "ドメインコントローラ" などで存在を確認します。
2. 「アクセスが拒否されました」エラー
権限不足が原因であることがほとんどです。管理者権限を持つユーザーアカウント、もしくはmanager属性編集が許可された委任権限を付与したアカウントで操作する必要があります。また、クロスドメインでの編集の場合、双方向トラストが設定されていないとこのエラーが発生する場合もあります。
3. レプリケーションの遅延による設定反映不良
大規模環境や複数サイト運用のADでは、レプリケーションに数分から数十分の遅延が発生することがあります。設定後すぐに確認した際に反映されていないように見えても、時間が経てば正しく反映される場合もあるため、十分な時間を置いてから再度確認すると良いでしょう。
運用効率を上げるコツ
1. 属性の一元管理ツールを利用する
サードパーティ製の管理ツールやMicrosoftが提供するActive Directory管理センター(ADAC)などを活用することで、GUI上でクロスドメインのユーザーを検索しやすくなる場合があります。必ずしもADUCに依存せず、多彩なツールを組み合わせることで運用負荷を軽減できます。
2. 監査ログの活用
manager属性の設定や変更がどのようなタイミングで行われたのかを追跡するため、監査ログ設定を強化しておくのも一案です。誤った設定や悪意のある改変を早期に発見しやすくなります。
3. グループポリシーで共通環境を整備
複数のドメインコントローラが存在する環境では、グループポリシーオブジェクト(GPO)を使ってLDAP通信やファイアウォール設定、タイムサービスなどを一元管理することで、運用やトラブルシュートが容易になります。AD環境の健全性を維持することでManager属性の設定もスムーズに行えるでしょう。
まとめ
異なるドメインのユーザーをManagerとして設定するには、通常のADUC画面だけでは不十分であり、属性エディタを使う方法やPowerShellでmanager属性を直接編集する方法が一般的です。その際、双方向トラストの構築やグローバルカタログの利用可否、アクセス権限などの基礎設定が非常に重要なポイントとなります。運用効率を高めるためには、一括スクリプト運用や管理ツールの導入、定期的なレプリケーション確認などを通して、必要な情報が円滑にやり取りできる環境を作ることが大切です。
「Contactオブジェクトを用いる」方法は一つの代替策ですが、管理負荷の増大を招くため、むやみに使用せず、正攻法であるトラストとGCを活用してのクロスドメイン参照を整備するほうが結果的に運用コストを下げることにつながります。
是非ここで紹介した手法を参考に、自社環境でも円滑に異なるドメインのManager属性が設定できる仕組みを実現してみてください。
コメント