【Active Directory】ドメインユーザーとは？Domain Users や Domain Adminsも絡めて明快に解説

ドメインユーザーとは、Active Directory Domain Services（AD DS）に作成され、ドメインコントローラーが一元的に認証するユーザーアカウントです。会社のPCへサインインできることと、サーバーを管理できることは別です。通常のドメインユーザーは業務に必要な範囲だけを許可され、Domain Users は広い利用者集合、Domain Admins はドメイン全体を管理できる最上位級の特権グループです。本記事では、ローカルユーザー、Authenticated Users、ローカル Administrators も含めて違いを整理し、安全な権限設計と確認方法まで解説します。

ドメインユーザーはAD DS上のセキュリティプリンシパル

ドメインユーザーは、AD DSのUserオブジェクトとして保存される「セキュリティプリンシパル」です。人が対話的に使う一般アカウントのほか、設計によってはサービスの実行主体として使われるユーザー型アカウントもあります。ドメインコントローラーは資格情報を確認し、アカウントの状態、サインイン条件、所属グループなどを基に認証処理を行います。PCごとに同じ利用者を登録するローカルアカウントとは異なり、複数のドメイン参加端末やサーバーで同じ組織IDを利用できる点が特徴です。

ただし、AD DSのドメインユーザーとMicrosoft Entra IDのユーザーは同じ用語ではありません。同期構成では同じ人に対応するオブジェクトが両方に存在することがありますが、オンプレミスADへのサインイン、Microsoft 365へのサインイン、クラウド側の管理ロールは別々に評価されます。「ドメインユーザーだからクラウドにも入れる」「Microsoft 365管理者だからDomain Adminsである」とは限りません。障害調査では、どのID基盤が認証し、どのシステムが権限を判定したかを分けて確認します。

表示名ではなくSIDがアクセス制御の基準になる

利用者は通常、DOMAIN\user形式または[email protected]のようなUPN形式でサインインします。表示名、姓、メールアドレス、UPN、古い形式のサインイン名は管理上重要ですが、Windowsがアクセス制御の識別に使う中心はSecurity Identifier（SID）です。Microsoftの説明では、ドメインのSIDとアカウント固有のRIDを組み合わせてドメインアカウントのSIDが作られます。アカウント名を変更しても同一SIDなら同じセキュリティプリンシパルとして扱われます。

一方、削除したユーザーと同じ名前でアカウントを作り直しても、新しいSIDが発行されます。以前のファイルACLに古いSIDが残っていても、新しいアカウントへ権限は自動継承されません。退職者アカウントを即時削除して同名再作成で引き継ぐ運用は避け、まず無効化し、所有データ、グループ、直接付与ACL、サービス依存を調査します。SIDを人名のように再利用できないという原則を理解すると、「名前は同じなのに開けない」という現象を説明できます。

認証と認可を分けると権限の仕組みが分かる

認証は「そのユーザーが誰か」を確認する処理、認可は「確認されたユーザーが何をしてよいか」を決める処理です。サインインに成功するとWindowsは、本人のSID、所属グループのSID、ユーザー権利などを含むアクセストークンを作成します。ファイル共有やプリンター、アプリケーションは、そのトークンと対象リソースのACLなどを照合してアクセスを許可または拒否します。ドメインへのサインイン成功だけで、全共有フォルダーを読めるわけではありません。

グループ所属を変更しても、すでに発行済みのアクセストークンやアプリ独自のセッションへ直ちに反映されない場合があります。クライアントでの確認は、変更の複製状況を待ち、対象ユーザーをサインアウトして再サインインした新しいセッションで行うのが基本です。サービスやWebアプリが独自トークンを使う場合は、その製品側の再認証条件も確認します。権限エラーを「ADが壊れた」と決めつけず、認証、グループ、トークン、ACLの順に切り分けます。

Domain Usersは通常のドメイン利用者を表す既定グループ

Domain Usersは、ドメイン作成時から存在するグローバルセキュリティグループです。Microsoftの現行資料では、ドメイン内のすべてのユーザーアカウントを含み、新しいユーザーアカウントは既定で追加されます。既知のRIDは513で、SIDはS-1-5-21-<domain>-513という形です。全社員向けプリンターなど、ドメインの利用者全体を表したい場面には使えますが、管理者グループではありません。

Domain Usersを「営業部」「経理担当」「特定システム利用者」の代わりに使うと、対象が広すぎて最小権限になりません。機密共有、リモート接続、業務アプリでは、職務や対象リソースを表す専用セキュリティグループを作り、承認された利用者だけを所属させます。また、Domain Usersを日常運用で削除・改変して利用者の区分を作るのではなく、組織固有のグループを追加して権限を表現します。既定グループは製品や既存ACLが前提としている可能性があるためです。

