【Active Directory】ユーザーパスワードのリセット方法を4通り解説

結論から言うと、ADユーザーのパスワードリセットは、本人確認、対象アカウントの一意確認、対象OUに限定した委任権限、平文を残さない入力、結果記録の5点をそろえて実行します。画面操作ならActive Directoryユーザーとコンピューター（ADUC）またはActive Directory管理センター（ADAC）、緊急の単発操作ならnet user、再現性と確認を重視するならActive Directory用PowerShellを選びます。

ここで扱うのはオンプレミスのActive Directory Domain Services（AD DS）です。Microsoft Entra IDのセルフサービスパスワードリセットとは対象も管理画面も異なります。また、一般ユーザーのパスワードリセット手順で、gMSA、krbtgt、サービス、同期、アプリ実行用アカウントを変更してはいけません。これらは依存サービスと専用の変更手順が必要です。

4つの方法の選び方

方法	向いている場面	パスワードの入力	次回変更・ロック解除	主な注意点
ADユーザーとコンピューター	ヘルプデスクの通常対応	GUIの非表示欄	同じ画面で選択可能	同姓同名とOUを確認する
Active Directory管理センター	ADACを標準管理画面にする組織	GUIの非表示欄	画面で設定する	接続先と対象を確認し、履歴ペインを使わない
net user	最小限の緊急操作	*で非表示入力	別途確認する	ドメイン対象では/domainを省かない
PowerShell	監査しやすい定型操作、詳細確認	SecureString	別コマンドで明示	大量処理へ安易に展開しない

どの方法でも、実行できる権限と実行すべき権限は別です。ローカル管理者だからADユーザーをリセットできるわけではなく、反対にDomain Adminsを使う必要もありません。MicrosoftのDelegation of Control Wizardにある共通タスク「Reset user passwords and force password change at next logon」は、パスワードリセットと次回ログオン時の変更要求を委任するもので、ロック解除まで自動的に許可するタスクではありません。ヘルプデスクへロック解除も担当させる場合は、解除を別の役割・権限として対象OUだけにスコープし、専用のテスト用ロックアカウントで実行可否と監査記録を確認します。解除に失敗しても通常運用をDomain Adminsへ切り替えず、委任設計と対象OUを修正します。

実行前の安全確認

1. 本人確認：組織の定めた本人確認を完了し、チケット番号を取得する。発信者番号や表示名だけで判断しない。
2. 対象確認：表示名だけでなくUPN、sAMAccountName、社員番号、所属OUのうち複数を照合する。
3. 用途確認：一般ユーザーか、サービス・タスク・アプリ・同期に使われるアカウントかを確認する。
4. 状態確認：無効化、ロック、期限切れ、次回変更要求、適用されるパスワードポリシーを分けて見る。
5. 権限確認：対象OUへ限定して委任された管理アカウントと管理用端末を使う。
6. 伝達確認：一時パスワードの安全な伝達経路と、利用者が変更画面へ到達できるかを決める。

パスワードの変更は本人が現在のパスワードを知って新しい値へ変える操作、管理者によるリセットは現在のパスワードを使わずに置き換える操作です。リセットすると、利用者が保存している古い資格情報、スマートフォン、VPN、タスク、サービスなどが認証失敗を繰り返すことがあります。ロック解除だけを求められているのにリセットまで行わないよう、依頼内容を分けます。

方法1：Active Directoryユーザーとコンピューターでリセット

RSATを入れた管理用端末でActive Directoryユーザーとコンピューターを開きます。対象ドメインとOUを展開し、ユーザーを右クリックしてReset Passwordまたはパスワードのリセットを選びます。検索結果から開く場合も、AccountタブやObjectタブでUPN、ログオン名、識別名を確認してから操作します。

新しい一時パスワードを2回入力します。組織のパスワードポリシーを満たし、推測しやすい共通初期値を使い回さないでください。画面共有や録画中なら停止し、入力値をチケット本文、チャット、メールへ貼り付けません。

一般ユーザーが通常の対話サインインで自分の新しいパスワードを設定できる場合は、User must change password at next logonを有効にします。VPN接続前に変更できない遠隔利用者、非対話アカウント、サービス依存アカウントではこの選択が停止原因になるため、組織手順へ分岐します。ロック中で解除も承認されている場合だけ、Unlock the user accountを選びます。

