Microsoft EntraのCreatio SAML設定更新|Identifier URL末尾スラッシュ修正の影響と確認ポイント

Microsoft EntraでCreatioのSAML SSOを設定している管理者がまず確認すべき点は、Identifier(Entity ID)のURL末尾にスラッシュを付けないことです。2026年5月20日にMicrosoftDocsの公式ドキュメントPRがマージされ、Creatio向けSAML設定例のIdentifierが https://<SUBDOMAIN>.creatio.com/ から https://<SUBDOMAIN>.creatio.com に修正されました。末尾スラッシュが残っていると、CreatioのSSO構成が意図どおり一致せず、サインイン失敗や設定不整合の原因になる可能性があります。(GitHub)

今回の変更はMicrosoft Entra ID本体の機能変更や緊急パッチではなく、Creatio SAML設定例のドキュメント修正です。ただし、SAMLではIdentifier、Reply URL、Sign-on URLのようなURL値の一致が認証フローに影響するため、既にCreatio連携を運用している組織でも設定値の棚卸しをおすすめします。

目次

Microsoft Entra documentation updateの変更点

今回の「Microsoft Entra documentation update: Fix Creatio SAML Identifier URL example」は、Microsoft Entra IDとCreatioをSAMLで連携する手順のうち、Basic SAML ConfigurationのIdentifier例を修正するものです。

MicrosoftDocsのPRでは、Creatio SAML Identifier URLの例から末尾スラッシュを削除したこと、従来の https://<SUBDOMAIN>.creatio.com/ ではなく https://<SUBDOMAIN>.creatio.com とすべきこと、末尾スラッシュによりCreatioのSSO設定が誤る可能性があることが説明されています。(GitHub)

項目修正前修正後
対象設定IdentifierIdentifier
URL例https://<SUBDOMAIN>.creatio.com/https://<SUBDOMAIN>.creatio.com
変更内容URL末尾に / があるURL末尾の / を削除
影響する場面CreatioのSAML SSO設定CreatioのSAML SSO設定
管理者の対応既存設定に末尾スラッシュがないか確認必要に応じてIdentifierを修正してテスト

現在のMicrosoft LearnのCreatio向けSSO手順でも、Identifierのパターンは https://<SUBDOMAIN>.creatio.com、Reply URLは https://<SUBDOMAIN>.creatio.com/ServiceModel/AuthService.svc/SsoLogin、Sign-on URLは https://<SUBDOMAIN>.creatio.com/ と示されています。(Microsoft Learn)

ここで重要なのは、すべてのURLからスラッシュを消すわけではないという点です。今回の修正対象はIdentifierです。Reply URLやSign-on URLは別の意味を持つため、公式手順やCreatio側の実環境URLに合わせて個別に確認する必要があります。

これはセキュリティパッチではなく、SSO設定ミスを防ぐための修正

「Microsoft Entraのセキュリティ更新」として情報を追っている管理者は、今回の変更を脆弱性修正や仕様変更と誤解しないようにしましょう。

今回の更新は、Microsoft Entra IDの認証基盤そのものを変更するものではありません。対象は、Microsoft Learnに掲載されているCreatio向けSAML SSO構成例です。とはいえ、SSO設定のIdentifierはSAML連携の成否に直結するため、運用上の重要度は低くありません。

特に、次のような組織では確認優先度が高くなります。

対象確認優先度理由
2026年5月20日以前の手順を見てCreatio連携を設定した組織高修正前の例を参考にしている可能性がある
CreatioのSSOで断続的なログイン失敗がある組織高Identifier不一致が原因の一つになり得る
新規にCreatioをMicrosoft Entra IDへ統合する組織高初期設定時に誤った値を入れないため
Creatio以外のSAMLアプリのみを使う組織低今回の修正対象はCreatioのドキュメント例に限定される
OIDCやパスワードベースSSOのみの組織低SAML Identifierの設定対象外

管理者が押さえるべき実務上のポイントは、「ドキュメント修正だから無視してよい」ではなく、「過去にその例を使って設定していないか確認する」ことです。

影響範囲:CreatioのSAML SSOを使う環境が中心

今回の影響範囲は、Microsoft Entra IDのEnterprise appsでCreatioをギャラリーアプリとして追加し、SAML SSOを構成している環境です。Microsoft Learnの手順では、Creatioをギャラリーから追加し、Enterprise apps > Creatio > Single sign-onでSAMLを選択して設定する流れが案内されています。(Microsoft Learn)

影響を受ける可能性があるのは、主に次の設定です。

