「Active Directoryの運用」ドメインユーザーの作成手順を図で解説

Active Directoryのドメインユーザーは、[Active Directory Users and Computers]で対象OUを選び、[New]、[User]から作成します。ただし、名前とパスワードを入れるだけでは運用できません。作成前に人事情報、ログオン名、配置OU、利用開始日、所属グループ、失効日、初期パスワードの受け渡し方法を確認し、最初は無効な状態で作成して承認後に有効化すると安全です。本記事はWindows Server 2016~2025のAD DSを対象に、GUIとPowerShellの手順、確認、失敗時の戻し方まで説明します。

目次

最初にアカウントの種類を確認する

ここで作るのは、オンプレミスのActive Directory Domain Servicesに保存されるドメインユーザーです。Windows端末だけで使うローカルユーザーや、Microsoft 365へ直接作るMicrosoft Entra IDユーザーとは別物です。同期環境では、オンプレミスADで作成した属性がクラウドへ同期される場合があるため、どちらが正しい作成元かをID管理担当へ確認します。二重に作成すると、メールアドレスやUPNの競合、異なるIDへの権限付与を招きます。

  • ドメインユーザー:AD DSで認証し、ドメイン参加端末やファイル共有などへ利用する。
  • ローカルユーザー:1台のPCまたはサーバー内で管理され、ドメイン全体のIDにはならない。
  • Microsoft Entra IDユーザー:クラウドディレクトリで管理し、作成元や同期規則は組織ごとに異なる。
  • サービスアカウント:人が日常ログオンするユーザーとは要件が異なる。可能ならgMSAなど専用方式を検討する。

作成前にそろえる情報

依頼票には、氏名、社員番号、部署、役職、上司、勤務地、入社日、雇用終了日、ログオン名、メールアドレス、必要な業務システムを記載します。似た氏名がいる場合の命名規則も先に決めます。表示名は人が見分ける名称、userPrincipalNameは通常「ログオン名@UPNサフィックス」、sAMAccountNameは旧来互換のログオン名です。表示名が同じでもオブジェクトは作れますが、UPNとsAMAccountNameは組織内で一意に管理します。

対象OUは単なる整理用フォルダーではありません。GPOの適用、管理権限の委任、運用スクリプトの検索範囲に影響します。既定のUsersコンテナーへとりあえず作成せず、正社員、契約社員、外部委託、管理用アカウントなど組織の設計に沿ったOUを選びます。どのOUか不明なら作業を止め、AD設計資料または責任者へ確認します。

必要な権限と管理端末

Active Directory Users and Computersは、ドメインコントローラーまたはRSATのAD DS/AD LDS管理ツールを導入したドメイン参加端末で使用できます。Server Managerの[Tools]から開くか、承認済みの管理端末でdsa.mscを起動します。作成者には対象OUでユーザーオブジェクトを作成・変更する委任権限が必要です。

日常的なユーザー作成にDomain AdminsやEnterprise Adminsを使う必要はありません。対象OUに限定して作成、属性変更、パスワードリセットなどを委任します。管理者は通常のメール閲覧やWeb閲覧に同じ特権アカウントを使わず、操作ログと依頼番号を残します。

Active Directory Users and Computersで作成する

  1. [Active Directory Users and Computers]を開き、左側で正しいドメイン名を確認します。
  2. 作成先OUを選び、右クリックして[New]、[User]を選びます。
  3. First name、Last name、Full nameを命名規則どおりに入力します。日本語表示名とローマ字ログオン名を混同しません。
  4. User logon nameへUPNの左側を入力し、右側のUPNサフィックスが正しいことを確認します。
  5. User logon name (pre-Windows 2000)のsAMAccountNameを確認し、既存アカウントと重複しない名称にします。
  6. [Next]を選び、承認済みの方法で生成した一時パスワードを入力します。
  7. 通常は[User must change password at next logon]を選びます。準備中なら[Account is disabled]も選びます。
  8. 確認画面で氏名、ログオン名、作成先を再確認し、[Finish]を選びます。

[Password never expires]や[Store password using reversible encryption]を安易に有効化しません。前者は組織のパスワード・認証方針に従い、後者は平文に近い形式でパスワードを扱う特別な互換要件がある場合だけ、セキュリティ承認を得て使用します。利用者がパスワードを変更できない設定も、共有アカウントの代替として使わないでください。

作成直後に属性を整える

新しいユーザーを右クリックして[Properties]を開き、依頼票と照合します。[General]の表示名・説明・連絡先、[Organization]の役職・部署・会社・上司、[Account]のUPN・有効期限・ログオン制限、[Member Of]のグループを確認します。[View]の[Advanced Features]を有効にすると、[Object]や[Attribute Editor]など追加タブを確認できます。属性を直接編集する場合は、同期やアプリ連携への影響を把握している項目だけに限定します。

  • Description:用途や雇用区分を記載する。パスワードや機密情報は書かない。
  • Employee ID:人事システムとの照合キー。重複と形式を確認する。
  • Manager:承認フローやアドレス帳で使われる場合がある。
  • Account expires:期限付き要員は最終利用日と時刻の運用を明確にする。
  • Log On To/Logon Hours:強い制限が必要な専用アカウントだけ、影響をテストして設定する。

グループは必要最小限に追加する

