企業ネットワークの安全を確保するためには多層的な認証が欠かせません。特にNPS（Network Policy Server）を活用した802.1x認証とAzure MFAを連携させることで、高度なセキュリティを実現できますが、その一方で「DS_CONVERSION_ERROR」というエラーに直面し、認証フローが止まってしまうケースもあります。
NPS + 802.1x + Azure MFA での DS_CONVERSION_ERROR とは
NPSとAzure MFAを連携して802.1x認証を行う際に、イベントログやNPSログ上で「DS_CONVERSION_ERROR」というメッセージが表示され、最終的に認証が拒否される事象です。特にコンピューターアカウント（host/{FQDN}）でのマシン認証を実施しようとした際に、Azure MFAとの連携でユーザーアカウントが解決できずにエラーとなるケースが報告されています。
よく見られるエラーメッセージ
- No mapping between account names and security IDs was done.
- User not found in on-premises Active Directory
- DS_CONVERSION_ERROR
こうしたメッセージが示すとおり、Active Directory上でアカウントやSIDが正しく対応付けできず、NPS拡張（Azure MFA）側で処理が停止している可能性が高いのが特徴です。
802.1x コンピューター認証におけるトラブルの背景
ユーザー認証とマシン認証の違い
通常、Azure MFAはユーザーの多要素認証を主眼にした仕組みとなっています。802.1x環境では大きく分けて以下の2種類の認証パターンがあります。
- ユーザー認証: ユーザーアカウントを使ったログイン（PEAPまたはEAP-TLS）
- コンピューター認証: host/{FQDN} などのコンピューターアカウントを使ったログイン（PEAP-TLSなど）
後者のコンピューター認証でAzure MFAを組み合わせると、アカウントの解決がスムーズにいかずにエラーが発生しやすいことが知られています。
二要素認証のフローが阻害される理由
Azure MFAのNPS Extensionは、NPSの認証結果が「AccessAccept」である場合にのみ、多要素認証を実行するトリガーとなります。しかしコンピューター認証の場合、EAPの段階でNPSから「AccessChallenge」が返ることが多く、その状態ではAzure MFA Extensionは動作せず、結果的に認証が失敗する流れになりがちです。
DS_CONVERSION_ERROR が発生する原因と対処策
下記のような原因でDS_CONVERSION_ERRORが発生しやすく、対処も原因ごとに異なります。
原因1: Active Directory 上のアカウント情報の不整合
- コンピューターアカウントのUPNやSIDが誤っている
- AD上でアカウントが無効化されている、または重複している
このような状態だと、NPSが正しくアカウントを解決できず、Azure MFA Extensionが「ユーザーを特定できない」と判断してDS_CONVERSION_ERRORに至ります。以下の手順で対処を行います。
- コンピューター名とUPNを照合
Active Directoryユーザーとコンピューターの管理画面でhost/{FQDN}が正しいか確認します。 - SIDの一致を確認
コマンドプロンプトなどでwhoami /userを実行し、表示されるSIDとActive Directory上のコンピューターアカウントのSIDが一致しているか確認します。 - アカウントの有効化状態を確認
コンプライアンスや組織変更などで無効化されている可能性がないかをチェックします。
原因2: マシン認証時にAzure MFAが想定していない認証フロー
Azure MFAはユーザーの多要素認証を想定して設計されているため、host/{FQDN}形式のマシンアカウントでの多要素認証フローはサポート外、もしくは動作が保証されていないケースが多いです。これが理由で認証フローが中断され、DS_CONVERSION_ERRORに直結します。
- 対策
- マシン認証とユーザー認証用のNPSサーバーを分ける
- マシン認証にはAzure MFAをかけず、ユーザー認証時のみAzure MFAを適用
原因3: NPSポリシーやレジストリ設定の競合
NPSはポリシーが複数重なる構成も可能であり、細かい条件指定をするほど競合や優先順位の問題が発生しがちです。また、AzureMfa NPS Extensionのレジストリ設定（IPホワイトリストなど）によって意図せず認証の可否が変わることもあります。
- 対策例
- NPSのポリシー順序を見直す
特に「接続要求ポリシー」と「ネットワークポリシー」の設定が複雑になっていないか確認します。 - IPホワイトリストによる一時的なMFAスキップ
HKLM\SOFTWARE\Microsoft\AzureMfa下のIP_WHITELISTにスイッチやAPなどのRADIUSクライアントのIPを追加して、MFA要求が発生しないようにする方法があります。
Azure MFA とコンピューター認証を連携するうえでの注意点
運用上のリスクとメリット
コンピューター認証とAzure MFAを連携すること自体、あまり一般的ではありません。その理由は、マシンアカウントにはユーザーのように追加のアプリ通知などを受け取る術がないため、多要素認証の利点を十分に活用できないことにあります。運用上の複雑さを増すだけでなく、サポート外となるリスクが高い点も考慮しましょう。
Microsoft公式ドキュメントの確認
Azure MFAのNPS Extensionのリリースノートや公式ガイドを確認すると、ユーザーアカウントでのRADIUS認証を中心に設計されている旨の記載があります。コンピューター認証への対応は限定的なので、最新のドキュメントと互換性情報を必ずチェックしましょう。
NPS構成における分割のベストプラクティス
NPSサーバーを分割する理由
複雑なポリシー構成と競合を避けるため、以下のようにサーバーを分割するのが一般的なベストプラクティスです。
- マシン認証専用のNPSサーバー
- 802.1xにおけるコンピューター認証をハンドリング
- Azure MFAのNPS Extensionはインストールしない
- ユーザー認証専用のNPSサーバー
- VPNやリモートデスクトップゲートウェイなどのユーザー認証をハンドリング
- Azure MFAのNPS Extensionを導入し、ユーザー認証に多要素を適用
これにより、マシン認証でのDS_CONVERSION_ERRORを含む様々なエラーを回避できる可能性が大幅に向上します。
運用事例
- 大規模企業A社: 部署ごとにNPSを分割し、マシン認証用NPSにはAzure MFAを導入しない。ユーザー認証専用NPSにはAzure MFAを導入して、VPNやリモートアクセスで安全性を確保。
- 中規模企業B社: NPSサーバー2台構成。クライアント端末が認証する先（802.1x）とユーザーVPN認証先を明確に分けることで運用トラブルをほぼ解消。
IPホワイトリストによる一時的な回避策
設定例
下記はIPホワイトリスト設定のためのレジストリキー例です。レジストリエディタを使う際は、必ず事前にバックアップをとってください。
レジストリパス: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureMfa
キー名: IP_WHITELIST
値の種類: REG_MULTI_SZ
値の内容:
192.168.0.10
192.168.0.11
10.0.0.5複数のRADIUSクライアントIPアドレスを指定することで、そのIP経由の認証要求に対してAzure MFAがスキップされます。ただし、これはあくまで一時的な措置であり、ホワイトリストに登録された範囲で多要素認証が実行されないため、セキュリティ要件を満たせない場合がある点に注意が必要です。
実践例: DS_CONVERSION_ERROR対策のフロー
以下は、DS_CONVERSION_ERRORが発生した際に推奨される対処フローを表にまとめたものです。
| ステップ | 内容 | 実施のポイント |
|---|---|---|
| 1. ログ確認 | Event ViewerやNPSログでエラー詳細を確認 | 「No mapping between account names…」などのエラーを特定 |
| 2. AD情報の整合性チェック | コンピューターアカウントのUPNやSIDを確認 | host/{FQDN}形式が正しいか、アカウントが無効化されていないか |
| 3. NPSポリシー確認 | RADIUSクライアント設定、条件一致を確認 | 複数ポリシーの優先順位や条件重複に注意 |
| 4. Azure MFA Extension設定確認 | レジストリ (IP_WHITELIST など) やAzureポータル側の設定をチェック | 誤ってMFAが適用される/適用されない範囲を確認 |
| 5. 検証環境でテスト | NPSサーバー分割やホワイトリスト設定などの変更をテスト環境で試行 | 本番環境適用前に十分な検証を行う |
| 6. 本番環境に適用 | 段階的に設定を反映し、再度ログをモニタリング | 不具合があればロールバックを素早く行えるように手順を用意 |
NPSやAzure MFAに関する追加のベストプラクティス
証明書の管理
802.1x（PEAP-TLS、EAP-TLSなど）では、クライアント側とサーバー側の証明書が必須となります。証明書の有効期限切れやCAのルート証明書トラストチェーンの不備は、認証エラーの原因になりやすいです。定期的な証明書の更新スケジュールを設定しておきましょう。
ログの一元管理
NPSやAzure MFA Extensionは、Windowsイベントログ、NPSログ、Azureポータル側の認証ログなど、複数のログソースが存在します。これらをSIEM（Security Information and Event Management）などで一元管理すると、問題発生時のトラブルシュートが大幅に効率化されます。
まとめ
- DS_CONVERSION_ERRORは主にActive DirectoryとAzure MFAの間でコンピューターアカウントが適切に解決できない場合に発生します。
- コンピューター認証とAzure MFAの連携は公式にサポートが限定的であり、運用上のメリットが少ないケースが多いです。
- NPSサーバーを「マシン認証用」と「ユーザー認証用」に分割する構成が一般的なベストプラクティスとなり、複雑なトラブルの回避に繋がります。
- IPホワイトリストを使った一時的な回避策は存在しますが、根本的な解決策としてはNPSポリシーの見直しやサーバー分割が望まれます。
- 802.1x認証では証明書とポリシーが要となるため、運用時の証明書管理とログ分析を徹底し、セキュリティと可用性のバランスを保ちましょう。
コメント