Windows Server 2016 の NPS（Network Policy Server）で RADIUS 認証を運用していると、「パスワードが16文字を超えると失敗する」「RADIUS v2 に切り替えが必要？」という疑問が出がちです。ここでは仕様（RFC）に基づいて誤解を整理し、NPS側の設定有無と、実際に疑うべき原因・切り分け手順をまとめます。
よくある誤解：「RADIUS v2がないと16文字超パスワードは使えない」
結論から言うと、Windows Server 2016 の NPS で「RADIUS v1／v2 を切り替える設定」を探しても、基本的に見つかりません。なぜなら、NPS は RADIUS を RFC 2865（認証）/ RFC 2866（アカウンティング）に基づいて実装しており、仕様上の「16文字制限」を回避するためにプロトコル版を切り替える、という考え方自体がズレているケースが多いからです。
そして、RADIUS の代表的なパスワード格納属性である User-Password は、仕様として 16オクテット単位で分割して処理する前提で定義されています。つまり、16文字（16オクテット）を超えるパスワードも、仕様上は扱えるのが基本です。
Windows Server 2016 NPS の RADIUS は何に準拠しているのか
NPS は、Windows の RADIUS 実装として長く提供されてきた系譜（IAS → NPS）を引き継ぎつつ、RADIUS の標準仕様に基づいて動作します。NPS 管理コンソールで設定できる項目（RADIUS クライアントの登録、共有シークレット、ポート、要求ポリシー、ネットワークポリシー、会計ログなど）を見ても分かる通り、一般的な RADIUS サーバーとしての設定であり、「v1→v2」のようなプロトコル切替を前提にしていません。
もし装置側の UI やマニュアルで「RADIUS V1 / V2」の選択肢が出てくる場合は、ベンダー独自の呼び名、または別物（MS-CHAPv2 など）を指している可能性が高いです。ここを取り違えると、NPS 側で永遠に“存在しない設定”を探し続けることになります。
RADIUSのUser-Password属性は「16オクテット単位」で処理される
「16文字で区切られる」という話の出どころは、RADIUS の User-Password 属性が 16オクテット（16バイト）単位でブロック化されて暗号化（正確には秘匿化）されるという仕様にあります。ここで重要なのは、16オクテット単位に分割する＝16オクテットを超えたら扱えない、ではないという点です。
User-Password は、パスワードを 16オクテット境界にパディングし、16オクテットごとのブロックを順に処理して送る設計です。仕様上は 最大 128オクテット（実装や認証方式にもよる）まで扱えると整理できます。
| 入力したパスワード（例） | 想定オクテット数 | 16オクテットブロック数 | RADIUS（User-Password）の扱い |
|---|---|---|---|
| 8文字（ASCII） | 8 | 1 | 16オクテットにパディングして1ブロックで処理 |
| 16文字（ASCII） | 16 | 1 | ちょうど1ブロックで処理 |
| 17文字（ASCII） | 17 | 2 | 2ブロックに分割して順に処理（仕様上は自然） |
| 40文字（ASCII） | 40 | 3 | 3ブロックに分割して処理 |
| 64文字（ASCII） | 64 | 4 | 4ブロックに分割して処理 |
ポイント：「16文字超で失敗する」のは、仕様が原因というより、“分割して処理するはずなのに、装置側がうまく実装できていない／制限している”ケースが現場では目立ちます。
「文字数」と「オクテット数」は一致しないことがある
RADIUS の仕様は基本的に「オクテット（バイト列）」で定義されます。パスワードに日本語や絵文字、全角記号などマルチバイト文字を混ぜると、見た目の「16文字」でもオクテット数は簡単に 16 を超えます。
- ASCII中心のパスワード：1文字 ≒ 1オクテットになりやすい
- UTF-8 の日本語など：1文字が 3オクテット以上になることが多い
装置によっては「文字数」で制限しているつもりが「バイト数」で制限していたり、その逆だったりします。特に「17文字目から必ず失敗」のように綺麗に境界で落ちる場合は、ブロック処理の実装不備や固定長バッファを疑う価値があります。
「V1/V2」という言い方が生まれる原因（混同ポイントの整理）
現場で飛び交う「V1/V2」は、RADIUS そのもののバージョンではなく、別レイヤの話が混ざっていることが多いです。混同をほどくと切り分けが一気に楽になります。
| よく見る表記 | 実際に指している可能性 | 16文字超パスワードとの関係 | 確認すべき場所 |
|---|---|---|---|
| RADIUS V1 / V2 | ベンダー独自表現（古い仕様RFCを便宜的に区別、または実装差の呼称） | 仕様としてはどちらも「16超NG」ではないことが多い | 装置マニュアル／リリースノート |
| MS-CHAPv1 / MS-CHAPv2 | 認証方式（RADIUSの“中身”として運ばれる） | RADIUSのUser-Passwordとは別経路になりやすい。装置依存の制限は起こり得る | NPSのネットワークポリシー／クライアントの認証設定 |
| PAP / CHAP | 認証方式（PAPはUser-Passwordを使う典型） | PAP周りで実装制限が表に出やすい | NAS（VPN/スイッチ/AP）の認証方式設定 |
| EAP（PEAP / EAP-TLS など） | 802.1X等で使うEAP方式（RADIUSはEAP-Messageを運ぶ） | 「RADIUSの16文字制限」というより、サプリカント/装置のEAP実装側が原因になりやすい | クライアント（PC/スマホ）とNASのEAP設定 |
この表の通り、「RADIUS v2 にしないと長いパスワードが使えない」という話は、認証方式（PAP/CHAP/MS-CHAP/EAP）や装置実装の制約が絡んで発生しているケースが大半です。
16文字超で失敗する場合に疑うべきポイント
RADIUSクライアント（NAS/装置）側の実装・制限
まず疑うべきは、NPS ではなく RADIUS クライアント側（NAS：スイッチ、VPN装置、無線LANコントローラ/AP、FWなど）です。実際、ベンダーのトラブルシューティング情報として「特定条件で RADIUS 認証が通らない」旨が挙げられることがあり、パスワード長や文字種がトリガーになる例もあります。
- 装置のUI入力欄が 16文字まで（見た目の制限）
- 内部で 16バイト固定のバッファに格納し、17文字目以降を破棄（切り捨て）
- User-Password の分割/パディング処理が不完全で、16の倍数以外で失敗
- 文字コード処理が弱く、特定記号やマルチバイトで失敗
- 古いファームウェアの不具合（アップデートで改善することがある）
このパターンに当たると、NPS 側の設定をいくら見直しても改善しません。装置側の仕様・制限を確認し、必要ならファーム更新や設定変更を検討します。
認証方式（PAP/CHAP/MS-CHAP/EAP）の組み合わせ
「どの方式で認証しているか」によって、RADIUS パケットの中身が変わります。特に PAP は User-Password 属性を使う典型で、装置側実装の影響が表に出やすいです。
| 認証方式 | RADIUSで主に使われる属性 | パスワードの扱い | 16文字超トラブルの出やすさ | 実務メモ |
|---|---|---|---|---|
| PAP | User-Password | 16オクテット単位で秘匿化して送信（仕様上は長いパスワードも可） | 装置実装次第で出やすい | 「17文字で落ちる」等はPAP実装をまず疑う |
| CHAP | CHAP-Password など | チャレンジレスポンス系（平文を直接送らない） | 比較的出にくい | 装置のCHAP対応状況・相性が別途ポイント |
| MS-CHAPv2 | MS-CHAP2-Response など | チャレンジレスポンス（Windows系で採用が多い） | 低〜中（装置次第） | VPNやPEAPの内部認証で採用されやすい |
| EAP（PEAP/EAP-TLS等） | EAP-Message | RADIUSはEAP会話を運ぶ（パスワードがUser-Passwordに乗らないことが多い） | 低（ただしEAP実装の相性はあり得る） | Wi-Fi/有線802.1XならEAPの方式選びが重要 |
もし「PAP でだけ長いパスワードが失敗する」「方式を変えたら通る」という状況なら、RADIUSの仕様というより、装置側のPAP周り実装、またはNPSの許可している認証方式（ネットワークポリシー側）が原因である可能性が上がります。
NPS（サーバー）側の設定で“詰まりやすい”ポイント
NPS 側の「RADIUS v1/v2 切替」は原則として議題になりませんが、長いパスワードの問題に見えて、実は NPS の別要因で拒否されているケースはあります。
- ネットワークポリシーで許可していない認証方式をクライアントが使っている
- 接続要求ポリシー／ネットワークポリシーにマッチしていない（想定外のポリシーで拒否）
- ユーザー条件（グループ、時間帯、接続元など）で弾いている
- アカウントロックアウト、期限切れ、ログオン制限など Active Directory 側の要因
この場合、パスワードの長さを変えると「たまたま別条件が変わって見える」こともあるため、ログで事実確認するのが近道です。
切り分け手順：NPS側で「プロトコルの問題ではない」ことを確認する
「16文字超で失敗する」現象を最短で切り分けるには、NPSのログとRADIUSパケットの2点で事実確認するのが有効です。
NPSイベントログで拒否理由を確認する
- NPS サーバーでイベントビューアーを開き、NPS/Network Policy and Access Services 関連のログを確認します。
- 「拒否（Access-Reject）」のイベントを探し、どのポリシーにマッチしたか／拒否理由が何かを確認します。
- 同じユーザーで「短いパスワード」と「長いパスワード」を試し、ログ上の違い（拒否理由、適用ポリシー）を比較します。
ログで「資格情報不一致」のように見える場合でも、装置側でパスワードが切り捨てられていれば、NPS から見ると “間違ったパスワードが来た” のと同じに見えます。ログは「NPSが何を受け取ったか」を推測する手掛かりになります。
Wireshark等でRADIUSパケットを見て「切り捨て」や「属性」を確認する
可能なら NPS サーバー側でパケットキャプチャを取り、Access-Request に何が載っているかを確認します。フィルタ例は以下の通りです。
udp.port == 1812 or udp.port == 1813 or udp.port == 1645 or udp.port == 1646- PAP の場合：Access-Request に User-Password が載ることが多い
- EAP の場合：Access-Request に EAP-Message が載る
- MS-CHAPv2 の場合：MS-CHAP 系の属性が載る
ここで「長いはずのパスワードが 16 で切れていそう」「装置が想定外の方式で投げている」などが分かれば、原因はかなり絞れます。逆に、NPS に到達する時点で正しくリクエストが組み立てられているなら、次は NPS ポリシーや AD 条件を疑う、という順番になります。
症状別：現場で多い原因と対処のパターン
| 症状 | 疑うべき原因 | まずやる確認 | 対処例 |
|---|---|---|---|
| 16文字までは成功、17文字から必ず失敗 | NAS側が16バイトで切り捨て／ブロック処理の実装不備 | NPSログの拒否理由比較、RADIUSパケットで属性確認 | 装置のファーム更新、認証方式変更（PAP→MS-CHAPv2/EAP）、ベンダーに制限確認 |
| 短い・長いに関係なく時々失敗 | 共有シークレット不整合、通信経路の問題、重複クライアント設定 | RADIUSクライアント定義、共有シークレット、疎通（UDP/1812） | 設定統一、冗長経路の見直し、NAT/ACL確認 |
| ASCIIだけ成功、記号や日本語を含むと失敗 | 文字コード処理、入力検証、装置のUI制限 | 同じ長さで文字種だけ変えて再現確認 | パスワードポリシーをASCII中心に寄せる／装置更新／別方式（証明書）へ移行 |
| PAPだと失敗、別方式だと成功 | PAP実装の制約、ポリシーでの方式許可の不一致 | NAS側の方式、NPSネットワークポリシーの認証方式許可 | PAPを避ける（可能ならPEAP/MS-CHAPv2/EAP-TLS） |
| 特定ユーザーだけ長いパスワードで失敗 | AD側の制限（ロックアウト/期限/ログオン制限）、グループ条件 | NPSログのユーザー条件、ADの状態 | アカウント状態の是正、ポリシー条件の見直し |
どうしても装置側に制限がある場合の現実的な選択肢
装置側が「16文字超は非対応」などの明確な制限を持つ場合、NPS側で魔法のように解決するのは難しいことがあります。その場合は、次の順番で“現実解”を検討すると収まりが良いです。
まずは装置のアップデートと設定見直し
- ファームウェア／OS／ソフトウェアのアップデート（同一症状の修正が入っていることがある）
- 認証方式の再選定（PAPを避ける、EAP系に寄せる、装置が得意な方式に合わせる）
- パスワード入力欄やCLIの制限（UI上の最大長）を再確認する
方式を変えて「パスワードをRADIUSのUser-Passwordに載せない」方向へ
Wi-Fi/有線 802.1X の文脈なら、PEAP（内部でMS-CHAPv2）や EAP-TLS（クライアント証明書）など、設計として強度を上げやすい選択肢があります。特に EAP-TLS は「長いパスワードを通す」発想から一段離れて、証明書での相互認証へ寄せられるため、装置のパスワード長制限の影響を受けにくくなります。
暫定的にパスワード長ポリシーを調整する（ただし条件付き）
どうしても短期的な復旧が優先で、装置交換や方式変更のリードタイムが取れない場合、限定的に「対象ユーザー/対象用途だけ」パスワードポリシーを緩める判断が出ることもあります。ただし、これは本来のセキュリティ方針と衝突しやすいので、以下のように“条件付き”で運用リスクを下げる工夫が必要です。
- 対象範囲を最小化（特定装置向けアカウント、特定グループのみ）
- 利用経路を限定（VPNのみ、特定SSIDのみ等）
- 監査ログを強化（NPSの会計ログ、ADの監査）
- 移行期限を決め、恒久対策（方式変更/装置更新）へ繋げる
運用のヒント：長いパスワードを通すだけで終わらせない
「16文字超を使いたい」という相談の背景には、たいてい「推測されにくい強い認証にしたい」という目的があります。目的がそこなら、次の観点も一緒に検討すると、将来的な設計が崩れにくくなります。
- “長さ”だけでなく運用全体の強度（MFA、端末証明書、条件付きアクセス、監査）
- 装置依存の少ない方式（EAP-TLS、ベンダーの推奨構成）
- RADIUSの特性（UDP、共有シークレット、装置の実装差）を踏まえた設計
結果として「RADIUS v2 が必要」という方向ではなく、装置の制約を踏まえた認証方式の選択と切り分け可能なログ設計に落とし込むのが、現場で最も再現性の高い解決パターンになります。
コメント