「Enable Multiple O365 Email Domains」について

シラン(2024年5月8日)
以前掲載したショウブの隣に群生していました。単子葉類なので、色違いのショウブかと思ったら別の植物だったので意外でした。
シランは中国、日本、韓国などアジアの一部の国で、4月から5月にかけて咲くようです。

Workspace ONE Accessには、シングルサインオン機能があります。

以前簡単にご紹介したように、この機能は企業で利用されるWebアプリケーションなどのシステムとSAMLなどのフェデレーションプロトコルに則て認証連携を行い、「Workspace ONE Accessに一度ログインすれば認証連携したシステムに個別にユーザー名/パスワードを入力することなく、そのままログインできる」というものです。
最近は勤怠システムや経費精算システムなどもSAMLに対応したSaaSを利用する企業が増えつつあり「覚えないといけないユーザー名/パスワードがここ数年で増えた！」という方も多いと思います。
そのような状況において、Workspace ONE Accessと複数のSaaSをSAMLなどで認証連携することにより、シングルサインオン機能はユーザーのログインにかかる手間を下げてくれます。
※もっと言うとすでに勤務先でOktaやOnelogin、HENNGE ONEなどで認証を統一しており、「ここ数年で、勤怠システムにログインしようとしたら、ログイン先の勤怠システムの代わりに、なんかよくわからない別の認証システムにユーザー名/パスワードを入力するようになった」という方もいらっしゃると思います。Workspace ONE Accessも、そんな「なんかよくわからない別の認証システム」のうちの一つです。

認証連携を行う際、どこかからWorkspace ONE Accessなどの認証を委任される側のシステムのことをIdP(Identity Provider)とよび、認証をどこかに委任する側のシステムのことをSP(Service Provider)と呼びます。

認証連携のプロトコルは、SAMLを採用しているSPが多い印象があります。
※ちなみにWorkspace ONE Accessが対応している認証連携のプロトコルは以下の通りです。

  • SAML 2.0 applications
  • SAML 1.1 applications
  • WS-Federation 1.2 supported for Office 365 only
  • OpenID Connect applications

出典：Providing Access to Web Applications in Workspace ONE Access

Workspace ONE Accessでは、人気が高く、多くの企業で利用されるSaaSアプリやWebアプリケーションについては、認証連携の作業が手間にならないよう、あらかじめカタログとしてまとめてあります。

※欧米で流行しているSaaSアプリが多いため見慣れないSaaSアプリもありますが、salesforce、Office 365(現Microsoft 365)、Slackなど、日本で流行しているSaaSアプリもあります。また、日本発のSaaSアプリではサイボウズもあります。

カタログに載っていなかったとしても、上述のプロトコルに対応しているSaaSアプリであれば、Workspace ONE AccessをIdPとして、SPとしての利用が可能です。

今回は、Workspace ONE AccessにMicrosoft 365を認証連携しました。Microsoft 365の連携方法は日本語でも多くのブログがあるため、本投稿でその方法をそのまま全部する記載することは避けます。
本投稿では公式マニュアルでも多くは語られておらず、また、世界中のブログ記事を見渡してみてもだれかが試して、その詳細を記載した記録を見つけられなかったオプションである「Enable Multiple O365 Email Domains」について記載します。

●「Enable Multiple O365 Email Domains」について

私の環境での設定のスクリーンショットです。
カスタムドメインはMicrosoft 365のカスタムドメインをそのまま記載していますが、IssuerURI A～Cは任意の文字列を設定しています。

このオプションの説明が掲載されているのは、以下のドキュメントです(リンクのURLは2024年5月12日時点のものです)。

この中では以下のように記述されています。

To configure multiple domains to use the Office 365 app
a. Click Advanced Properties and switch Enable Multiple O365 Email Domains to Yes.
b. Click ADD ROW.
c. Enter the Office 365 domain name and the issuer value.
To enter another domain, click Add Row. 

このオプションは、Microsoft 365で複数のカスタムドメインを使用する場合に利用する旨が記載されています。
このオプションをWorkspace ONE Accessで設定した後、Microsoft 365ではドメインごとにSet-MsolDomainAuthenticationコマンドを実行します。

