結論から言うと、Microsoft EntraでPalo Alto Networks GlobalProtectのSAML SSOを構成している場合、Identifier URL、つまりIdentifier (Entity ID) にポート番号 :443 が含まれているかを必ず確認してください。2026年5月20日にMicrosoftDocs/entra-docsのPRで、GlobalProtectチュートリアルのIdentifier URL例が https://<Customer Firewall URL>/SAML20/SP から https://<Customer Firewall URL>:443/SAML20/SP に修正されました。ポート番号がないIdentifier URLでは動作しない、というのが今回の変更点です。(GitHub)
これはMicrosoft Entra IDの大規模な仕様変更というより、Palo Alto Networks GlobalProtect向けSAML設定手順の重要なドキュメント修正と見るべきです。ただし、既存環境が古い記載どおりに設定されている場合、SSO失敗やVPN接続不可につながる可能性があります。特にリモートアクセス基盤としてGlobalProtectを使っている組織では、単なる表記修正として流さず、設定値・手順書・自動化スクリプトまで確認する価値があります。
Microsoft Entraのセキュリティ更新、管理者が確認すべき影響範囲と対応ポイント
今回の更新対象は、Microsoft EntraとPalo Alto Networks GlobalProtectをSAMLで連携する公式チュートリアルです。PR上で確認できる変更は1ファイルの1行で、対象ファイルは palo-alto-networks-globalprotect-tutorial.md です。変更内容は、Basic SAML Configurationの Identifier (Entity ID) に指定するURLパターンへポート番号 :443 を追加するものです。(GitHub)
| 確認項目 | 内容 |
|---|---|
| 更新日 | 2026年5月20日にPRがマージ |
| 対象サービス | Microsoft Entra IDとPalo Alto Networks GlobalProtectのSAML SSO連携 |
| 対象設定 | Basic SAML ConfigurationのIdentifier (Entity ID) |
| 修正前の例 | https://<Customer Firewall URL>/SAML20/SP |
| 修正後の例 | https://<Customer Firewall URL>:443/SAML20/SP |
| 重要な注意点 | Identifier URLにポート番号がないと動作しない |
| 直接変更されていない項目 | Reply URL、Sign on URL、SAML証明書、クレーム設定 |
現在のMicrosoft LearnのGlobalProtectチュートリアルでも、Identifier (Entity ID) の例は https://<Customer Firewall URL>:443/SAML20/SP と示されています。一方で、Reply URLは https://<Customer Firewall URL>/SAML20/SP/ACS、Sign on URLは https://<Customer Firewall URL> の形式で案内されています。(Microsoft Learn)
重要なのは、今回の更新を「URLにポート番号を付けるだけ」と軽く見ないことです。SAMLのEntity IDは、単なるアクセス先URLではなく、サービスプロバイダーを識別するための値として扱われます。https://vpn.example.com/SAML20/SP と https://vpn.example.com:443/SAML20/SP は、見た目が似ていてもSAML連携上は別の識別子として扱われる可能性があります。
なぜIdentifier URLにポート番号が必要なのか
SAMLでは、サービスプロバイダーであるGlobalProtectと、IDプロバイダーであるMicrosoft Entra IDの間で「この認証要求はどのアプリケーション向けか」を識別します。そのときに使われる代表的な値がIdentifier (Entity ID) です。
MicrosoftのSAMLプロトコル文書では、AuthnRequest内の Issuer 要素は、Microsoft Entra ID側のクラウドサービスに登録されたServicePrincipalNamesのいずれかと正確に一致する必要があると説明されています。つまり、GlobalProtect側が :443 を含むIssuerを送っているのに、Entra側のIdentifierがポート番号なしで登録されていると、期待した一致判定にならない可能性があります。(Microsoft Learn)
管理者が押さえるべきポイントは次のとおりです。
| 観点 | 判断ポイント |
|---|---|
| HTTPの通常動作 | HTTPSの既定ポートは443だが、SAML Entity IDの一致判定では省略してよいとは限らない |
| Entra側の設定 | Identifier (Entity ID) に :443 を含める |
| GlobalProtect側の設定 | SP側が使用するEntity ID、Issuer、メタデータの値とEntra側を一致させる |
| トラブル時の見方 | 「URLとして到達できるか」ではなく「SAML上の識別子が一致しているか」を見る |
実務では、ここを混同しがちです。ブラウザで https://vpn.example.com にアクセスできるからといって、SAMLのIdentifierもポート番号なしでよいとは限りません。今回の更新は、その落とし穴を避けるための修正です。
影響を受ける可能性がある環境
今回の影響を受けやすいのは、Palo Alto Networks GlobalProtectをMicrosoft Entra IDのエンタープライズアプリとして登録し、SAML SSOを使っている環境です。特に、過去の公式手順や社内手順書をコピーして設定した環境では、Identifier (Entity ID) が古い形式のままになっている可能性があります。
| 環境 | 影響の可能性 | 確認すべきこと |
|---|---|---|
| GlobalProtectをEntra IDのSAML SSOで利用中 | 高 | Identifier (Entity ID) に :443 が含まれているか |
| これからGlobalProtect SSOを新規構成する環境 | 高 | 最新のMicrosoft Learn手順どおりに設定する |
| 過去に社内Wikiや手順書へURL例を転記した環境 | 中〜高 | 手順書内のIdentifier URLが古くないか |
| Terraform、Graph API、PowerShellなどでSAML設定値を管理している環境 | 中 | コード内のEntity ID文字列に :443 があるか |
| GlobalProtect以外のSAMLアプリ | 低 | 今回のPRの直接対象ではないが、各アプリのEntity ID一致は別途確認する |
GlobalProtectはリモートアクセス用途で使われることが多いため、SSO設定ミスの影響は単なるアプリログイン失敗にとどまりません。ユーザーがVPNへ接続できず、管理者も社内リソースへ入れない、という状況が起きる可能性があります。設定変更は、必ず代替アクセス手段を確保したうえで実施してください。
Microsoft Entra管理者が確認すべきSAML設定
Microsoft Learnの手順では、Palo Alto Networks – GlobalProtectをギャラリーから追加し、Enterprise appsのSingle sign-onでSAMLを選択して構成します。SAMLベースのSSO設定では、Basic SAML ConfigurationでReply URLやSign on URLなどを指定します。Microsoftの一般的なSAML SSO手順でも、アプリごとの構成ガイドに従って正しいIdentifierを確認することが求められています。(Microsoft Learn)
まずは、次の3項目を確認します。
| Microsoft Entraの項目 | GlobalProtect向けの確認例 | 注意点 |
|---|---|---|
| Identifier (Entity ID) | https://<Customer Firewall URL>:443/SAML20/SP | 今回の更新対象。ポート番号 :443 を含める |
| Reply URL (Assertion Consumer Service URL) | https://<Customer Firewall URL>/SAML20/SP/ACS | 今回のPRで変更された項目ではない。GlobalProtect側の値と照合する |
| Sign on URL | https://<Customer Firewall URL> | ユーザーがアクセスするGlobalProtectのサインオンURLと整合させる |
<Customer Firewall URL> には、自社のGlobalProtectポータルまたは対象となるファイアウォールのFQDNを入れます。たとえば、GlobalProtectのURLが vpn.example.co.jp の場合、Identifier (Entity ID) は次のようになります。
https://vpn.example.co.jp:443/SAML20/SP古い形式のままになっている場合は、次のようにポート番号がありません。
https://vpn.example.co.jp/SAML20/SPこの差分は見落としやすいものの、SAMLでは致命的な不一致になり得ます。設定レビューでは、URL全体を目視するだけでなく、文字列として完全一致しているかを確認してください。
修正前に準備すべきこと
GlobalProtectのSSO設定は、ユーザーのVPN接続に直結します。いきなり本番のIdentifierを変更すると、想定外のSSO失敗時に切り戻しや調査が難しくなります。作業前に、最低限次の準備をしてください。
| 準備項目 | 理由 |
|---|---|
| 変更前のSAML設定値を記録する | 失敗時に元の設定へ戻すため |
| GlobalProtect側のSPメタデータまたはEntity IDを確認する | Entra側だけを直しても、SP側と一致しなければ動かないため |
| VPNに依存しない管理アクセスを確保する | VPN SSOが失敗しても管理画面へ入れるようにするため |
| テストユーザーを用意する | 全ユーザーへ影響を出す前に検証するため |
| 作業時間帯を調整する | リモートワーク利用者への影響を抑えるため |
| 社内ヘルプデスクへ周知する | SSO失敗の問い合わせを一次切り分けできるようにするため |
特に重要なのは、VPNに依存しない管理経路です。GlobalProtectに入れないとファイアウォールや関連ログを見られない構成では、SSO障害時の復旧が遅れます。現地コンソール、管理用固定回線、別経路の踏み台、ローカル管理者アカウントなど、組織の運用ポリシーに沿った代替手段を事前に確認しておきましょう。
Identifier URLを確認・修正する手順
以下は、Microsoft Entra管理センターで確認する場合の実務手順です。画面名称は変更される可能性がありますが、確認すべき場所はEnterprise applicationsのSAML設定です。
- Microsoft Entra管理センターにサインインします。
- Entra ID から Enterprise applications を開きます。
- 対象の Palo Alto Networks – GlobalProtect アプリを選択します。
- 左メニューから Single sign-on を開きます。
- SAML設定画面で Basic SAML Configuration を編集します。
- Identifier (Entity ID) を確認します。
https://<Customer Firewall URL>:443/SAML20/SPの形式になっていない場合は、GlobalProtect側のSP設定と照合したうえで修正します。- 保存後、テストユーザーでSP initiated SSOを実行します。
- 問題がなければ、対象ユーザーまたは対象グループで段階的に確認します。
- 社内手順書、構成管理台帳、自動化コードのURL例も同じ形式へ更新します。
Microsoftのトラブルシューティング文書では、IdentifierやReply URLを追加できない場合、アプリに事前設定されたパターンと入力値が一致しているかを確認するよう案内されています。ギャラリーアプリでは、入力できるURLパターンに制約があることもあるため、赤い警告やプレースホルダー表示も確認してください。(Microsoft Learn)
自動化・構成管理で確認したい文字列
SAML設定をコードや構成管理台帳で管理している場合は、リポジトリやドキュメント内に古いIdentifierが残っていないか検索します。
/SAML20/SP
https://<GlobalProtect FQDN>/SAML20/SP
Identifier
Entity ID
Palo Alto Networks - GlobalProtect古い形式が見つかった場合は、単純置換する前に「それがIdentifier (Entity ID) なのか、Reply URLなのか、説明文なのか」を確認してください。今回のPRで修正されたのはIdentifier URLです。Reply URLまで機械的に :443 付きへ変更すると、別の不一致を作る可能性があります。
展開時に失敗しやすいポイント
今回の変更は小さく見えますが、SAML連携では1文字の違いが障害になります。特に次のポイントは、現場で見落とされやすい部分です。
| 失敗しやすいポイント | 起きること | 対応 |
|---|---|---|
:443 を入れ忘れる | SAMLのIssuerまたはAudienceの不一致でSSOが失敗する可能性 | Identifier (Entity ID) を公式パターンに合わせる |
| ポータルURLとゲートウェイURLを混同する | 一部の接続先だけSSOに失敗する | GlobalProtect側の実際のSP設定を確認する |
| FQDNとIPアドレスを混在させる | Entra側とGlobalProtect側で識別子が一致しない | どちらを正式値にするか決め、全設定を統一する |
| 末尾スラッシュを追加する | 別のEntity IDとして扱われる可能性 | 公式例とGlobalProtect側の値に合わせる |
| Reply URLも同じルールで変更する | ACS URLの不一致が発生する可能性 | 今回の変更対象はIdentifierであることを明確にする |
| 本番だけ修正する | 検証環境や手順書に古い値が残る | テスト環境、DR環境、社内Wikiも更新する |
SAML設定では、「見た目として同じURLに見えるか」ではなく、「相手が送ってくる文字列と登録値が完全に一致しているか」が重要です。レビュー時は、管理画面のスクリーンショットだけでなく、コピーした文字列をテキストで比較するとミスを減らせます。
テスト時に見るべき確認項目
設定変更後は、Microsoft Entra側とGlobalProtect側の両方でテストします。Microsoft LearnのGlobalProtect手順では、Entra管理センターのテスト、このアプリケーションへの直接アクセス、My Appsからの起動といった確認方法が示されています。(Microsoft Learn)
| テスト項目 | 期待する結果 | 失敗時に疑うポイント |
|---|---|---|
| Entra管理センターのSSOテスト | 認証フローが開始される | Identifier、Reply URL、ユーザー割り当て |
| GlobalProtectポータルからのログイン | Entra IDへリダイレクトされ、認証後に戻る | SP initiated SSO、ACS URL、証明書 |
| My Appsからの起動 | 対象アプリへサインインできる | Sign on URL、アプリ割り当て |
| 新規ユーザーの初回ログイン | 必要に応じてJITプロビジョニングされる | ユーザー属性、NameID、アプリ側ユーザー制約 |
| 複数拠点・複数ゲートウェイ | 対象ごとにSSOが成功する | ゲートウェイ別Entity ID、URLの取り違え |
テストで失敗した場合は、まずIdentifier (Entity ID) とGlobalProtect側のIssuerまたはEntity IDを比較します。次にReply URL、証明書、ユーザー割り当て、条件付きアクセス、クレーム設定の順で確認すると、切り分けが進めやすくなります。
管理者と開発者が更新すべきドキュメント・成果物
今回の変更は、Entra管理センターの値だけ直せば終わりではありません。運用に関わるドキュメントやコードに古いURL例が残っていると、将来の再構築や障害対応で同じミスが再発します。
更新対象になりやすいものは次のとおりです。
| 更新対象 | 確認内容 |
|---|---|
| 社内構築手順書 | Identifier URLが :443 付きになっているか |
| 運用Runbook | SSO障害時の確認項目にEntity ID一致確認が含まれているか |
| IaC・自動化スクリプト | ハードコードされたEntity IDが古くないか |
| 変更管理チケットのテンプレート | SAML設定変更時の事前確認に代替アクセス確保があるか |
| 監査用設定台帳 | 本番、検証、DR環境のIdentifierが最新か |
| ヘルプデスクFAQ | VPNログイン失敗時の一次切り分けに反映されているか |
特に、過去のMicrosoft Learn手順を社内Wikiへ転記している場合は注意が必要です。公式ドキュメントは更新されても、社内Wikiの古いスクリーンショットやコードブロックは自動では直りません。今回のような1行修正ほど、古い情報が残りやすいものです。
よくある誤解
HTTPSの既定ポートは443だから省略してもよい？
通常のWebアクセスでは、HTTPSの既定ポートとして443が使われます。しかし、SAMLのIdentifier (Entity ID) は、ブラウザで到達するためのURLというより、サービスプロバイダーを識別する文字列として扱われます。公式チュートリアルが :443 付きへ修正された以上、GlobalProtect連携では省略しないのが安全です。
Reply URLにも:443を入れるべき？
今回のPRで変更されたのはIdentifier (Entity ID) のURL例です。現在のMicrosoft LearnのGlobalProtect手順では、Reply URLの例は https://<Customer Firewall URL>/SAML20/SP/ACS と示されています。Reply URLを変更する場合は、GlobalProtect側のACS URLと照合し、公式手順やベンダー側設定に基づいて判断してください。(Microsoft Learn)
証明書の再発行やクレーム変更も必要？
今回の更新内容だけを見る限り、SAML署名証明書、属性とクレーム、NameID形式の変更は示されていません。SSOが失敗している場合でも、まずはIdentifierの不一致を確認し、その後に証明書やクレームを切り分ける順序が現実的です。
Microsoft Entra全体の仕様変更と考えるべき？
PRの差分は、Palo Alto Networks GlobalProtectチュートリアル内のIdentifier URL例を修正するものです。Microsoft Entra ID全体のSAML仕様がこの日に変更された、と断定できる内容ではありません。今回の対応は、GlobalProtect向けの公式手順修正として扱うのが適切です。(GitHub)
今すぐ取るべき対応
Microsoft EntraでPalo Alto Networks GlobalProtectのSAML SSOを運用している管理者は、まず本番環境のIdentifier (Entity ID) を確認してください。値が https://<Customer Firewall URL>:443/SAML20/SP の形式になっていれば、次に検証環境、DR環境、社内手順書、自動化コードを確認します。古い形式の https://<Customer Firewall URL>/SAML20/SP が残っている場合は、GlobalProtect側の設定と照合し、変更手順と切り戻し手順を用意したうえで修正します。
今回のポイントは、SAML設定を「URL入力作業」として扱わないことです。Identifier (Entity ID) は、Entra IDとGlobalProtectが互いを正しく認識するための合意値です。ポート番号 :443 の有無まで含めて一致しているかを確認することで、SSO障害の予防と復旧時間の短縮につながります。
コメント