「Edge 147 の AuthNegotiateDelegateByKdcPolicy は結局何が変わるのか」「既存の AuthNegotiateDelegateAllowlist とどう違うのか」と迷う管理者向けに先に結論を言うと、この新ポリシーは Negotiate/Kerberos 認証での資格情報委任を KDC の承認に連動させるためのものです。AuthNegotiateDelegateAllowlist を置き換えるのではなく、許可リストに加えて KDC がサービス チケットへ OK-AS-DELEGATE を付けた場合だけ委任を許可する“引き締め”の設定だと理解すると外しません。Microsoft は 2026 年 4 月 10 日公開の Stable 147.0.3912.60 リリースノートでこのポリシーを新規追加として掲載しており、現時点のポリシー定義では対応は macOS 147 以降、Windows は未サポートです。 (Microsoft Learn)
実務目線で見ると、これは「新しい SSO 機能が増えた」というより、「既存の Kerberos/Negotiate 委任をブラウザー側でより厳密に制御できるようになった」変更です。Edge のポリシー管理で何を見直すべきか、関連ポリシーとの違い、設定イメージ、導入前の判断基準までまとめて確認していきます。 (Microsoft Learn)
Edge 147 で追加された AuthNegotiateDelegateByKdcPolicy とは
Microsoft Edge Stable 147.0.3912.60 のリリースノートでは、AuthNegotiateDelegateByKdcPolicy が「新しいポリシー」として追加されています。ポリシー定義の説明もシンプルで、KDC ポリシーを使って資格情報を委任するための設定です。 (Microsoft Learn)
| 項目 | 内容 |
|---|---|
| 追加時期 | Edge 147 / Stable 147.0.3912.60 |
| 役割 | KDC の承認と AuthNegotiateDelegateAllowlist の両方を満たした場合だけ資格情報を委任 |
| データ型 | ブール値 |
| 必須ポリシー | 対応 |
| 推奨ポリシー | 非対応 |
| 動的更新 | 対応 |
| 現時点の対応 OS | macOS 147 以降 |
このポリシーの管理属性は上表のとおりで、特に見落としやすいのは「推奨ポリシーでは配れないこと」と「現時点では macOS 専用であること」です。Windows の GPO 追加項目として考えて読み進めると、途中で前提がずれてしまいます。 (Microsoft Learn)
まず押さえたい変更点
このポリシーを有効にすると、Edge は KDC からの承認を受け入れ、KDC がサービス チケットに OK-AS-DELEGATE を設定した場合にのみ、要求先サービスへユーザー資格情報を委任します。しかも、そのサービスは AuthNegotiateDelegateAllowlist にも入っている必要があります。逆に、無効または未構成なら、KDC の承認は無視され、従来どおり AuthNegotiateDelegateAllowlist にあるサービスに対してだけ委任します。 (Microsoft Learn)
| 設定状態 | 委任の条件 | 実務への影響 |
|---|---|---|
| 無効 / 未構成 | AuthNegotiateDelegateAllowlist に含まれていること | 既存の allowlist 設計がそのまま委任条件になる |
| 有効 | Allowlist に含まれ、かつ KDC が OK-AS-DELEGATE を付与していること | 委任条件が厳格になる。KDC 側の設定が不足しているサービスでは差が出やすい |
ここで重要なのは、この変更が AuthNegotiateDelegateAllowlist を不要にするものではない点です。Edge 147 の新ポリシーは、委任先の一覧にさらに KDC 側の条件を重ねる追加ガードだと考えると分かりやすいです。 (Microsoft Learn)
AuthServerAllowlist・AuthNegotiateDelegateAllowlist との違い
混同しやすいので、まず一言で整理します。AuthServerAllowlist は「どこで統合認証してよいか」、AuthNegotiateDelegateAllowlist は「どこへ資格情報を委任してよいか」、AuthNegotiateDelegateByKdcPolicy は「委任の前に KDC の許可まで要求するか」です。認証と委任は似ていますが、役割は別です。 (Microsoft Learn)
| ポリシー | 何を決めるか | 未設定時に起きやすいこと |
|---|---|---|
| AuthServerAllowlist | 統合認証を有効にするサーバー | インターネット判定のサイトでは IWA 要求が無視されやすい。macOS では統合認証に必須 |
| AuthNegotiateDelegateAllowlist | ユーザー資格情報を委任できるサーバー | イントラネット判定でも資格情報を委任しない |
| AuthNegotiateDelegateByKdcPolicy | KDC の承認を委任条件に含めるか | 有効時は OK-AS-DELEGATE がないサービスへの委任が成立しにくくなる |
Microsoft の ID 関連ドキュメントでも、Negotiate 資格情報の委任が必要なサービス向けに AuthNegotiateDelegateAllowlist を使った constrained delegation を案内しています。つまり、単に社内サイトへ自動サインインしたいだけなのか、ブラウザーから先のサービスへ資格情報委任まで使うのかで、見るべきポリシーが変わります。 (Microsoft Learn)
さらに、macOS の Platform SSO で Kerberos SSO を使う構成では、Microsoft は Edge 向けに AuthNegotiateDelegateAllowlist と AuthServerAllowlist の設定を案内しています。すでにこの 2 つを運用している組織ほど、今回の新ポリシーを追加しやすいはずです。 (Microsoft Learn)
導入が向く環境と、急がなくてよい環境
公式仕様から逆算すると、導入優先度は次のように考えると整理しやすいです。 (Microsoft Learn)
| 状況 | 優先度 | 理由 |
|---|---|---|
| macOS の Edge で Kerberos/Negotiate 委任を使っている | 高い | 直接の対象で、KDC 基準を追加できる |
| macOS Platform SSO + Kerberos SSO を運用している | 高い | 既存 allowlist に追加しやすい |
| AuthNegotiateDelegateAllowlist を広めに設定している | 中〜高 | 委任範囲の引き締めに向く |
| Windows 中心の環境 | 低い | 現時点のポリシー定義では未サポート |
| 推奨ポリシーでゆるく段階展開したい | 低い | 推奨ポリシー非対応 |
実務的には、Windows 中心の組織が今すぐ大きく動くテーマではありません。まずは macOS で Edge の Kerberos SSO や委任を使っている部署・端末群があるかを洗い出し、そこにだけ焦点を当てる方が効率的です。 (Microsoft Learn)
macOS での設定イメージ
macOS では、Microsoft Edge のポリシーを com.microsoft.Edge.plist として構成できます。Microsoft Learn では、plist の名前は com.microsoft.Edge.plist、配布は Intune などの MDM を使う流れが案内されています。ポリシーごとの基本設定キー名も各ポリシー定義で確認できます。 (Microsoft Learn)
以下は構成イメージです。
<key>AuthServerAllowlist</key>
<string>*.contoso.com</string>
<key>AuthNegotiateDelegateAllowlist</key>
<string>app.contoso.com</string>
<key>AuthNegotiateDelegateByKdcPolicy</key>
<true/>この例では、AuthServerAllowlist が統合認証の対象、AuthNegotiateDelegateAllowlist が委任先、AuthNegotiateDelegateByKdcPolicy が KDC 条件の強制です。ワイルドカードは使えますが、最初から広く許可するより、まずは対象アプリの FQDN を絞って検証する方が失敗しにくいです。 (Microsoft Learn)
反映確認で見落としやすい点
反映確認は edge://policy が手早いです。Microsoft のポリシー確認手順でも edge://policy が案内されています。さらに注意したいのは、AuthNegotiateDelegateByKdcPolicy 自体は動的更新に対応している一方、AuthServerAllowlist と AuthNegotiateDelegateAllowlist はブラウザー再起動が必要なことです。allowlist を触ったのに Edge を開いたまま判定すると、「設定したのに効かない」と誤解しやすくなります。 (Microsoft Learn)
| ポリシー | 反映時の注意点 |
|---|---|
| AuthServerAllowlist | 再起動が必要 |
| AuthNegotiateDelegateAllowlist | 再起動が必要 |
| AuthNegotiateDelegateByKdcPolicy | 動的更新に対応 |
この 3 つをまとめて変更するなら、最終確認は必ず Edge 再起動後に行うのが安全です。 (Microsoft Learn)
失敗しやすいポイント
もっとも多いのは、「サインインできるなら委任もできる」と考えてしまうことです。統合認証の対象と委任先は別ポリシーで管理され、Edge 147 からはさらに KDC の承認条件も足せるようになりました。設定箇所を混同すると、認証は通るのに委任だけ失敗する、という状態が起きます。 (Microsoft Learn)
| 失敗例 | 起きる理由 | 対処 |
|---|---|---|
| 新ポリシーだけ有効にする | 委任先は AuthNegotiateDelegateAllowlist にも含める必要がある | 先に委任先 allowlist を整理する |
| AuthServerAllowlist を省く | macOS では統合認証に必要 | 認証対象と委任対象を別々に定義する |
| KDC 側を見ずに本番投入する | 有効化すると OK-AS-DELEGATE が委任条件に加わる | 代表サービスでパイロット検証する |
| 設定直後に失敗判定する | allowlist 系は再起動が必要 | Edge 再起動後に再確認する |
| Windows 向け GPO の話だと思い込む | 現時点では Windows 未サポート | 対象 OS を先に切り分ける |
特に 3 行目は重要です。AuthNegotiateDelegateByKdcPolicy はブラウザー単体で魔法のように安全性を上げる設定ではなく、KDC 側の委任判断とセットで効くポリシーです。KDC 条件が整っていないサービスでは、既存構成との差が表面化します。 (Microsoft Learn)
本番投入前のテスト手順
本番投入は、次の順で進めると失敗しにくいです。
- まずは 1 つの対象アプリと 1 台の検証用 Mac に絞る
AuthServerAllowlistとAuthNegotiateDelegateAllowlistを必要最小限の FQDN で定義するAuthNegotiateDelegateByKdcPolicyを有効にする- Edge を閉じて開き直し、
edge://policyで反映を確認する - 対象アプリへアクセスし、既存運用との差分を確認する
- 想定どおりに動かなければ、KDC 側のチケット条件とサーバー側構成を確認する
- 問題がなければ、対象サービスごとに段階展開する
Microsoft の ID 構成ドキュメントでは、WIA ベースの SSO ではサーバー側の追加設定が必要な場合があると案内されています。つまり、ブラウザー ポリシーだけで完結すると決めつけない方が安全です。macOS の Platform SSO を使う環境なら、Kerberos SSO のテストとして app-sso platform -s で Kerberos チケットを確認する手順も Microsoft が案内しています。 (Microsoft Learn)
まとめ
AuthNegotiateDelegateByKdcPolicy は、Edge 147 で追加された「KDC の承認まで含めて資格情報委任を制御する」ための管理ポリシーです。新しい認証機能というより、既存の AuthNegotiateDelegateAllowlist をより厳密に運用するための追加条件と捉えると理解しやすいでしょう。次にやるべきことは、macOS の Edge で Kerberos/Negotiate 委任を使っているかを確認し、使っているなら AuthServerAllowlist と AuthNegotiateDelegateAllowlist を棚卸ししたうえで、1 サービス・少数端末からパイロット導入することです。 (Microsoft Learn)
コメント