OKを選び、成功メッセージを確認します。成功後はチケットへ実行時刻、対象UPN、実行者、次回変更の有無、ロック解除の有無を記録します。一時パスワードそのものは記録しません。利用者へは承認済みの別経路で伝え、初回サインイン後に変更できたことまで確認します。

方法2：Active Directory管理センターでリセット

Active Directory管理センターはdsac.exeで開けるAD管理GUIです。左側で対象ドメインを選び、対象OUまたはGlobal Searchからユーザーを探します。パスワードリセットでは、前掲の警告どおりWindows PowerShell Historyペインを使用しません。履歴が閉じていること、画面共有と録画が停止していることを確認してから対象を選びます。

対象OUを開き、ユーザーのUPN、識別名、所属を確認します。同名利用者がいる組織では、検索結果の表示名だけで右クリックしないでください。依頼票の社員番号など、AD外の本人確認情報とも照合します。

対象ユーザーを右クリックしてReset passwordを選びます。画面の位置や表記はWindows Serverの言語で変わりますが、入力するのは新しいパスワード、確認入力、次回サインイン時変更などです。

一時パスワードを2回入力し、一般ユーザーで必要な場合だけ次回サインイン時の変更を有効にします。ADACをDomain Adminsで開き続けるのではなく、対象OUへ委任された管理グループの資格情報を使用します。管理端末を離席する前にコンソールを閉じ、管理セッションを残さないでください。

結果を確認し、ADUCと同じ監査項目を記録します。ADACで失敗してADUCでは成功する、またはその逆の場合は、接続先、実行資格情報、対象オブジェクト、管理端末のRSAT状態を比較します。ツールを変えて何度も候補パスワードを試すのではなく、エラー内容を保持して原因を切り分けます。

方法3：net userでパスワードを非表示入力

net userはローカルコンピューターまたはドメインのユーザーを管理するWindowsコマンドです。ドメインユーザーを対象にする場合は/domainを付け、パスワード位置へ*を指定します。アスタリスクを使うとパスワード入力が画面に表示されません。例では検証用アカウントuser01を使っています。実行前に実環境の対象ログオン名をGUIまたは承認済みの検索で一意確認してください。

net user user01 * /domain

コマンドを実行すると新しいパスワードと確認入力を求められます。実値をコマンド行に並べる方法は、履歴、画面、ログ、監視製品、手順書へ資格情報が残るため掲載しません。/domainを省くと同名のローカルアカウントを変更する可能性があります。成功メッセージだけで対象が正しいと決めず、依頼票のUPNと実行したsAMAccountNameを再照合します。

net userは短い一方で、対象の識別名、細かいパスワードポリシー、ロック状態を同じ画面で確認しにくい方法です。定型化された単発の緊急手順に限定し、一般運用ではADUCまたはPowerShellで事前確認を含めます。次回サインイン時変更やロック解除が必要なら、GUIまたは次のActive Directory PowerShellコマンドで明示的に行います。

方法4：PowerShellでSecureStringを使う

ActiveDirectoryモジュールを利用し、対象の書き込み可能なドメインコントローラー（DC）と、一人のユーザーを先に確認します。以下は一人ずつ確認する対話操作です。コードを一括貼り付けせず、各段階の表示と承認を確かめて進めます。読み取り専用DC（RODC）やグローバルカタログのポートは、パスワードを設定する接続先にしません。

Import-Module ActiveDirectory
$DirectoryServer = Read-Host '対象ドメインの書き込み可能DCのFQDN'
if ([string]::IsNullOrWhiteSpace($DirectoryServer)) { throw 'DCが空のため中止します。' }

DC名は組織の管理情報から確認します。-Serverをすべての検索・変更・読み直しに指定することで、対象確認時と変更後で別DCへ接続して結果が食い違う状況を避けます。接続先を指定しても、権限や複製状態の確認が不要になるわけではありません。

sAMAccountNameで一人を確認する

$SamAccountName = Read-Host '対象のsAMAccountName'
if ([string]::IsNullOrWhiteSpace($SamAccountName)) { throw '対象が空のため中止します。' }
$User = Get-ADUser -Identity $SamAccountName -Server $DirectoryServer -Properties Enabled,LockedOut,UserPrincipalName -ErrorAction Stop
$User | Select-Object SamAccountName,UserPrincipalName,Enabled,LockedOut,DistinguishedName

