在宅勤務でドメイン参加していないPC（ドメイン外PC）からVPN接続していると、Active Directory（AD）のパスワードが期限切れになった瞬間に「VPNに入れない」「ドメインユーザーが自分でパスワード変更できない」といったトラブルが起きがちです。本記事では、NPS（RADIUS）＋EAP-MSCHAPv2環境で期限切れ後でもVPN認証の流れの中でパスワード変更を成立させる定番設定と、代替策・運用のコツを具体的に解説します。
よくある症状：期限切れが“VPNに入れない”に直結する
ドメイン参加していない端末（BYODや検証端末など）で業務VPNを使う場合、普段は問題なく接続できていても、ADのパスワード期限切れを境に突然詰まることがあります。特に「VPN接続の認証＝ドメイン資格情報（ユーザー名・パスワード）」という構成では、パスワード変更のために社内ネットワークへ入る必要があるのに、社内へ入るためのVPN認証が通らない、という“鶏と卵”状態になります。
| 現象 | ユーザー側で見えること | 典型的な原因 |
|---|---|---|
| パスワード期限切れ後、VPN接続が即失敗 | 「資格情報が正しくありません」「認証に失敗しました」などで接続不可 | NPS/RADIUSが期限切れパスワードを拒否し、変更フローに入れない |
| VPNには入れるが、パスワード変更がローカルに向く | Ctrl+Alt+Del の「パスワードの変更」でローカルユーザー変更しか出ない | 端末がドメイン非参加のため、Windowsの標準UIがドメイン変更として扱わない |
| 期限切れを知らせる警告が届かず、突然切れる | ある日いきなり入れなくなる | 警告表示が出るのは“ドメインに接続しているとき”が前提になりやすい |
なぜ「ドメイン非参加端末」だとパスワード変更が難しいのか
ドメイン参加端末であれば、WindowsのログオンやCtrl+Alt+Delの操作がADのパスワード変更と自然に結びつきます。一方でドメイン非参加端末では、そもそもOSとして“ドメインアカウントでサインインしている状態”ではありません。さらに、VPN接続前はドメインコントローラーへ到達できないため、期限切れ（または「次回ログオン時に変更」）のタイミングで必要になるパスワード変更処理を実行できません。
この問題をきれいに解く鍵は、「VPN認証のプロトコル自体に、期限切れ後のパスワード変更を許可する仕組みがあるか」と「RADIUSサーバー（NPS）がその仕組みを許可しているか」です。
結論：NPS（RADIUS）＋EAP-MSCHAPv2なら“期限切れ後の変更許可”が王道
VPNの認証が EAP-MSCHAPv2（多くはPEAPの内側でMSCHAPv2を使う構成）で、RADIUSサーバーに Windows NPS（Network Policy Server） を使っているなら、NPS側のネットワークポリシー設定で「期限切れ後のパスワード変更」を許可するのが定番です。
| 項目 | 推奨（本記事の前提） | 補足 |
|---|---|---|
| RADIUSサーバー | NPS | ドメイン参加し、ADでユーザー認証できる構成 |
| 認証方式 | PEAP（EAP-MSCHAPv2） | “中身がMSCHAPv2”であることが重要 |
| クライアント | Windows標準VPNクライアント | クライアント実装により動作が異なる場合あり |
NPSで有効化すべき設定
NPSの「ネットワーク ポリシー」→「EAP MSCHAPv2 のプロパティ」で、次のチェックを有効化します。
「パスワードが期限切れになった後にクライアントがパスワードを変更できるようにする（Allow client to change password after it has expired）」
これを有効にすると、期限切れのアカウントでVPN接続を試みた際に、クライアント側が“パスワード変更を伴う認証フロー”へ移行でき、結果としてVPN接続の流れの中で新しいパスワードへ更新できる可能性が高まります。逆に無効だと、期限切れの時点で認証が拒否され、VPNに入れずパスワード変更もできない状態になりがちです。
設定手順：NPSのネットワークポリシーで許可を入れる
ここでは、NPSでRADIUS認証を行っている一般的な構成（VPN装置/Windows RRAS → NPS → AD）を想定して手順を整理します。画面構成はWindows Serverのバージョンで多少異なりますが、項目名は概ね同じです。
手順の全体像
- NPSで対象のネットワークポリシー（VPN用）を特定する
- ポリシーの「制約」からEAP（PEAP）を開く
- EAP-MSCHAPv2の設定を開き、「期限切れ後の変更許可」をオンにする
- 実際に期限切れユーザーでテストし、変更→接続が成立することを確認する
具体的な操作ポイント
- NPSコンソール を開きます（nps.msc）。
- ポリシー → ネットワーク ポリシー を開き、VPN接続に適用されるポリシーを選びます。
- ポリシーのプロパティで 制約（Constraints）→ 認証方法（Authentication Methods）を確認します。
- 一覧に Microsoft: 保護された EAP (PEAP) があり、それが有効になっていることを確認して 編集 します。
- PEAPの中で使用するEAPタイプとして EAP-MSCHAP v2 を選び、プロパティ（または構成）を開きます。
- 「パスワードが期限切れになった後にクライアントがパスワードを変更できるようにする」にチェックを入れて保存します。
前提確認：VPN装置（またはRRAS）とNPSの“認証方式”を揃える
NPS側にチェックを入れても、VPN側が別方式で認証していると当然ながら効果が出ません。まずは「どこで」「何の方式で」認証しているかを言語化できる状態にしておくと、設定変更が最短で済みます。
| 確認ポイント | 見る場所 | 目安 |
|---|---|---|
| VPN側がRADIUSを使っているか | VPN装置/RRASの認証設定 | RADIUSサーバーがNPSになっている |
| RADIUSでEAPを使っているか | VPN装置/RRASのEAP設定 | PEAP/EAP-MSCHAPv2が選択されている |
| NPSのネットワークポリシーが一致しているか | NPSのネットワークポリシー条件 | NAS-Port-TypeやRADIUSクライアント名などで想定どおりにマッチ |
特に複数拠点・複数VPN装置がある環境では、RADIUSクライアント（接続元機器）ごとにポリシーを分けていることも多いです。「どの装置から来た接続が、どのポリシーにマッチしているか」をNPSログで確認しながら進めるのが確実です。
もしネットワークポリシーが複数ある場合は、「どの条件のときにどのポリシーが当たるか」を整理してください。パスワード期限切れのユーザーが別ポリシー（たとえば拒否ポリシー）にマッチしていると、チェックを入れても効果が出ません。
動作確認：ユーザー体験はどう変わる？
設定が効いている場合、期限切れ状態でVPN接続を行うと、Windows標準クライアントでは“新しいパスワード入力”を促すダイアログが出たり、認証エラーのあとに変更フローへ誘導されたりします（表示は環境・OSビルド・接続方式により差があります）。重要なのは、期限切れでもVPNの認証フローが継続し、結果としてパスワード更新が成立することです。
| チェック項目 | 期待される結果 | うまくいかない場合の見直し |
|---|---|---|
| NPS側の設定 | 期限切れ後の変更許可がオン | 別ポリシーが適用されていないか、PEAPの内側が本当にMSCHAPv2か |
| クライアント側の挙動 | 新パスワード入力を促す、または変更後に接続成功 | 別のVPNクライアントを使っていないか、資格情報が保存されていないか |
| ログの確認 | NPSイベントで成功（許可）として記録される | 拒否理由コード、ユーザー状態（ロック/無効）を確認 |
ユーザー向け：期限切れになったときの操作手順（配布用テンプレ）
ヘルプデスク対応を減らすには、ユーザーが迷わず復旧できる“短い手順”を社内ナレッジに固定化するのが効果的です。Windows標準VPNクライアントを前提に、案内文のたたき台を載せます。
| 手順 | やること | 補足 |
|---|---|---|
| VPN接続を開始 | いつもどおりVPN接続を実行する | 期限切れでも、変更許可が有効なら途中で案内が出ることがある |
| 期限切れの案内が出たら | 新しいパスワードの入力を求められたら、その場で更新する | 新パスワードは社内ポリシー（長さ/複雑性/履歴）を満たす必要がある |
| 更新後 | 再度VPN接続を試し、接続できることを確認する | 保存済み資格情報が残っていると、古いPWで再試行して失敗することがある |
| うまくいかない場合 | 一度VPNの資格情報保存を削除し、再入力する | 次の「資格情報の消し方」を参照 |
保存済み資格情報が原因で失敗するときの対処
WindowsはVPNのユーザー名/パスワードを保存できます。期限切れ後にパスワードを更新できても、保存情報が古いままだと“毎回同じ失敗”を繰り返します。次の場所を確認してください。
- 設定 → ネットワークとインターネット → VPN：接続設定の編集で、保存済み情報の見直し
- 資格情報マネージャー（コントロールパネル）：Windows資格情報にVPN名やサーバー名に紐づく資格情報があれば削除
ユーザー名の形式も意外な落とし穴です。たとえば DOMAIN\ユーザー名 と ユーザー名@ドメイン のどちらを想定しているか、VPNプロファイルの説明欄などに明記しておくと混乱が減ります。
NPSログで見るべきポイント
原因切り分けを早くするために、NPSのイベントログ（Event Viewer → Custom Views → Server Roles → Network Policy and Access Services など）を確認します。拒否されている場合は、拒否理由や認証方法、適用されたネットワークポリシー名が手がかりになります。
うまくいかないときに疑うべき“ハマりどころ”
EAP-MSCHAPv2ではない（またはPEAPの内側が違う）
もっとも多い見落としは、VPNの認証方式が想定と違うケースです。たとえばEAP-TLS（証明書認証）ではパスワード変更という概念自体がありませんし、PAP/CHAP系は期限切れ後の変更フローに対応しないことが一般的です。
| 認証方式 | 期限切れ後の変更フロー | コメント |
|---|---|---|
| PEAP（EAP-MSCHAPv2） | 対応しやすい（NPS設定が重要） | 本記事の主題 |
| EAP-TLS（証明書） | 対象外 | パスワードではなく証明書で認証する |
| PAP/CHAP/MS-CHAPv1 | 非推奨/未対応が多い | セキュリティ面でも見直し対象になりやすい |
クライアントが“期限切れパスワード変更”に非対応
Windows標準VPNクライアントでは動く例が多い一方、サードパーティVPNクライアントやOSの種類によっては、期限切れ後の変更フロー（MSCHAPv2のパスワード変更）を実装していないことがあります。その場合、NPS側で許可してもクライアントが変更要求を出せず、結果として接続失敗のままになります。
業務でさまざまな端末を許容する場合は、「どのOS/クライアントなら期限切れから復旧できるか」を事前に検証し、ユーザー向けの手順に落とし込むのがおすすめです。
ユーザーがロックアウト/無効/パスワードポリシー違反
期限切れとは別に、ロックアウトや無効化、または新しいパスワードがポリシー（長さ、履歴、複雑性）を満たしていない場合、変更フローは失敗します。ユーザーから見ると“同じくVPNに入れない”ため、ヘルプデスクが判断できるようにチェックリストを持っておくとスムーズです。
代替案：NPS以外でパスワードを変えるルートを用意する
NPSでの期限切れ後変更がもっとも筋が良い一方、環境要件が合わない・クライアントが対応していない・別認証方式に移行したい、といった事情もあります。その場合は「VPNに入る前/入った後に、確実にパスワード変更できる導線」を別途用意します。
| 手段 | 使えるタイミング | メリット | 注意点 |
|---|---|---|---|
| RDWeb（RDS）のパスワード変更ページ | VPN接続後（または公開できる場合はVPN前） | ブラウザだけで変更でき、端末のドメイン参加に依存しにくい | RDS/RDWebの運用・公開範囲の設計が必要 |
| Exchange/OWAの変更機能 | メールへアクセスできる環境なら | ユーザーにとって分かりやすい | Exchange未導入の環境では使えない |
| SSPR（セルフサービス）ポータル | VPN前でも可能に設計できる | 期限切れ・失念の両方に強い | 本人確認（MFA/登録情報）の設計が肝 |
| ヘルプデスクによる一時パスワード発行 | いつでも | 最終手段として確実 | 工数が増えやすい、本人確認とログが必須 |
RDWeb（RDS）がある場合の実務的な運用
RDS（Remote Desktop Services）を運用している組織では、RDWebにパスワード変更用のページが用意されていることがあります。VPN接続後にそのページへ誘導するだけでも、ドメイン非参加端末の“UI問題”を回避できます。運用としては、社内ポータルやナレッジに「パスワード期限切れのときはRDWebで変更→再接続」という導線を明記しておくと問い合わせが減ります。
キャッシュ資格情報でログオン→VPN→変更、が使えるケース
ドメイン参加端末であれば「キャッシュされた資格情報でWindowsにログオン」→「VPN接続」→「Ctrl+Alt+Delでドメインパスワード変更」→「端末をロックして新PWで解除」という手順が成立することがあります。ただし本記事の前提であるドメイン非参加端末では、Ctrl+Alt+Delの変更先がローカルに寄りやすく、万能ではありません。
オンスクリーンキーボード（osk）でCtrl+Alt+Delを送る方法について
一部の環境では、オンスクリーンキーボード（osk）からCtrl+Alt+Del相当を送って「パスワードの変更」画面に入れる手順が有効だったという報告もあります。しかし、ドメイン非参加端末やVPN方式によっては同じ画面に入れても結局ローカル変更になり、根本解決にならないことがあります。ナレッジとして紹介する場合は、“効く環境もあるが再現性は高くない”と明記するのが安全です。
運用で効く対策：期限切れ“前”に気づかせる
技術的な解決に加えて、運用側で“期限切れに到達させない”工夫も重要です。特に在宅勤務・外部端末を許容している環境では、ユーザーが社内に接続する頻度が下がり、期限警告を見逃しやすくなります。
期限切れ警告日数を増やす
ADのパスワードポリシー（最大パスワード有効期間）自体を緩めるのではなく、まずは「期限が近いことを早めに通知する」設計が現実的です。社内端末に対してはグループポリシーで警告日数を調整したり、ログオン時のスクリプトでメッセージを出したりできます。
“期限が近いユーザー”へ通知する（例：PowerShell）
ドメイン側で期限を計算し、メールやTeams通知などでリマインドする運用を作ると、VPNが切れてからの問い合わせが目に見えて減ります。以下は概念例です（実環境では権限・宛先・例外ユーザーなどを設計してください）。
# 概念例：期限が近いユーザーを抽出（実運用ではOUやグループで絞り込み推奨）
Import-Module ActiveDirectory
$days = 10
$limit = (Get-Date).AddDays($days)
Get-ADUser -Filter * -Properties "msDS-UserPasswordExpiryTimeComputed","mail" |
Where-Object { $_."msDS-UserPasswordExpiryTimeComputed" -and
([datetime]::FromFileTime($_."msDS-UserPasswordExpiryTimeComputed")) -lt $limit } |
Select-Object SamAccountName, mail,
@{Name="Expiry";Expression={[datetime]::FromFileTime($_."msDS-UserPasswordExpiryTimeComputed")}} |
Sort-Object Expiry通知方法はメールに限らず、社内ポータル、ヘルプデスクの自動チケット作成、チャット通知など、組織文化に合わせて選べます。ポイントは「期限前に、ユーザーが一度VPNに入って変更できるタイミングを確保する」ことです。
セキュリティ観点の注意：EAP-MSCHAPv2を“使い続ける”前提での守り方
EAP-MSCHAPv2は互換性が高く、既存環境で採用されがちです。一方で、設計によっては認証情報を狙われるリスクや、古い暗号スイートが残るリスクが指摘されます。ここで重要なのは、「PEAP（TLSトンネル）の設定を適切にする」「証明書・暗号・サーバー名検証を徹底する」「可能なら多要素認証へ段階的に移行する」という現実的な落とし所です。
- PEAPで使用するサーバー証明書を適切に管理し、クライアント側でサーバー検証（サーバー名/CA）を有効にする
- 古いTLS/暗号スイートを排除し、OS・NPS・VPN装置の更新を計画する
- 将来的にEAP-TLS（証明書）＋MFA、またはID基盤連携など、より強い方式へ移行できる余地を残す
- NPSの監査ログ（成功/失敗）を収集し、異常な試行回数や国/地域の偏りを監視する
まとめ：まずはNPSの“期限切れ後変更許可”を入れて詰まりを解消する
ドメイン非参加端末からVPN接続していると、ADパスワードの期限切れは想像以上に業務停止へ直結します。NPS（RADIUS）でPEAP（EAP-MSCHAPv2）を使っているなら、ネットワークポリシーのEAP-MSCHAPv2設定で「期限切れ後のパスワード変更を許可」を有効化するのが、最小変更で効果が大きい対策です。
それでも端末やクライアントの都合で難しい場合は、RDWeb/SSPRなど別経路のパスワード変更導線を用意し、さらに期限前通知の運用で“詰む前に直す”体制を作ると安定します。
コメント