Windows Server 2012 R2 の AD FS 3.0 を SAML 2.0 IdP として Duo Network Gateway に連携すると、”パスワード認証（フォーム認証）が必要” と言われたり、SAML で NoAuthnContext が出て先に進めないことがあります。原因と、実際に動いた設定、外部公開できない場合の落とし穴まで整理します。
前提：今回の構成と用語をそろえる
まずは「どこで認証していて、どこで詰まっているか」を同じ言葉で整理します。AD FS 側の設定に手を入れる前に、この対応関係を押さえておくとログも読みやすくなります。
| 要素 | 役割 | 今回の例 | AD FS 管理画面での呼び方 |
|---|---|---|---|
| IdP | ユーザーを認証して SAML 応答を返す | AD FS 3.0（Windows Server 2012 R2） | AD FS |
| SP / RP | IdP に認証を依頼してアプリにログインさせる | Duo Network Gateway | Relying Party Trust（証明書利用者の信頼） |
| 認証方式 | ユーザーがどの方法で本人確認されるか | フォーム認証／Windows 統合認証など | Authentication Policies（認証ポリシー） |
| 認可 | その RP に対してトークンを発行してよいか | ユーザー／グループの許可ルール | Issuance Authorization Rules（発行承認規則） |
起きている現象：Duo が動かない／ログに NoAuthnContext が出る
ハマりやすいのは、Duo 側の設定というより AD FS 側の「ユーザー向け設定（認証・認可）」が整っていないケースです。見た目は「Duo Network Gateway が動かない」でも、実際には AD FS が要求された認証コンテキストを満たせず、SAML のエラーを返しています。
ログやレスポンスに出がちな代表例が次です。
urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext| 症状 | ありがちな原因 | 最初に見るべき場所 |
|---|---|---|
| NoAuthnContext が返る | 要求された AuthnContext（例：PasswordProtectedTransport）を AD FS が満たせない | AD FS/Admin ログ、Authentication Policies |
| 認証画面にすら到達しない／ループする | RP へのアクセスが許可されていない（発行承認規則で拒否） | Relying Party Trust の Issuance Authorization Rules |
| 社内では動くが社外で動かない | IdP（AD FS）にブラウザから到達できない（外部公開要件の欠落） | DNS/証明書/公開経路（WAP・リバースプロキシ等） |
なぜ「パスワード認証（フォーム認証）が必要」と言われるのか
SAML では、単に「認証できたか」だけでなく、「どの種類の認証で本人確認したか」を AuthnContext として扱うことがあります。SP 側（Duo Network Gateway）が AuthnRequest で特定の AuthnContext を要求すると、IdP 側（AD FS）はそれを満たせない場合に NoAuthnContext を返します。
AD FS 3.0 は環境によって次のように振る舞います。
- 社内（イントラネット）でドメイン参加済み端末＋対応ブラウザの場合、Windows 統合認証（Kerberos/NTLM）で「パスワード入力なし」に進むことが多い
- 一方、SP が「パスワード入力を伴う認証」を期待していると、統合認証では要件を満たせず NoAuthnContext になり得る
- フォーム認証を許可すると、少なくとも「ID とパスワードを入力して認証する」経路を AD FS 側で選べるようになる
| ユーザーが体験する画面 | AD FS の認証方式（例） | SAML 的に期待されやすい扱い | SP 側の要求と衝突しやすいポイント |
|---|---|---|---|
| ドメイン参加端末で自動ログイン | Windows 統合認証（WIA） | Kerberos/NTLM 相当のコンテキスト | 「パスワード認証」を明示要求されると不一致になることがある |
| ユーザー名・パスワード入力画面が出る | フォーム認証（Forms Authentication） | PasswordProtectedTransport 相当が期待されやすい | フォーム認証が無効だと選択肢がなくなる |
つまり「Duo 連携が特殊」というより、AD FS 側が提示できる認証方式の選択肢が足りない／許可されていないことが本質になりがちです。
実際に動いた対処：AD FS 側の設定を 2 点そろえる
ポイントは次の 2 点です。片方だけだと「ログイン画面は出るが発行できない」「発行はできるが認証方式が合わない」といった別の詰まり方をします。
| 対処 | 狙い | 効果が出る代表的な症状 |
|---|---|---|
| イントラネットユーザーにフォーム認証を許可 | 「パスワード入力による認証」を AD FS が選択できる状態にする | NoAuthnContext、統合認証で要件を満たせない |
| Relying Party Trust に必要ユーザーのアクセスを許可 | 認証後に SAML トークンを発行できる状態にする | リダイレクトループ、トークン発行拒否 |
イントラネット（社内）ユーザーにフォーム認証を許可する
AD FS 3.0（Windows Server 2012 R2）では、社内向け（Intranet）と社外向け（Extranet）で許可する一次認証方式を分けて設定します。ここで Intranet にフォーム認証が許可されていないと、社内からのアクセスでフォーム認証に切り替えられず、SP が期待するコンテキストに到達しないことがあります。
GUI での確認・設定手順（例）
- 「AD FS 管理」(AD FS Management) を開く
- 左ペインで「認証ポリシー」(Authentication Policies) を開く
- 「一次認証」(Primary Authentication) の Intranet にて「フォーム認証」(Forms Authentication) を許可する
- 社外利用がある場合は Extranet 側も同様に見直す（WAP/プロキシ経由は Extranet 扱いになることが多い）
運用での落とし穴
- Intranet にフォーム認証を追加しても、ドメイン参加済み端末では従来どおり統合認証が優先されることがあります（「フォームを許可」＝「必ずフォームになる」ではありません）。
- Duo 側の要件が厳しく「必ずパスワード入力にしたい」切り分けでは、検証用に一時的に Windows 統合認証を外して挙動を確認すると原因が見えやすくなります（本番適用は影響範囲を十分確認）。
PowerShell で状態を可視化する例（GUI と合わせて「今どうなっているか」を確認するのに便利です）
Get-AdfsGlobalAuthenticationPolicy出力で Intranet/Extranet の一次認証プロバイダーを確認し、フォーム認証が候補に入っているかを見ます。
Relying Party Trust に対してユーザーのアクセスを許可する
認証方式が整っても、Relying Party Trust 側で「この RP にはトークンを発行してよい」という許可が出ていないと、最終的にトークン発行が拒否されます。AD FS 3.0 ではこの制御が Issuance Authorization Rules（発行承認規則） にまとまっています。
GUI での確認・設定手順（例）
- 「AD FS 管理」→「信頼関係」→「証明書利用者の信頼」(Relying Party Trusts)
- Duo Network Gateway 用に作成した RP を選択し、プロパティ（または「発行承認規則の編集」）を開く
- 「発行承認規則」(Issuance Authorization Rules) で、少なくとも必要なユーザーが 許可 されていることを確認する
検証段階で切り分けを速くするなら、まずは「すべてのユーザーを許可（Permit All Users）」にして疎通を成立させ、動作確認が取れてから「特定グループのみ許可」に絞るのが実務的です。
| ルール方針 | おすすめ場面 | 注意点 |
|---|---|---|
| Permit All Users（全ユーザー許可） | 初期構築／切り分け | 本番では対象 RP にアクセスできるユーザー範囲を必ず絞る |
| 特定グループのみ許可 | 本番運用 | グループの同期漏れ・ネスト・条件ミスで想定外に拒否されることがある |
発行承認規則のイメージ（例）
GUI のテンプレートを使うのが確実ですが、何をしているかを理解するために「許可」の考え方だけ押さえておくと、後でトラブルシュートが楽になります。
@RuleName = "Permit All Users (example)"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"]
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");ログを見て「止まっている層」を 1 個ずつ潰す
AD FS は「どこで失敗したか」をイベントログに残してくれるため、闇雲に設定をいじるよりも速く解決できます。SAML 連携は設定ミスが 1 つあるだけで同じ画面を行き来しやすいので、ログで層を切り分けるのがコツです。
まず見るログ
- イベント ビューアー →「アプリケーションとサービス ログ」→「AD FS」→「Admin」
- 必要に応じて「セキュリティ」ログ（監査を有効にしている場合）
| ログ/メッセージのヒント | 意味の目安 | 優先して直す設定 |
|---|---|---|
| NoAuthnContext | 要求された認証方式（コンテキスト）を満たせない | Authentication Policies（Intranet/Extranet の一次認証） |
| Access denied / not authorized | RP へのトークン発行が許可されていない | Issuance Authorization Rules（許可ルール） |
| Relying party not found / identifier mismatch | RP 識別子やメタデータの不整合 | Relying Party Identifier、メタデータ URL/インポート内容 |
| Certificate / signature / decrypt error | 署名・暗号化の設定ミス（証明書やアルゴリズム） | トークン署名証明書、暗号化証明書、Duo 側の設定 |
ポイントは「認証（Authentication）」と「認可（Authorization）」を混同しないことです。AD FS の画面上は同じ “ログインの失敗” に見えても、ログ上ははっきり別のエラーになります。
動作確認のチェックリスト
フォーム認証を許可したのに改善しない場合、次の観点で「リクエストがどこを通っているか」を確認します。
| チェック項目 | 確認方法 | よくある落とし穴 |
|---|---|---|
| Intranet として判定されているか | 社内ネットワークからアクセスし、AD FS が想定どおりの認証画面になるか | プロキシ/WAP 経由で Extranet 扱いになる／逆に社外から VPN で Intranet 扱いになる |
| RP への許可ルールが効いているか | 許可ルールを一時的に「全ユーザー許可」にして挙動を見る | グループ制限の条件が厳しすぎて誰も通らない |
| メタデータとエンドポイントが一致しているか | RP の識別子、ACS URL、証明書を突き合わせる | HTTP/HTTPS 混在、末尾スラッシュ違い、別名（CNAME） |
| 時刻同期が取れているか | AD FS／Duo／クライアントの時刻を NTP で揃える | NotBefore/NotOnOrAfter で弾かれる（数分のズレでも影響） |
重要な補足：Duo 側の前提と「AD FS を外に出したくない」要件の衝突
今回のように “設定自体は動いた” 後に気づきやすいのが設計上の落とし穴です。SAML のブラウザベース SSO は、ユーザーのブラウザが IdP（AD FS）のサインイン URL にリダイレクトされるのが基本動作です。つまり、社外から利用するユーザーがいるなら、そのユーザーが AD FS に到達できる必要があります。
要件として「AD FS サーバーを外部公開したくない」が強い場合、ここで矛盾が発生します。
| 要件 | そのままだと起きること | 現実的な落としどころ |
|---|---|---|
| AD FS をインターネットに公開しない | 社外ユーザーのブラウザが IdP に到達できず、SAML 認証フローが成立しない | WAP/公開用プロキシで公開経路を作る、または別 IdP に寄せる |
| 社外利用もしたい（VPN 前提は避けたい） | VPN がないとログインできず、利便性・運用負荷が上がる | 外部公開前提の別 IdP（クラウド IdP 等）＋AD を背後のユーザーDBにする |
この衝突があると、いくら Duo と AD FS の設定を詰めても「構成として成立しない」ため、最終的に AD FS を IdP にする構成をやめて別 IdP を採用し、AD は背後のユーザーDBとして利用する判断になりやすいです。
AD FS を直接外に出したくない場合の選択肢
「AD FS をそのままインターネットに露出させない」ことを守りつつ SAML を成立させる典型パターンを整理します。セキュリティ要件や既存構成（DMZ の有無、証明書運用、WAF の有無）で最適解が変わるため、比較表で当たりを付けると決めやすくなります。
| 選択肢 | 概要 | メリット | 注意点 |
|---|---|---|---|
| Web Application Proxy（WAP）/ AD FS Proxy を挟む | 外部からはプロキシにだけ到達させ、AD FS 本体は内部に置く | 公開面を絞りやすい／AD FS の定番構成 | DMZ 設計・証明書・名前解決が難所になりやすい |
| リバースプロキシ／WAF で公開する | HTTP(S) を中継して AD FS の公開 URL を提供する | 既存の公開基盤を流用しやすい | AD FS 特有の要件（パス、ヘッダー、クッキー、証明書）で詰まりやすい |
| 外部公開前提の別 IdP を採用（クラウド IdP など） | IdP を外部で完結させ、AD は同期・フェデレーションで利用する | 外部到達性の問題を根本回避／条件付きアクセス等が使える | ライセンス／既存運用の変更、ユーザー属性同期の設計が必要 |
| VPN 前提で社外も Intranet 扱いにする | 社外からは VPN で社内に入ってから SAML を踏ませる | 外部公開を避けられる | ユーザー体験が重い／VPN が単一障害点になりやすい |
「WAP を挟む」か「別 IdP に寄せる」かは、次の判断基準が分かれ目です。
- DMZ を含む公開基盤を運用できるか（証明書更新、監視、脆弱性対応、冗長化）
- 将来的に Windows Server/AD FS のバージョン更新を計画できるか
- 条件付きアクセス、MFA、デバイス準拠など “認証の高度化” をどこまで求めるか
本番を見据えた設計メモ：安全に進めるための実務ポイント
最後に、検証を「動いた」で終わらせず、本番で事故を起こしにくくするための実務ポイントをまとめます。
- 切り分けは広く、運用は狭く：検証では「全ユーザー許可」でまず疎通、本番ではグループ許可に絞る。
- フォーム認証を許可しても SSO は維持できる：社内ドメイン参加端末の利便性を落としたくない場合、WIA とフォームを併用し、想定ユーザーで画面遷移を確認する。
- 証明書と名前解決は最初に固める：SAML は URL の揺れ（別名、末尾スラッシュ、HTTP/HTTPS）や証明書の更新で壊れやすい。運用手順まで含めて設計する。
- ログを定点観測できるようにする：障害時に「今どの層で失敗しているか」を短時間で判断できるよう、AD FS/Admin の収集・保管を仕組みにしておく。
まとめ
Duo Network Gateway を AD FS 3.0（Windows Server 2012 R2）と SAML 2.0 連携する際に NoAuthnContext が出る場合、まず疑うべきは Duo 固有の設定ではなく、AD FS 側の「認証方式（フォーム認証の許可）」と「RP へのアクセス許可（発行承認規則）」です。ここを整えると、エラーの種類が変わり、切り分けが一気に進みます。
一方で、社外利用を想定するなら「IdP がユーザーから到達可能である」という SAML の前提と、「AD FS を外部公開したくない」という要件が衝突しやすい点も重要です。公開用の構成（WAP/公開プロキシ）を採るのか、外部公開前提の別 IdP に寄せるのかを早めに判断し、無駄な遠回りを減らすのが現実的です。
コメント