Get-ADUser公式資料の-IdentityはDN、GUID、SID、sAMAccountNameまたはADUserオブジェクトを受け取ります。この入力例ではsAMAccountNameに限定しています。表示されたUPN・所属OU・状態が依頼内容と一致しなければ、変更へ進みません。UPNをこの-Identity入力へそのまま渡す方法ではありません。

UPNで受け付ける場合は検索方法を切り替える

UPNで特定する場合は、前のsAMAccountName検索の代わりに次を使います。先にDCを指定する初期化は共通です。0件・複数件は停止し、最初の一件を自動選択しません。

$Lookup = Read-Host '対象のUPN'
if ([string]::IsNullOrWhiteSpace($Lookup)) { throw 'UPNが空のため中止します。' }
$Matches = @(Get-ADUser -Server $DirectoryServer -Filter { UserPrincipalName -eq $Lookup } -Properties Enabled,LockedOut,UserPrincipalName -ErrorAction Stop)
if ($Matches.Count -ne 1) {
    throw "UPN検索結果が $($Matches.Count) 件のため中止します。"
}
$User = $Matches[0]
$User | Select-Object SamAccountName,UserPrincipalName,Enabled,LockedOut,DistinguishedName

確認済みのユーザーへパスワードを設定する

どちらかの検索で一人に解決した$Userを再確認した後だけ、次を実行します。生の入力文字列やワイルドカードではなく、同じADUserオブジェクトを変更先に渡します。

$NewPassword = Read-Host '新しい一時パスワード' -AsSecureString
Set-ADAccountPassword -Identity $User -Server $DirectoryServer -Reset -NewPassword $NewPassword -Confirm -ErrorAction Stop

Set-ADAccountPasswordの公式仕様では、既定では戻り値が出力されません。空の出力だけを根拠に、失敗した・必ず成功したとは判断しません。確認に「いいえ」と回答した場合やエラーになった場合は、後続の次回変更要求・ロック解除へ進まず、対象・権限・ポリシーを再確認してください。

Read-Host -AsSecureStringは秘密値をコードや通常の画面表示へ平文で書かないための入力方法です。侵害された管理端末から秘密を守る保証ではありません。画面共有・録画・履歴のコピーを避け、管理端末の健全性とアクセス制御を前提にします。

次回変更要求とロック解除は必要な操作だけ行う

リセットを承認してエラーなく終えた後、対話サインインする一般ユーザーで、組織手順が求める場合だけ次回変更を設定します。サービスや非対話アカウントには一律設定しません。Set-ADUserの仕様では、PasswordNeverExpiresがtrueの状態とChangePasswordAtLogonがtrueの設定は併用できません。エラー時にパスワード無期限設定を勝手に切り替えず、対象の運用を確認します。

Set-ADUser -Identity $User -Server $DirectoryServer -ChangePasswordAtLogon $true -Confirm -ErrorAction Stop

ロックされており、本人確認とロック解除の承認も完了している場合だけ、別操作として解除します。パスワードリセットをしたから自動的にロックが解けたとは仮定しません。

Unlock-ADAccount -Identity $User -Server $DirectoryServer -Confirm -ErrorAction Stop

同じDCで変更後の状態を読み直す

パスワードリセットの後は、実行した同じDCから対象ユーザーの状態を読み直し、次回変更要求とロック状態を別々に確認します。

Get-ADUser -Identity $User -Server $DirectoryServer -Properties PasswordLastSet,pwdLastSet,Enabled,LockedOut -ErrorAction Stop |
    Select-Object SamAccountName,UserPrincipalName,Enabled,LockedOut,PasswordLastSet,pwdLastSet

PasswordLastSetやpwdLastSetを見て、次回変更要求も設定したかを照合します。MicrosoftのpwdLastSetが0のアカウントに関する説明では、0は「次回サインイン時にパスワード変更を要求」したユーザー等でも見られます。0だからパスワードが未設定、またはリセット失敗と一律に判定しないでください。状態の読み直しは、新しい秘密値の表示やサインインの成功確認ではありません。

実行DC・時刻・対象・実施した操作を秘密値を含めず記録し、利用者の正規のサインイン経路で確認します。解除後にすぐ再ロックする場合は、スマートフォン、Outlook、VPN、タスク、サービス等に保存された古い資格情報の発生元を調べます。再リセットを繰り返す前に、保存資格情報を更新してください。

