Active Directoryグループへメンバーを追加する前に、対象ユーザーとグループを一意に特定し、グループ種別・スコープ・付与される権限・承認・有効期限を確認します。少人数ならActive Directory Users and Computers（ADUC）のユーザープロパティ「所属するグループ」またはグループの「メンバー」から追加できます。自動化はActiveDirectory PowerShellモジュールでGet-ADUser/Get-ADGroup/Get-ADGroupMemberを先に実行し、Add-ADGroupMemberを-WhatIfで確認してから限定実行します。Domain Adminsなど高権限グループを日常アカウントへ追加せず、変更前後とロールバックを記録します。
グループ追加で得るアクセスを先に確認する
依頼票にユーザーの表示名だけでなく、サインイン名、社員ID、所属、対象グループのsAMAccountNameまたは識別可能な正式名、必要な資源、アクセスレベル、開始/終了日、承認者を記載します。同姓同名や似たグループ名を検索候補から選ばず、説明、所有者、既存メンバー、グループが付与されているACLやアプリロールを確認します。
セキュリティグループはファイル、アプリ、ユーザー権利などのアクセスを与えます。配布グループはメール配信が目的で、アクセス制御のDACLには使えません。追加がどの権限を生むか分からない場合はグループ所有者へ確認します。「とりあえず入れて試す」ために本番権限を広げず、検証用アカウントと読み取り専用ロールを使います。
グループ種別とスコープを確認する
ADのセキュリティグループにはGlobal、Universal、Domain Localのスコープがあります。Microsoftの説明では、Globalは原則同じドメインのアカウント/Globalグループを含み、フォレスト内の資源へ権限付与できます。Domain Localは信頼先を含む広い主体をメンバーにでき、同じドメイン内の資源へ権限を付与します。Universalは同一フォレストの複数ドメインをまたぐ設計に使えます。
一般的にはアカウントを業務ロールのGlobalグループへ、Globalグループを資源権限のDomain Localグループへ入れる設計を検討します。直接ユーザーを多数の資源グループへ追加すると棚卸しが難しくなります。スコープ変更やUniversal化はレプリケーションや入れ子条件へ影響するため、メンバー追加のついでに変更しません。クロスドメインでは信頼関係と許可されるメンバー種別を確認します。
高権限・組み込みグループを別扱いにする
Domain Admins、Enterprise Admins、Administrators、Schema Admins、Backup Operatorsなどは通常の業務アクセスグループではありません。MicrosoftはDomain Adminsが全DCとドメイン管理へ広い権限を持つサービス管理者グループであると説明しています。日常メールやWeb閲覧に使うアカウントを追加せず、必要なら分離した管理アカウント、時間制限、MFA、特権ワークステーション、監視を使います。
高権限追加は通常のヘルプデスク承認とは別の緊急/特権手順にし、二者承認、期限、目的、作業開始/終了、削除確認を記録します。グループ管理を委任する場合もDomain Adminsへ常時追加せず、MicrosoftのDelegation of Control Wizardで対象OU/オブジェクトと作業を限定します。委任が子オブジェクトへ及ぶ範囲を検証し、グループ自身の所有者権限も棚卸しします。
ADUCでユーザー側から追加する
RSATのAD DS/AD LDS管理ツールが入ったドメイン参加管理端末で、最小権限の管理アカウントを使い「Active Directory Users and Computers」を開きます。対象ユーザーをOUから選び、プロパティの「所属するグループ」を開きます。「追加」でグループ名を入力し、「名前の確認」を押します。不確かな場合は「詳細設定」「検索」で候補の場所、説明、正式名を確認します。
Microsoftの現行手順も、Member OfタブからAddし、Select Groupsで名前を検証してOKで確定する流れです。複数候補が返ったら短い表示名だけで決めず、キャンセルしてグループを別途開きます。追加前に画面または変更票へ現在の所属を記録し、確定後にタブを再表示して目的グループ一件だけが増えたことを確認します。別の既存グループを整理目的で同時に削除しません。
ADUCでグループ側から追加する
複数の承認済みユーザーを一つのグループへ追加する場合は、対象グループのプロパティ「メンバー」を開き、「追加」からユーザー名を検証します。グループの説明、スコープ、種類、Managed By、既存メンバーを先に確認します。ユーザーだけでなく、コンピューター、サービスアカウント、グループもメンバーになり得るため、オブジェクトの種類と場所を必要な範囲に絞ります。
グループのMemberタブは直接メンバーを示しますが、入れ子グループによる間接アクセスをすべて表示するわけではありません。同じユーザーを直接と入れ子の両方で追加しないよう、有効な所属経路を調べます。一括貼り付けで大量追加する前に、先頭数件を検証し、対象外アカウント、退職者、無効アカウント、別ドメインの同名アカウントがないか照合します。
PowerShellは取得とWhatIfを先に行う
ActiveDirectoryモジュールを使う場合、まずGet-ADUser -Identity "taro.yamada" -Server "dc01.example.com"とGet-ADGroup -Identity "GG-App-Accounting-Users" -Server "dc01.example.com"を別々に実行し、DistinguishedName、Enabled、説明、スコープを確認します。次にGet-ADGroupMemberで現在の直接メンバーを取得し、変更前ファイルをアクセス制限された作業場所へ保存します。
追加候補を変数へ保持し、Add-ADGroupMember -Identity $group -Members $user -Server "dc01.example.com" -WhatIfで対象グループとメンバーを確認します。Microsoftの公式構文はIdentityにグループ、Membersにユーザー/グループ/コンピューター/サービスアカウントを指定します。IdentityとMembersを逆にせず、ワイルドカード検索の結果をそのまま変更コマンドへパイプしません。
承認後に限定実行し直後に再取得する
WhatIf出力、変更件数、対象DC、承認が一致したら、同じオブジェクト変数を使い-WhatIfだけを外して実行します。Add-ADGroupMemberは既定では出力を返さないため、無表示を成功の証明にしません。同じDCを指定してGet-ADGroupMember -Identity $groupを再実行し、対象オブジェクトのSID/DistinguishedNameが一件増えたことを確認します。
複数ユーザーは一件ずつ検証済みオブジェクトへ解決し、CSVの行数、重複、空白、文字コード、ドメインを確認します。エラー行を無視して残りだけ続けると承認結果と実結果がずれるため、成功/失敗を個別に記録します。公式資料はグループを自分自身のメンバーに追加できてしまい不安定動作を招くと注意しています。入れ子追加では循環参照を事前に検査します。
直接所属と有効な所属を区別する
Get-ADGroupMemberは対象グループのメンバーを確認する基本コマンドです。ユーザー側から所属を見るGet-ADPrincipalGroupMembershipも使えますが、直接/入れ子、Primary Group、外部信頼、アプリ側同期などで見え方が異なります。ADUCのMember Ofだけで有効アクセスの全経路を判断せず、権限資源側のACL、アプリロール、トークン内グループも確認します。
ユーザーにwhoami /groupsなどで現在のWindowsアクセストークンを確認してもらう場合、既存セッションは追加前のトークンを保持します。業務を保存してサインアウト/サインイン、アプリ再起動、SMB再接続など対象サービスに合う更新を保守可能な時間に行います。強制再起動やKerberosチケット全消去を最初の手段にせず、AD変更、レプリケーション、トークン、アプリ同期の順に切り分けます。
レプリケーションとアプリ同期を待って確認する
変更直後は書き込んだDCで見えても、別サイトのDC、Global Catalog、Microsoft Entra同期、SaaSのプロビジョニングへ反映するまで時間がかかります。対象DC、変更時刻、参照DCを記録し、正常なレプリケーションを待って代表DCで再取得します。単一ユーザー追加のために全フォレストの強制複製を常用せず、遅延が異常ならrepadminなどの診断結果をAD担当へ渡します。
グループがファイルサーバーACLに使われるなら対象共有で読み取り/書き込み、アプリならサインインと許可機能を検証します。アクセス拒否を解消するため、さらに広いグループやDomain Adminsへ追加しません。拒否理由がACL、入れ子、トークン、アプリキャッシュ、ライセンス、条件付きアクセスのどれかを切り分けます。権限が付与され過ぎていないことも負のテストで確認します。
記録・期限・ロールバックを運用する
変更記録にはユーザーSID/サインイン名、グループSID/名前、直接/入れ子、承認者、実施者、対象DC、前後メンバー、実施時刻、期限、検証結果を残します。高権限や委託先の所属は自動期限通知と定期レビューを設け、異動・退職・案件終了で削除します。グループ所有者がいない状態を避け、アクセスレビューの責任を明確にします。
誤追加のロールバックは同じ対象を再取得し、Remove-ADGroupMemberのWhatIfと確認を経て、その一件だけを削除します。ユーザーの全グループを初期化したり、CSVの「正解一覧」にない所属を一括削除したりしません。削除後も同じDCと代表DC、アクセストークン、実資源を確認します。削除で業務データは消えませんがアクセスを失うため、所有権移管と緊急復旧連絡先を用意します。
確認チェックリスト
- ユーザー/グループをSID・正式名・説明で一意に特定した
- Security/DistributionとGlobal/Universal/Domain Localを確認した
- 高権限グループは分離アカウント・二者承認・期限付きにした
- ADUCの名前の確認で同名オブジェクトを誤選択していない
- Get-ADUser/Get-ADGroup/Get-ADGroupMemberを変更前に実行した
- Add-ADGroupMemberをWhatIf後に限定実行した
- 直接/間接所属、複製、トークン、アプリ同期を区別した
- 前後記録と一件単位のRemoveロールバックを用意した
コメント