グループスコープを使って人とACLを分離する

AD DSのセキュリティグループには、グローバル、ドメインローカル、ユニバーサルなどのスコープがあります。グローバルグループには原則として同じドメインのアカウントやグローバルグループをまとめ、ドメインローカルグループには同じドメイン内のリソース権限を割り当てる構成が取りやすくなります。ユニバーサルグループは同一フォレストの複数ドメインをまたぐ役割に利用できますが、複製範囲も考えて設計します。

実務では「ユーザー → 同一ドメインの職務グローバルグループ → リソース用ドメインローカルグループ → ACL」のように段階化すると、異動時は職務グループの所属変更だけで済みます。これはグループスコープの性質から組み立てる代表的な設計パターンであり、環境ごとの命名、信頼関係、アプリの制約に合わせて調整します。個人ユーザーを多数のフォルダーACLへ直接追加すると、棚卸しと退職処理が難しくなるため避けます。

Domain Adminsは日常利用者の上位版ではない

Domain Adminsは、ドメインを管理する権限を持つ既定のグローバルセキュリティグループで、既知のRIDは512です。Microsoftの資料では、Domain Adminsは既定でドメイン参加した全コンピューターのAdministratorsグループに属し、ドメインコントローラーへの全面的なアクセスや管理グループの変更能力を持ちます。また、AdminSDHolderによって保護される高特権グループです。単に共有フォルダーを一つ開くために追加する権限ではありません。

Domain Admins相当の資格情報が一般PCで盗まれると、攻撃者がドメイン全体へ到達できる恐れがあります。Microsoftの現行Tierモデルも、Domain Adminsで日常業務を行うことをアンチパターンとして挙げています。メール、Web閲覧、文書作成には通常アカウントを使い、管理専用の別アカウント、管理対象と同じ信頼レベルの特権アクセス端末、最小限かつ監査可能な昇格手順を用意します。Domain Adminsの常任メンバーは必要最小限にします。

Enterprise AdminsとローカルAdministratorsも区別する

Enterprise AdminsはActive Directoryフォレストのルートドメインだけに存在し、子ドメイン追加などフォレスト全体の変更を実行できる最高特権級グループです。Domain Adminsが基本的に一つのドメインを管理するのに対し、Enterprise Adminsはフォレスト横断です。どちらも通常利用者へ付与するものではなく、必要な作業、期間、承認、実施者を限定します。Schema Adminsなど他の高特権グループも同様に、作業がないときは空または最小構成を保ちます。

ローカルAdministratorsは各Windowsコンピューターにあるローカルグループです。ある端末のローカル管理者になっても、それだけでDomain Adminsにはなりません。逆にDomain Adminsは既定構成でドメイン参加コンピューターのローカルAdministratorsに含まれるため、影響範囲が極めて広くなります。端末管理が必要なら、対象端末やサーバー群に限定した管理グループを設計し、GPOなどでローカルグループ所属を制御します。権限障害の回避策としてDomain Adminsを配布しないことが重要です。

Authenticated Usersは編集できる通常グループではない

Authenticated UsersはDomain Usersとは異なる「特殊なIDグループ」です。Microsoftの資料では、サインイン処理を経てシステムへアクセスするユーザーにこのIDが与えられ、所属はOSが制御します。Active Directory Users and Computersで人を追加・削除する通常のグループではなく、グループスコープも適用されません。既知のSIDはS-1-5-11です。認証された主体を広く表すため、Domain Usersより対象が広くなる場面があります。

たとえばコンピューターアカウントやサービスのセキュリティコンテキストを含む認証主体がACL評価に関わる場合があり、「社員だけ」の意味でAuthenticated Usersを安易に使うと想定外のアクセスにつながります。Everyoneも別の特殊IDで、匿名アクセスを含むかなどはOS世代と設定を踏まえて確認が必要です。全社公開、ドメイン利用者限定、特定職務限定、端末限定のどれを意図するのかを先に定義し、その意味に合うグループをACLへ割り当てます。

現在のユーザーとグループを読み取り専用で確認する

対象PCでコマンドプロンプトを開き、whoamiを実行すると現在のドメイン名とユーザー名、whoami /userではユーザーSID、whoami /groupsでは現在のアクセストークンに含まれるグループを確認できます。whoami /allはユーザー、グループ、権限をまとめて表示します。結果には組織名、SID、グループ情報が含まれるため、外部へ貼り付ける際は機密情報を伏せます。

管理者はActive Directory Users and Computersで対象ユーザーのプロパティを開き、Account、Member Of、Objectなどを確認できます。高度な機能を有効にした場合だけ見えるタブもあります。表示される所属だけで結論を出さず、グループの入れ子、対象リソースのローカルグループ、明示的な拒否ACE、共有権限とNTFS権限、別資格情報で残ったセッションも照合します。調査のために権限を追加する前に、現状を記録して再現条件をそろえます。

