Active Directoryを理解するには、「誰が使うか」「何を使えるか」「端末にどんな設定を適用するか」を分けると整理しやすくなります。本記事では、社内Windows環境のユーザーやコンピューターを管理するActive Directory Domain Services（AD DS）を対象に説明します。
AD DSはユーザーやコンピューターなどの情報を保持するディレクトリサービスです。サインイン時の認証やアクセス制御と結び付き、組織のアカウント管理を支えます。Microsoft Learn：AD DSの概要
社内ドメインとドメインコントローラーの関係
AD DSの論理構造は、フォレストの中にドメインがあり、ドメインの中にOU（組織単位）がある形です。ドメインコントローラー（DC）は、アカウント情報を保持し、ユーザーの認証を担います。ドメインは管理する論理的なまとまり、DCはそのサービスを提供するサーバーとして捉えるとよいでしょう。Microsoft Learn：Active Directoryの論理モデル
| 用語 | 役割 | 担当者が整理する事項（編集上の提案） |
|---|---|---|
| ドメイン | AD DS内のアカウント管理・認証を構成する単位 | どの利用者・端末が対象か |
| DC | アカウント情報の保持と認証 | 誰が保守し、障害時に対応するか |
| OU | オブジェクトを管理目的でまとめる入れ物 | 設定の適用や管理委任をどう分けるか |
| DNS | 認証などに必要なDCの所在を探す仕組み | 端末がどのDNSを参照しているか |
OUはグループポリシーの適用や管理権限の委任に使われます。一方、DNSはAD DSがDCを探すために必要な仕組みです。ドメイン名の文字列だけでなく、端末から必要なDCを見つけられる構成を確認する必要があります。論理モデル、Microsoft Learn：DNSの概要
認証に成功しても、すべてのファイルを使えるわけではない
認証は利用者を確かめる処理、認可はその利用者に操作を許可する判断です。Windowsでは認証後に、対象リソースに必要なアクセス権があるかを判定します。共有フォルダーの権限確認では、ユーザーやグループに対して与えられた権限を確認します。Microsoft Learn：アクセス制御の概要
たとえば「PCにはサインインできるが、経理の共有フォルダーを開けない」という状況を想定します。この場合、アカウントを作り直す前に、対象フォルダー、表示されたエラー、必要なグループへの所属、リソース側のアクセス権を整理することを提案します。これは症状から確認範囲を絞るための手順であり、原因をアクセス権だけに断定するものではありません。
また、Windowsには過去のドメインログオン情報を使って、DCが利用できない場合でもサインインできる仕組みがあります。その場合、ドメインによる検証が必要なネットワークリソースは利用できません。デスクトップを開けたことだけで、DCへの接続が正常とは判断できません。Microsoft Learn：キャッシュされたドメインログオン情報
端末設定はグループポリシーで管理する
グループポリシーは、Windowsのユーザー設定やコンピューター設定を集中管理する仕組みです。設定をまとめたGPO（グループポリシーオブジェクト）をサイト・ドメイン・OUにリンクし、適用範囲を構成します。適用対象は、端末やユーザーがどこに属するかなどによって決まります。Microsoft Learn：Group Policyの概要
そのため運用では、「端末をドメインに参加させた」という作業と、「意図した設定が適用された」という確認を別の項目にすることを提案します。新入社員用のPCであれば、サインインの確認に加え、配置したOU、対象GPO、実際に適用された設定を記録すると、確認漏れを減らすためのチェック表になります。
OUは設定適用や管理委任、アクセス権はリソースの利用許可というように、確認する目的を区別してください。「所属部署が同じだから、端末設定もファイルの権限も同じはず」と判断せず、それぞれの設定を確かめます。
Microsoft Entra IDとの違い
Microsoft Entra IDは、Microsoft 365やSaaSなどのクラウドリソースに対するID・認証サービスです。AD DSと同期して利用する構成もあります。Entra IDで扱う端末の管理には、Microsoft IntuneなどのMDMを利用できます。Microsoft Learn：ディレクトリサービスの比較
別サービスのMicrosoft Entra Domain Servicesは、ドメイン参加、グループポリシー、LDAP、Kerberos／NTLM認証など、従来型AD DS機能の一部をマネージドサービスとして提供します。Entra IDとEntra Domain Servicesを同じものとして扱わないようにしましょう。同比較資料
導入判断では、まず既存アプリが必要とする認証方式、端末設定の管理方法、クラウドサービスの利用範囲を書き出すことを提案します。「Microsoft 365を使うか」だけでAD DSの要否を決めず、社内システムが依存する機能を確認するためです。
運用・委託範囲を決めるための判断表
以下は、ここまでの技術的な役割分担を基にした編集上の確認案です。障害原因を確定する表ではなく、社内担当者と委託先が調査対象・作業の完了条件をそろえるために使います。
| 場面 | 最初に分けて確認すること | 残したい記録 |
|---|---|---|
| 新しいPCを配る | ドメイン参加、サインイン、GPO適用、業務リソースへのアクセス | 端末名、配置OU、試験した設定と利用先 |
| サインインできない | 影響するユーザーと端末、DNS・DCへの接続、表示エラー | 発生時刻、接続場所、影響範囲 |
| 共有フォルダーだけ開けない | 認証状況、対象パス、グループ所属、リソース側の権限 | 必要な操作、現在の権限、承認者 |
| 一部の端末だけ設定が違う | 配置OU、GPOの適用対象、実際に適用された設定 | 正常端末との差分、変更履歴 |
| 異動・退職がある | 変更対象のアカウント、グループ、端末、連携サービス | 作業担当、実施時点、確認結果 |
たとえばPC配布を委託する場合、「ドメイン参加まで」と「業務で使うフォルダーへのアクセス確認まで」では、完了条件が異なります。依頼時に対象と確認項目を列挙し、権限の付与を誰が承認するかも決めておくと、受け渡しが具体的になります。
Active Directoryの運用を検討するときは、認証・権限・端末設定の担当と確認項目を一枚の表にまとめるところから始めてください。委託先を検討する際の事業案内として、テクノヴァースのインフラ支援も参照できます。