設定項目役割今回の確認ポイント
Identifier(Entity ID)SAML連携でアプリを識別する値https://<SUBDOMAIN>.creatio.com になっているか
Reply URL(ACS URL)認証後にSAMLレスポンスを受け取るURL公式手順またはCreatio側の実URLと一致しているか
Sign-on URLSP開始のサインイン導線必要に応じて末尾スラッシュを含む実URLになっているか
App Federation Metadata URLCreatio側へ渡すメタデータURL最新の設定情報としてCreatio側に共有済みか
ユーザー割り当てSSO利用者の制御テストユーザーと本番ユーザーが適切に割り当てられているか

Microsoft EntraのSAML設定では、Identifierは「Entity ID」として扱われる項目です。MicrosoftのSAML SSO設定ドキュメントでも、Identifier(Entity ID)は統合するアプリ固有のURLであり、アプリごとの構成ガイドに従って正しい値を決める必要があると説明されています。(Microsoft Learn)

つまり、CreatioではCreatio向けの値を、別のSaaSではそのSaaS向けの値を使います。似たURLだからといって、Reply URLやSign-on URLをIdentifierに流用しないよう注意してください。

なぜ末尾スラッシュだけでSSO設定が崩れるのか

URLの末尾スラッシュは、人間が見ると小さな違いに見えます。しかしSAML設定では、文字列としての一致が重要になる場面があります。

たとえば、次の2つは見た目が似ていますが、文字列としては別物です。

https://example.creatio.com
https://example.creatio.com/

Webブラウザでアクセスすると同じページに見えることがありますが、SAMLのIdentifierは「ブラウザで開けるURL」ではなく、サービスプロバイダーを識別する値として扱われます。そのため、アプリ側が期待するEntity IDとMicrosoft Entra側に登録したIdentifierが微妙に違うと、認証要求やレスポンスの検証で不一致が起きる可能性があります。

Microsoft EntraのSAMLプロトコル説明では、AuthnRequestのIssuerがMicrosoft Entra ID内のクラウドサービスのServicePrincipalNamesと正確に一致する必要があると説明されています。これはCreatio固有の説明ではありませんが、SAML連携で識別子の文字列一致が重要であることを理解するうえで参考になります。(Microsoft Learn)

実務では、次のようなミスが起きやすいです。

よくあるミス起きやすい症状対応
Identifierに末尾スラッシュを付けるCreatio側の期待値と一致しないIdentifierを https://<SUBDOMAIN>.creatio.com に修正
Reply URLとIdentifierを混同する認証後の戻り先エラーReply URLはACS URLとして別途確認
サブドメインを本番・検証で取り違える検証環境には入れるが本番で失敗環境ごとに設定表を作る
古い手順を社内Wikiに残す新規構築時に同じミスを繰り返す社内手順書を更新
変更後にテストユーザーで確認しない本番ユーザーで初めて障害化変更前後でSSOテストを実施

末尾スラッシュの有無は、単なる表記ゆれではなく、SSO設定では「別の値」として扱われる可能性があると考えておくべきです。

管理者が確認すべき設定

既にMicrosoft Entra IDでCreatio SSOを運用している場合は、次の順番で確認すると安全です。

Enterprise appsのCreatio設定を確認する

Microsoft Entra管理センターで、対象テナントのEnterprise appsからCreatioを開きます。Microsoft Learnの手順では、少なくともCloud Application Administratorなどの権限でMicrosoft Entra admin centerにサインインし、Entra ID > Enterprise apps > Creatio > Single sign-onへ進む流れが示されています。(Microsoft Learn)

確認する場所は、SAMLのBasic SAML Configurationです。

確認項目推奨される確認内容
Identifierhttps://<SUBDOMAIN>.creatio.com 形式か
Reply URL/ServiceModel/AuthService.svc/SsoLogin を含むCreatioの実URLか
Sign-on URLCreatioのサインイン開始URLとして正しいか
Relay State独自指定が必要な場合のみ設定されているか
Attributes & ClaimsCreatio側が期待するユーザー属性と一致しているか

Identifierに https://example.creatio.com/ のような末尾スラッシュが入っている場合は、変更候補です。ただし、いきなり本番値を変更するのではなく、Creatio側のSSO設定、社内手順書、過去の変更履歴も合わせて確認してください。

Creatio側のSSO設定と突き合わせる

Microsoft Entra側だけを見ても、SSO全体の正しさは判断できません。Creatio側にも、Microsoft Entra IDから取得したLogin URL、Microsoft Entra Identifier、証明書、メタデータURLなどの設定が存在します。

Microsoft LearnのCreatio手順では、Creatio側のSSO設定のためにApp Federation Metadata URLをCreatioサポートチームへ送付する流れが説明されています。(Microsoft Learn)

確認時は、次の観点で突き合わせると実務的です。