＜カスタムドメインAの分のコマンド＞
Set-MsolDomainAuthentication `
-DomainName "カスタムドメインA" `
-Authentication Federated `
-IssuerUri "IssuerUriA" `
-FederationBrandName "Omnissa" `
-PassiveLogOnUri "https:///SAAS/API/1.0/POST/sso" `
-LogOffUri "https://login.microsoftonline.com/logout.srf" `
-ActiveLogOnUri "https:///SAAS/auth/wsfed/active/logon" `
-MetadataExchangeUri "https:///SAAS/auth/wsfed/active/mex" `
-SigningCertificate "MII<長いので略>=="

＜カスタムドメインBの分のコマンド＞
Set-MsolDomainAuthentication `
-DomainName "カスタムドメインB" `
-Authentication Federated `
-IssuerUri "IssuerUriB" `
-FederationBrandName "Omnissa" `
-PassiveLogOnUri "https:///SAAS/API/1.0/POST/sso" `
-LogOffUri "https://login.microsoftonline.com/logout.srf" `
-ActiveLogOnUri "https:///SAAS/auth/wsfed/active/logon" `
-MetadataExchangeUri "https:///SAAS/auth/wsfed/active/mex" `
-SigningCertificate "MII<長いので略>=="

＜カスタムドメインCの分のコマンド＞
Set-MsolDomainAuthentication `
-DomainName "カスタムドメインC" `
-Authentication Federated `
-IssuerUri "IssuerUriC" `
-FederationBrandName "Omnissa" `
-PassiveLogOnUri "https:///SAAS/API/1.0/POST/sso" `
-LogOffUri "https://login.microsoftonline.com/logout.srf" `
-ActiveLogOnUri "https:///SAAS/auth/wsfed/active/logon" `
-MetadataExchangeUri "https:///SAAS/auth/wsfed/active/mex" `
-SigningCertificate "MII<長いので略>=="

はじめ、私はこのIssuerUriの指定としてはWorkspace ONE AccessのFQDNを設定しなくてはいけないものと思っていたのですが、Microsoft Entraには以下の制約があるため、複数ドメインがある場合、Microsoft Entraではドメインごとに別のIssuerUriを設定する必要があります。

IssuerUri プロパティで複数のドメインに同じ値を設定できないという Microsoft Entra の制約にあります。

出典：Microsoft Entra ID とのフェデレーションに使用する複数ドメインのサポート

ちなみに無邪気に複数のドメインに同じIssuer URIを指定しようとしたところ、Microsoft 365では以下のようなエラーとなりました。

Try again laterとありますが、何度やっても変わらず...

おわり

このブログの人気の投稿

●久々にESXiのカスタムISOをつくってみた

ブログのタイトルに仮想化という言葉がはいっているのですが、ここ2-3年ESXiなどにちゃんと触れていないことに気づき、後ろめたい気持ちがあったので、久々に仮想化について記載いたします。 今回は自作PCをくみ上げ、ESXi 6.7をインストールしてみました。 ※7じゃなくて6.7な理由は、自作パソコンをくみ上げた後にオンボードnicがRealtekさんだったことに気づいたためです。 ESXi 6.7までは有志の方が作ったRealtekのドライバを使うことができたようなのですが、7では使えないらしく、泣く泣くこの選択になりました。。。 参考： Homelab considerations for vSphere 7 そのため、インストールではなく、カスタムイメージの作成から始まります。 ※というかインストールはいろんな人がすでにブログで書いており、現状ほぼ自分も迷わないので、忘備録としてカスタムISOの作成だけを記載します。。汗 普段Workspace ONEに触れている私は、ESXiのカスタムイメージを作成する機会が滅多になく、作成のたびに2時間程度調べて格闘しなければいけなかったので、この機会に忘備録として記載してしまいます。。 なお、必要なイメージやVIBなどは以下を利用しました。 Net55-r8168 - V-Front VIBSDepot Wiki VMware vSphere Hypervisor (ESXi) 6.7U3b(オフラインバンドル) 手順は主に以下を参考にしました。 Using vSphere ESXi Image Builder to create an installable ISO that is not vulnerable to Heartbleed Using the vSphere ESXi Image Builder CLI ●ESXiのカスタムイメージ作成をやる前に、概念をぼんやり思い出そう 今回のESXiカスタムイメージ作成では、以下二つの概念が出てきます。 ソフトウェアデポ これはVIBなどのソフトウェアモジュールをプールしたモノのようです。ESXiのオフラインバンドルや拡張VIBモジュールのzipを入手したら、Add-EsxSoftwareDepotコマンドレットを使用して、とりあえずソフトウェアデポに追加していきます
Read more »

■Microsoft Graph PowerShellモジュールでMicrosoft 365の認証をWorkspace ONE Accessにフェデレーションする

イメージ
耐寒マツバギク(2024/5/18撮影) タンポポに似て、円形に細い花弁を持っていることや、その名前からキクの仲間と思ったところ、調べてみると違う植物の仲間だそうです。 マツバギクという名称なのでなんとなくアジア原産かと思っていたら、南アフリカ原産でした。 New-MgDomainFederationConfiguration コマンドというコマンドがあるそうです。 以下URLを見てみると、 前回のブログエントリ で使用した Set-MsolDomainAuthentication コマンドの後継コマンドだそうです。 Find Azure AD PowerShell and MSOnline cmdlets in Microsoft Graph PowerShell 今回は、New-MgDomainFederationConfiguration コマンドを使用してMicrosoft 365の認証をWorkspace ONE Accessに委任しました。 本ブログエントリは2024年5月18日時点で筆者が確認できた情報をもとに作成しております。本ブログエントリを参考に同様の手順を実行する場合、その時々の各製品、サービスの提供元の公式情報をご確認ください。 ■目次 Microsoft.Graph.Identity.DirectoryManagement モジュールのインストール Microsoft 365に接続 Microsoft 365に存在するドメインのリスト表示 New-MgDomainFederationConfiguration コマンドによるフェデレーション設定 ログイン確認 その他躓いたこと ①Microsoft.Graph.Identity.DirectoryManagement モジュールのインストール Set-MsolDomainAuthentication コマンドは MSOnline というモジュールの中のコマンドですが、New-MgDomainFederationConfiguration コマンドは別の Microsoft.Graph.Identity.DirectoryManagement モジュールに含まれたコマンドのようです。 以下のコマンドでモジュールをインストールしました。 Install-Module -Name Microso
Read more »

■Workspace ONE UEM API Explorerについて

イメージ
この投稿は、 vExperts Advent Calendar 2019 - Adventar の 12日目の記事 です。 今年初めて vExperts Advent Calendar に参加させていただきます。どうぞ宜しくお願い致します。 今回の記事のテーマは、 「Workspace ONE UEM(以下UEM)の持つREST APIの動作確認をしてみること」 です。 VMware製品の持つAPIの多くは、以下のページでどのようなものがあるかを確認することが可能です。 VMware API Explorer ただ、 UEM のAPI については上記ページに記載はなく、UEMホストそのものに同様のページが設けられています。具体的には各UEMホストの、以下のURLに準備されています。 https://<UEMのFQDN>/api/help/#!/apis ※2020/9/25 追記：確認する範囲では <UEMのFQDN>でもAPI Explorerにはアクセス可能ですが、 多くのSaaS共有環境では、API のURLは普段管理コンソールとして利用するcnXXX.awmdm.comの先頭二文字のcnをasに入れ替えた値となります(API ExplorerのFQDNも本来はこちらになります)。 UAGなどでTunnelやContent Gatewayなどの構成要件として APIとの通信が必要な 場合は、 <UEMのFQDN>ではなく、 asXXX.awmdm.comなどのような、API用URL をご確認の上、通信を許可してください。なお 管理者権限にもよりますが、 API用URLについては SaaS共有環境であれば[グループと設定]＞[すべての設定]＞[システム]＞[高度な設定]＞[サイトURL]で確認可能です(2020/9/25時点)。    REST API用のURLの確認画面。 ※画像はConsole Administrator権限で確認した際のもの 上記URLにアクセスすると、 Workspace ONE UEM API Explorer が表示されます。 REST APIの動作確認というと、 postmanなどのREST Clientをインストール したり、 FireFoxやChrome
Read more »