アクセス拒否は最小の変更で直す

共有フォルダーへアクセスできない場合は、対象ユーザー、端末、UNCパス、発生時刻、エラー内容を記録し、名前解決と接続、認証したアカウント、アクセストークンのグループ、共有権限、NTFS ACLの順に確認します。アクセス拒否を解消するためDomain Adminsへ入れると、原因が隠れるだけでなく被害範囲をドメイン全体へ広げます。必要な読み取り・変更権限だけをリソース用グループへ付与し、検証ユーザーをその職務グループへ追加します。

「アクセス許可」と「ユーザー権利」も別概念です。前者はファイルやプリンターなど個別リソースに対するReadやModify、後者はローカルログオン、ネットワーク経由アクセス、バックアップなどシステム動作の許可です。グループに両方が結び付くことがあるため、ACLだけでなくGPOのUser Rights Assignmentも調べます。明示的な拒否は広い許可より優先する場合があるため、拒否ACEの乱用を避け、許可グループ中心で説明可能な構成にします。

入社・異動・退職で権限をライフサイクル管理する

入社時は、本人の所属と職務を根拠に標準グループを割り当て、Domain Users以外の追加権限は申請と承認を残します。異動時は旧職務グループを外して新職務へ切り替え、兼務権限には期限を設けます。定期棚卸しでは、グループの所有者、目的、承認者、メンバー、ACLの参照先、最終利用を確認します。長期間使われないアカウント、個人への直接ACL、説明できない入れ子、常任の特権所属を優先して是正します。

退職時は最初にアカウントを無効化し、既存セッション、VPN、クラウド、証明書、サービス、スケジュールタスクなどAD外の経路も別途失効させます。Microsoftの管理手順では、無効化後もすでにサインイン中の利用者はそのセッションに残るため、無効化だけを即時切断と誤解しないことが重要です。削除前にデータ所有権と依存関係を引き継ぎ、保持期間を経て削除します。AD Recycle Binやバックアップの有効性も平時に確認します。

高特権アカウントはTier 0として別管理する

現行のMicrosoft Tierモデルでは、ドメインコントローラー、AD CS、AD FS、Microsoft Entra Connect、およびそれらを管理できるアカウントやシステムはTier 0のID制御面として扱います。Domain Adminsだけでなく、ドメインコントローラーのバックアップ、監視、仮想基盤、EDRなどを操作できるアカウントも、実質的な制御範囲からTier 0になり得ます。グループ名だけで高特権かどうかを判定しないことがポイントです。

Tier 0資格情報は通常PCや低いTierのサーバーへ入力せず、専用の特権アクセスワークステーションから使います。共有IDを避け、個人を識別できる管理専用ID、強い認証、承認された昇格、操作ログ、緊急用アカウントの保護と定期テストを組み合わせます。通常のドメインユーザーは必要最小限の業務グループだけ、管理者は管理対象ごとに分離したアカウントという構成にすると、侵害時の横展開を抑え、監査でも誰が何をしたか追跡できます。

確認チェックリスト

• 対象アカウントがAD DS、ローカル、Microsoft Entra IDのどれかを区別する
• whoami /userとwhoami /groupsで現在のSIDとトークンを確認する
• Domain Usersを全利用者向け、職務グループを限定権限向けに使い分ける
• 共有権限、NTFS ACL、ローカルグループ、GPOのユーザー権利を分けて調べる
• Domain Adminsを日常アカウントや権限障害の回避策として使わない
• 退職時は無効化に加え、既存セッションとAD外の認証経路も失効させる

ドメインユーザーは、組織のAD DSが認証するユーザー型セキュリティプリンシパルです。Domain Usersは通常のドメイン利用者を広く表す既定グローバルグループであり、Domain Adminsはドメイン全体を制御できる高特権グループです。さらにAuthenticated UsersはOSが所属を決める特殊ID、ローカルAdministratorsは端末単位の管理グループで、それぞれ意味と範囲が違います。ユーザー名ではなくSID、認証ではなく認可、個人ではなく職務グループという軸で整理し、通常利用と特権管理を分離すれば、分かりやすく安全な権限管理になります。

公式情報・参考資料

• Microsoft Learn: Active Directory security groups
• Microsoft Learn: Security identifiers
• Microsoft Learn: Special identity groups
• Microsoft Learn: Manage user accounts in Active Directory Users and Computers
• Microsoft Learn: whoami command
• Microsoft Learn: Reducing the Active Directory attack surface
• Microsoft Learn: AD DS tier model