突き合わせ対象見るべきポイント
Microsoft Entra側Identifier末尾スラッシュなしのCreatioドメインか
Creatio側のSP Entity IDEntra側Identifierと期待値が一致しているか
Reply URL / ACS URLCreatio側の受信エンドポイントと一致しているか
証明書有効期限切れや古い証明書参照がないか
メタデータURLCreatio側へ共有したURLが現在も有効か

社内でCreatio管理者とMicrosoft Entra管理者が分かれている場合、片方だけで修正すると原因調査が難しくなります。変更作業は、両者で画面共有しながら値を確認するか、変更前後の設定値をチケットに残して進めるのが安全です。

修正が必要な場合の対応手順

Identifierに末尾スラッシュが残っている場合は、次の流れで対応します。

| 手順 | 作業内容 | 注意点 |
| -: | ——————————– | —————————— |
| 1 | 現在のBasic SAML Configurationを記録する | 画面キャプチャだけでなく文字列として控える |
| 2 | Creatio側のSSO設定値を確認する | Entra側だけで判断しない |
| 3 | メンテナンス時間または影響の少ない時間帯を選ぶ | SSO利用者が多い時間帯を避ける |
| 4 | Identifierから末尾スラッシュを削除する | Reply URLやSign-on URLを誤って変更しない |
| 5 | テストユーザーでIDP開始とSP開始を確認する | 片方だけ成功しても完了にしない |
| 6 | 本番ユーザー数名で確認する | 条件付きアクセスやグループ割り当ても見る |
| 7 | 社内手順書と運用チェックリストを更新する | 古いURL例を残さない |

変更前後の値は、次のように記録しておくと後から追跡しやすくなります。

変更前 Identifier:
https://example.creatio.com/

変更後 Identifier:
https://example.creatio.com

変更理由:
MicrosoftDocs PR #1968 により、Creatio SAML Identifier URL例から末尾スラッシュが削除されたため。

このとき、example の部分は実際のCreatioサブドメインに置き換えます。記事や手順書に実ドメインを載せる必要がある場合は、アクセス権のある社内文書に限定しましょう。

新規構築時に間違えやすいポイント

これからMicrosoft Entra IDとCreatioをSAMLで連携する場合は、初期設定時点で今回の修正を反映しておくと、後の切り戻しや障害対応を避けやすくなります。

特に注意したいのは、Identifier、Reply URL、Sign-on URLの違いです。

項目入力例目的
Identifierhttps://example.creatio.comSAML上でCreatioを識別する
Reply URLhttps://example.creatio.com/ServiceModel/AuthService.svc/SsoLogin認証後のSAMLレスポンスを受け取る
Sign-on URLhttps://example.creatio.com/ユーザーがCreatioへアクセスする入口

この3つは似ていますが、同じ値ではありません。特に新規構築では、「URLはだいたい同じだろう」と考えてコピー&ペーストすると失敗しやすくなります。

おすすめは、設定作業前に次のような小さな確認表を作ることです。

Creatio環境名:
本番 / 検証 / 開発

Creatioサブドメイン:
example.creatio.com

Identifier:
https://example.creatio.com

Reply URL:
https://example.creatio.com/ServiceModel/AuthService.svc/SsoLogin

Sign-on URL:
https://example.creatio.com/

確認者:
Creatio管理者 / Microsoft Entra管理者

確認日:
YYYY-MM-DD

この表をチケットや社内Wikiに残しておくと、将来の証明書更新、テナント移行、Creatio環境追加の際にも再利用できます。

開発者・運用担当者が見るべきログとテスト観点

SSOが失敗した場合、画面上のエラーメッセージだけでは原因を特定しにくいことがあります。開発者や運用担当者は、SAMLリクエスト、Microsoft Entraのサインインログ、Creatio側の認証ログを組み合わせて確認しましょう。

確認対象見る内容目的
Microsoft Entraサインインログ対象ユーザー、アプリ、失敗理由、条件付きアクセス結果Entra側で拒否されたのか確認
SAML AuthnRequestIssuer、ACS URL、Destinationアプリ側から送られる値を確認
SAML ResponseAudience、NameID、属性値Creatio側が期待する値か確認
Creatio側ログSSOエラー、ユーザー照合、属性マッピングアプリ側の受け入れ失敗を確認
ブラウザ開発者ツールリダイレクト先、POST先、CookieSP開始フローの途中失敗を確認

テストでは、Microsoft Entra側からCreatioタイルをクリックするIDP開始だけでなく、CreatioのURLへ直接アクセスするSP開始も確認します。Microsoft LearnのCreatio手順でも、SP initiatedとIDP initiatedの両方のテスト方法が案内されています。(Microsoft Learn)

