こんにちは、技術部の渡邊です。
今日は、GWSとEntraIDでそれぞれ異なるドメインを使用している場合の
SSOを構成する方法について記載します。
できればSSOを組むGWSとEntraIDのドメインは合わせた方が色々スマートなので
合わせるべきなのですが、諸事情により違うドメインを使用せざるを得ないケースがあります。
異なるドメイン間でSSOを組む際の注意点
下図の様に2度異なるIDを入力する必要があり、利用者側からすると手間を感じてしまう環境となるため注意が必要です。
異なるドメイン間でSSOを組むには
方法はいくつかありますが、EntraID側のアカウントにGWSメールの属性値を持たせてひっかける方法と、EntraID側のUPNを変換する方法が考えられます。
今回はUPNを変換する方法を紹介します。
UPNを変換する場合、EntraID側の属性とクレームから変換の設定を行います。
・変換対象の名前 : nameidentifier
・ソース : 変換
→ 値 : Join (user.userprincipalname, “@”, “変換したいドメイン")
この構文では、UPNの@より後ろのドメイン名を変換します。
UPNの@より左側の文字列がGWSと共通の場合に有効な手段です。
異なるドメイン間でプロビジョニングをするには
プロビジョニングを行う方法もいくつかありますが、認証と同様にユーザーの属性マッピングを変換する方法を紹介したいと思います。
・変換対象とするEntraIDの属性 : userprincipalName
→ 値 : Replace([userPrincipalName], , “(?<Suffix>@(.)*)”, “Suffix”, “@変換したいドメイン", , )
・Google Cloud / Workspaceの属性 : PrimaryEmail
ちなみに、Groupを指定したマッピング変換を行うことも可能ですが、こちらはグループに所属しているユーザーのプロビジョニングが失敗しますのでご注意ください。
エラーメッセージは、Modified attributes (failed) / LinkedEntryMissing なので、グループが保持するメールアドレスの変換によりリンクされたエントリが見当たらなくなってしまうことが原因かと思われるので、実装には注意が必要です。
結局、実装や運用の考慮点やユーザーの利便性を考えると、ドメインは合わせた方が良いですよ、というお話でした。
リベルスカイでは、セキュアなGWS / GCPの利用環境を実現するためのご支援も提供しておりますので、セキュリティでお悩みのお客様は遠慮なくご相談ください👍