リセット直後の認証失敗はPDC Emulatorと接続先DCを分けて診断する

MicrosoftのMS-ADTSのPDC Emulator仕様では、他のDCで行われたパスワード変更はPDC Emulatorへ優先的に複製され、あるDCでbad-password認証になった場合はPDC Emulatorへ転送して最新パスワードを確認します。ただし、これは全DCへの通常の複製が完了したという意味ではありません。リセットを実行した書き込み可能DC、実行時刻、対象ドメインのPDC Emulator、再現したクライアントとそのクライアントが利用したDCを記録します。

新しいパスワードが特定DCでは成功し別DCでは失敗するなら複製状態を調べます。ネットワーク未接続端末で古い値が通る、または新しい値が通らない場合はキャッシュされた資格情報とオンラインDC認証を分けます。一度成功した後すぐロックされる場合は、スマートフォン、VPN、タスク、サービス、資格情報マネージャーなどが古い値を再送していないかを調べます。同じリセットを連打せず、複製障害、オフラインのキャッシュ資格情報、保存資格情報による再ロックを別々に診断します。

失敗したときの診断表

症状・エラー	主な原因	確認すること	対処
アクセスが拒否される	対象OUへのリセット権限がない、保護されたアカウント	実行者、対象OU、委任、管理グループ	Domain Adminsへ昇格せず、委任担当者へ権限境界を確認
パスワード要件を満たさない	長さ、複雑性、履歴、細かいポリシー	対象ユーザーの結果セットのパスワードポリシー	要件を満たす新しい値を安全に生成し、ポリシーを弱めない
ユーザーが見つからない	別ドメイン、誤ったsAMAccountName、複数フォレスト	UPN、識別名、接続先、信頼関係	正しい管理コンソールとドメインで再検索
リセット成功後もサインインできない	ロック、無効、期限、端末の接続、キャッシュ	Enabled、LockedOut、ネットワーク、エラーコード	状態ごとに承認を取り、原因を別々に修正
次回変更画面で失敗する	DCへ到達できない、VPN前、ポリシー不一致	端末のネットワークと変更経路	一時パスワードでネットワークへ到達できる手順を案内
すぐ再ロックする	古い保存資格情報が反復認証	スマートフォン、タスク、サービス、資格情報	発生元を止め、保存資格情報を更新
一部の場所だけ古い結果	複製待ち、接続先DCの差	操作時刻、接続先、ADレプリケーション	同じリセットを連打せず、管理者が複製状態を確認

細かいパスワードポリシーは、ドメイン内の特定ユーザーまたはグローバルセキュリティグループへ異なる長さ、履歴、ロックアウト条件を適用できます。既定ドメインポリシーだけを見て「条件は合っている」と判断しないでください。エラーが続く場合は、対象ユーザーへ実際に適用されるポリシーを確認します。候補パスワードをチケットやチャットに列挙して試行記録にしないことも重要です。

Microsoftの細かいパスワードポリシー確認手順では、ADACで対象ユーザーを選び、タスクから「結果セットのパスワード設定の表示（View Resultant Password Settings）」を開いて内容を確認します。読み取り確認なら確認後はキャンセルで閉じます。別ユーザーや既定ドメインの条件を、対象ユーザーの条件と取り違えないようにします。

誤ったユーザーをリセットした場合の対応

パスワードリセットには、元の秘密値を自動的に戻すロールバックはありません。誤操作に気付いたら、隠すために元らしいパスワードを推測して設定せず、組織のインシデント手順へ従います。対象アカウントが利用中なら、新しいサインインが発生する可能性も考えます。

1. 誤って変更した対象、時刻、実行者、操作方法を記録し、ID管理責任者へ直ちに連絡する。
2. 対象者本人を承認済み経路で確認し、意図しないリセットがあったことを通知する。
3. 必要に応じてアカウントを一時保護し、改めて別の一時パスワードを安全な経路で発行する。
4. 次回変更、ロック、無効状態、保存資格情報、依存サービスへの影響を確認する。
5. 平文が画面やログへ出た場合は資格情報漏えいとして扱い、ログのアクセス範囲と二次利用を調査する。
6. 委任範囲、対象確認手順、二者確認の不足を是正し、再発防止を変更管理へ反映する。

一時パスワードを安全に渡す