確認すべきテストパターンは次のとおりです。

テスト確認内容
IDP開始My AppsまたはMicrosoft Entraのテスト機能からCreatioへ入れるか
SP開始CreatioのSign-on URLからMicrosoft Entra認証へ遷移できるか
新規ユーザー割り当て直後のユーザーがログインできるか
既存ユーザー既存ユーザーのNameIDやメール属性が正しく紐づくか
条件付きアクセス対象ユーザーMFAやデバイス条件が意図どおり適用されるか
権限なしユーザー未割り当てユーザーが適切に拒否されるか

SSOは「ログインできたら終わり」ではありません。意図しないユーザーが入れないこと、条件付きアクセスが適用されること、属性マッピングが正しいことまで確認して初めて運用可能と判断できます。

移行・展開時の注意点

Creatioを新しいテナントへ移行する、検証環境から本番環境へ展開する、またはAzure AD時代の古い手順からMicrosoft Entra IDの手順へ更新する場合は、URL値の扱いを標準化しておく必要があります。

社内手順書の古いURL例を更新する

今回のようなドキュメント修正は、Microsoft Learnだけを見ている場合は自然に反映されます。しかし、社内Wiki、構築手順書、過去案件の設計書、運用委託先のチェックリストに古い例が残っていると、同じ設定ミスが再発します。

検索すべき文字列は次のようなものです。

creatio.com/
bpmonline
Creatio SAML
Identifier
Entity ID
Basic SAML Configuration

特に https://<SUBDOMAIN>.creatio.com/ のような末尾スラッシュ付きのIdentifier例が残っていないか確認してください。

検証環境と本番環境で値を混在させない

Creatioのサブドメインが環境ごとに分かれている場合、本番と検証の値を取り違えると、SSOテストが片方だけ成功することがあります。

環境Identifier例注意点
本番https://prod-example.creatio.com本番ユーザーの影響があるため変更時間を管理
検証https://test-example.creatio.com本番値をコピーしない
開発https://dev-example.creatio.comテストユーザーと属性値を分ける

設定値は環境ごとに管理し、ExcelやWikiで横並びにすると差分を確認しやすくなります。

変更管理に「URLの文字列一致」を含める

SSO設定の変更レビューでは、証明書や権限だけに目が行きがちです。しかし今回のように、URL末尾の1文字が問題になることもあります。

レビュー項目には、次のような観点を入れておきましょう。

レビュー項目確認内容
末尾スラッシュIdentifierには不要な / が付いていないか
大文字・小文字ドメインやパスの表記が実環境と一致しているか
プロトコルhttp ではなく https か
サブドメイン本番・検証・開発を取り違えていないか
パスReply URLのパスが公式手順やCreatio側設定と一致しているか

今回の更新から得られる運用上の教訓

今回のMicrosoft Entra documentation updateは、小さな修正に見えます。しかし、ID管理やSSO運用では、この種の小さな差分が障害の原因になります。

管理者が今後の運用で意識したいポイントは次の3つです。

まず、公式ドキュメントの変更は構成管理の対象にすることです。MicrosoftDocsのような公開リポジトリでドキュメント修正が行われた場合、自社の手順書や既存設定に影響がないか確認する仕組みがあると、設定ミスを早期に防げます。

次に、SAML設定値はURLではなく識別子として扱うことです。ブラウザで同じように見えるかではなく、アプリとIdPが期待する文字列として一致しているかを確認します。

最後に、SSO変更は必ずテストパターンを分けることです。IDP開始、SP開始、既存ユーザー、新規ユーザー、条件付きアクセス対象ユーザーを分けて確認すれば、障害の見落としを減らせます。

まとめ:Creatio連携を使う管理者はIdentifierの末尾スラッシュを確認

2026年5月20日にマージされたMicrosoft Entraのドキュメント更新では、Creatio SAML Identifier URLの例から末尾スラッシュが削除されました。修正後のIdentifierは、https://<SUBDOMAIN>.creatio.com です。(GitHub)

今回の変更はMicrosoft Entra ID本体の仕様変更ではありませんが、Creatio SSOの設定ミスを防ぐうえで重要です。CreatioをMicrosoft Entra IDとSAML連携している管理者は、まずEnterprise appsのCreatio設定を開き、Identifierに末尾スラッシュが残っていないか確認してください。

次に取るべき行動は明確です。既存設定を記録し、Creatio側の期待値と突き合わせ、必要ならIdentifierを修正し、IDP開始とSP開始の両方でSSOをテストします。あわせて、社内手順書や構築チェックリストから古いURL例を削除しておくと、今後の展開や移行時にも同じミスを防げます。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次