ファイル共有、プリンター、アプリの権限は、ユーザーへ直接付けずセキュリティグループへ付与し、そのグループへユーザーを追加します。似た部署の既存ユーザーを参考にする場合も、Member Ofを丸ごと複製しません。管理者グループ、VPN、機密共有、旧プロジェクトなど、その人には不要な権限まで引き継ぐ危険があります。

依頼ごとにグループ名、目的、所有者、承認者を確認します。Domain Admins、Enterprise Admins、Administrators、Account Operatorsなど高権限グループへの追加は通常の入社作業から分離し、別承認と期限を求めます。追加後はグループ一覧を依頼票へ記録し、利用者本人の業務要件と照合します。

パスワードを安全に受け渡す

初期パスワードは推測可能な社員番号、生年月日、共通文字列にしません。組織のパスワードポリシーを満たすランダムな値を生成し、ユーザー名と同じメールやチケットへ平文で併記しないようにします。本人確認済みの電話、対面、期限付きの秘密共有など、承認された別経路で通知します。管理者がパスワードを控え続けない運用も必要です。

[User must change password at next logon]を使う場合、初回ログオンでドメインコントローラーへ到達できる必要があります。完全なオフライン勤務、VPN接続前のWindowsログオン、スマートカード専用などでは初回変更に失敗することがあります。利用開始前に接続経路をテストし、必要なら組織のオンボーディング手順に合わせます。

PowerShellで1件作成する安全な例

ActiveDirectoryモジュールのNew-ADUserを使うと、同じ属性で再現可能な手順を作れます。パスワードをコマンド行やファイルへ直書きせず、Read-HostのSecureStringで入力します。最初は-WhatIfを付けて、対象OUと主要パラメーターを確認します。次は説明用の例なので、ドメイン名、OU、命名規則を自組織へ置き換えてください。

$password = Read-Host 'Temporary password' -AsSecureString
New-ADUser -Name '山田 太郎' `
  -GivenName '太郎' -Surname '山田' `
  -DisplayName '山田 太郎' `
  -SamAccountName 't.yamada' `
  -UserPrincipalName '[email protected]' `
  -Path 'OU=Users,OU=Tokyo,DC=example,DC=com' `
  -AccountPassword $password `
  -ChangePasswordAtLogon $true `
  -Enabled $false -PassThru -WhatIf

出力と依頼内容をレビューしてから-WhatIfを外します。New-ADUserはsAMAccountNameを指定して作成し、Pathを省略すると既定のコンテナーへ作成されるため、業務スクリプトではPathを明示します。大量作成にImport-Csvを使えるものの、CSVへパスワードを平文保存せず、まず1行だけでテストし、重複確認、件数上限、-WhatIf、実行ログを組み込みます。

作成結果を確認する

  1. 作成したOUでF5を押して更新し、同名別人ではなく新しいオブジェクトを開きます。
  2. UPN、sAMAccountName、表示名、社員番号、部署、上司、有効期限を依頼票と照合します。
  3. [Member Of]を確認し、承認されていない特権グループがないことを確認します。
  4. Get-ADUserで検索し、DistinguishedNameと主要属性を読み取ります。
  5. 無効状態のまま同期・メール・アプリ側の準備を完了し、利用開始条件がそろったら有効化します。
  6. テスト端末で初回ログオン、パスワード変更、必要な共有へのアクセスを本人または立会者が確認します。

Get-ADUserは既定では一部のプロパティだけを返すため、確認したい属性を-Propertiesで指定します。ログオン成功だけで完了とせず、不要な共有へアクセスできないことも確認します。同期環境ではクラウド側への反映時間とエラーを確認し、同じメールアドレスを持つ別オブジェクトがないかも調べます。

作成を誤ったときの戻し方

氏名や部署を誤っただけなら、正しいオブジェクトかをSIDやDistinguishedNameで識別してSet-ADUserまたはプロパティ画面から修正します。作成先OUが違う場合は、適用GPOと委任への影響を確認して移動します。誤って有効化した場合はまず無効化し、セッションやクラウド同期など下流の影響を確認します。

誤作成だからと即時削除すると、割り当て済みの権限や同期先のオブジェクトまで影響する場合があります。まず無効化し、依頼者、ID管理、メール管理と削除範囲を確認します。Active Directory Recycle Binは、有効化されていれば削除済みオブジェクトの復元に役立ちますが、削除前から有効である必要があります。復元機能をバックアップの代わりにはしません。

運用チェックリスト

  • AD DS、ローカル、Microsoft Entra IDのどこが作成元か確認した。
  • 氏名、社員番号、UPN、sAMAccountName、対象OUの重複を確認した。
  • 委任された管理アカウントを使い、操作記録と依頼番号を残した。
  • 一時パスワードを平文保存せず、本人確認済みの別経路で通知した。
  • 特権グループを複製せず、必要な業務グループだけ承認に基づき追加した。
  • 無効状態で属性、同期、アクセスを検証してから有効化した。
  • 退職日・契約終了日がある利用者はAccount expiresと無効化手続きを登録した。

ドメインユーザー作成の品質は、ウィザードを完了した速さではなく、正しいIDを正しいOUへ置き、必要な期間だけ必要な権限を与え、後から追跡できるかで決まります。まず1件ずつGUIとGet-ADUserで照合し、命名規則と確認表が固まってからPowerShellによる標準化へ進んでください。

公式情報・参考資料

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次