一時パスワードと対象者名を同じメールやTeamsチャットへ記録すると、履歴が長期間残り、転送や検索で露出します。組織が承認した本人確認済みの音声、期限付き秘密共有、対面などの経路を使い、チケットには伝達完了だけを記録します。利用者へは、初回サインインで直ちに変更すること、他サービスと同じ値を使わないこと、古い値を保存した端末を更新することを案内します。

管理者が利用者の恒久パスワードを知る運用にしないでください。次回変更を使える一般ユーザーでは一時値から本人だけが知る値へ移行します。次回変更が使えない遠隔利用者や特殊環境では、VPN、ネットワークレベル認証、パスワード変更ポータルなど組織固有の経路を事前検証し、利用者をサインイン不能にしない手順を用意します。

よくある質問

パスワードリセットだけでロックも解除されますか？

同じ操作として扱わないでください。ADUCにはリセット画面でロック解除を選べる場合がありますが、必要性と承認を別に確認します。PowerShellでもSet-ADAccountPasswordとUnlock-ADAccountは別コマンドです。再ロックする場合は古い資格情報の発生元を調査します。

Domain Adminsで実行すれば早いですか？

実行できても権限が過剰です。パスワードリセットと次回変更要求は特定OUへ委任できますが、その共通タスクだけでロック解除まで自動委任されたとはみなしません。解除は別に対象OUへスコープしてテスト用ロックアカウントで検証します。失敗時もDomain AdminsやEnterprise Adminsの常用へ切り替えず、委任設定を是正します。

PowerShellのConvertTo-SecureString -AsPlainTextは使えますか？

固定文字列をコマンドへ埋め込むと、SecureStringへ変換する前の平文がスクリプト、履歴、レビュー、ログへ残ります。対話操作ではRead-Host -AsSecureStringを使い、秘密値をコードへ書かない手順にします。

サービスアカウントも同じ方法で戻せますか？

安易に実行しないでください。サービス、タスク、アプリ、同期、SQL接続など複数箇所へ資格情報が保存されている可能性があります。gMSAはOSがパスワードを管理します。所有者、依存関係、停止計画、更新順、ロールバックを定めた専用手順へ分岐します。

古いパスワードへ戻せますか？

管理者は元のパスワードを読み出せず、自動復元もできません。誤リセット時は本人確認後に新しい一時パスワードを再発行します。以前と同じ値は履歴ポリシーで拒否される場合があり、そもそも管理者が知るべきではありません。

KRBTGTのパスワードもこのユーザー向け手順でリセットできますか？

KRBTGTはKerberosの鍵・チケットに関わる特別なアカウントです。一般ユーザーの忘れたパスワードを戻す運用と同じ手順で扱いません。Microsoftのフォレスト回復向けKRBTGTリセット手順では、履歴に保持される二つの値を更新するため二回のリセットと、その間の待機を説明しています。これは通常ユーザーへ二回連続リセットを勧める根拠ではありません。

公式手順の待機は、既定のユーザーチケット・サービスチケットの最大有効期間に対応する10時間で、組織が有効期間を変更していれば、その設定に応じてより長い間隔が必要です。10時間待てば複製や影響確認がすべて完了するという意味でもありません。実施は担当管理者が専用手順、DC間の複製、認証・サービスへの影響を確認して計画します。

同資料は書き込み可能DCを対象としており、RODCに対応するkrbtgt_番号は対象外です。ユーザー向けの次回変更要求やロック解除を、KRBTGTにそのまま適用しないでください。

Microsoft公式資料

• Manage user accounts in Active Directory Users and Computers
• Delegation of control in AD DS
• ADAC Windows PowerShell History Viewer
• Get-ADUser
• Set-ADAccountPassword
• Set-ADUser
• Unlock-ADAccount
• net user
• Fine-grained password policies
• MS-ADTS: PDC Emulator FSMO role

まとめ

ADユーザーのパスワードリセットは、本人確認、対象OUへ限定した委任、秘密値を表示・保存しない操作が基本です。PowerShellではsAMAccountNameから単一の$Userを解決し、すべての変更コマンドへそのADUserオブジェクトを渡します。ADAC履歴、画面共有、録画、コピーをリセット中に使わず、操作後は管理セッションを閉じます。ロック解除はパスワードリセットと別に委任・承認・テストし、認証失敗は書き込みDC、PDC Emulator、クライアントDC、キャッシュ資格情報、再ロックを記録して切り分けてください。