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

耐寒マツバギク(2024/5/18撮影)
タンポポに似て、円形に細い花弁を持っていることや、その名前からキクの仲間と思ったところ、調べてみると違う植物の仲間だそうです。
マツバギクという名称なのでなんとなくアジア原産かと思っていたら、南アフリカ原産でした。

New-MgDomainFederationConfiguration コマンドというコマンドがあるそうです。
以下URLを見てみると、前回のブログエントリで使用した Set-MsolDomainAuthentication コマンドの後継コマンドだそうです。

今回は、New-MgDomainFederationConfiguration コマンドを使用してMicrosoft 365の認証をWorkspace ONE Accessに委任しました。
本ブログエントリは2024年5月18日時点で筆者が確認できた情報をもとに作成しております。本ブログエントリを参考に同様の手順を実行する場合、その時々の各製品、サービスの提供元の公式情報をご確認ください。

■目次

  1. Microsoft.Graph.Identity.DirectoryManagement モジュールのインストール
  2. Microsoft 365に接続
  3. Microsoft 365に存在するドメインのリスト表示
  4. New-MgDomainFederationConfiguration コマンドによるフェデレーション設定
  5. ログイン確認
  6. その他躓いたこと

①Microsoft.Graph.Identity.DirectoryManagement モジュールのインストール

Set-MsolDomainAuthentication コマンドは MSOnline というモジュールの中のコマンドですが、New-MgDomainFederationConfiguration コマンドは別の Microsoft.Graph.Identity.DirectoryManagement モジュールに含まれたコマンドのようです。

以下のコマンドでモジュールをインストールしました。

Install-Module -Name Microsoft.Graph.Identity.DirectoryManagement

②Microsoft 365に接続

モジュールのインストールが完了したら、以下のコマンドを使用して接続します。

Connect-MgGraph -Scopes "User.ReadWrite.All", "Group.ReadWrite.All", "Domain.ReadWrite.All", "Directory.ReadWrite.All", "Directory.AccessAsUser.All"

※Microsoft Graph 関連のPowerShellでは、接続時に権限を指定しないといけないところが MSOnline モジュールの Connect-MsolService コマンドと異なっており、最初少し面喰いました。
※上記のコマンド例は、あくまで New-MgDomainFederationConfiguration に必要そうな権限を片っ端から追加してみたもののため、もしかしたら不要な権限がついているかもしれません。

入力すると、ポップアップが表示され、ID/Passを入力など入力してユーザー認証後、コマンドで入力した権限を使用するか否かチェックボックスにチェックをつけます。

よく見たら、このスクリーンショットの中でも同じ権限を重複して入力していますが、おなじものは一つでよいはずです。

認証が終わったら認可？のような形で実行可能な機能へのアクセス許可を得ます。

③Microsoft 365に存在するドメインのリスト表示

以下のコマンドを使用して、ドメインの一覧を表示します。

そのドメインの認証がEntra IDで行われているか、ほかのサードパーティIDPで行われているかが、ManagedかFederatedで表示されます。

Get-MgDomain

今回は上から４番目のドメインの認証をWorkspace ONE Accessにフェデレーションします。

④New-MgDomainFederationConfiguration コマンドによるフェデレーション設定

以下のようなコマンドで、対象のドメインをフェデレーションします。

New-MgDomainFederationConfiguration `
-DomainId "my.custom.domain" `
-DisplayName "Omnissa" `
-IssuerUri "https://Omnissa2024.0515" `
-PreferredAuthenticationProtocol "saml" `
-ActiveSignInUri "https://fqdn.of.my.workspaceoneaccess/SAAS/auth/wsfed/active/logon" `
-PassiveSignInUri "https://fqdn.of.my.workspaceoneaccess/SAAS/API/1.0/POST/sso" `
-SignOutUri "https://login.microsoftonline.com/logout.srf" `
-federatedIdpMfaBehavior "acceptIfMfaDoneByFederatedIdp" `
-MetadataExchangeUri "https://fqdn.of.my.workspaceoneaccess/SAAS/auth/wsfed/active/mex" `
-SigningCertificate "MII....==" | Format-List

これで、SSOを設定できました。
ちなみに、上記コマンドではFormat-Listに最後に出力を渡しているため、実行すると設定内容が一覧表示で表示されます。
設定後に設定内容のみを表示したい場合は以下のコマンドを実行します。

Get-MgDomainFederationConfiguration -DomainId "my.custom.domain" | Format-List

⑤ログイン確認

ログイン確認時の画面遷移は以下の通りです。

Microsoft 365のログイン画面で、ユーザーIDを入力します。
（今回はメールアドレスとしています）

Workspace ONE Accessの画面にリダイレクトされます。
ユーザー名を入力し、そのあとに続く認証ポリシーで定められたユーザー認証操作を行います
(詳細のスクリーンショットは割愛していますが、今回はユーザー名/パスワードの単一要素で認証しています)。

Workspace ONE AccessからMicrosoft 365にリダイレクトされ、戻ってきます。

ログインが完了しました！

⑥その他躓いたこと

・federatedIdpMfaBehaviorオプションについて

federatedIdpMfaBehaviorオプションを使用しない場合、「New-MgDomainFederationConfiguration : FederatedIdpMfaBehavior cannot be empty」というエラーが表示されました。

エラーが表示されたので、フェデレーションされていないのかと思いきや、Get-MgDomainコマンドではfederatedと表示されます。

しかし Get-MgDomainFederationConfiguration コマンドでも詳細を表示することができません。

なんだかおかしいので、一度 Remove-MgDomainFederationConfiguration コマンドでManagedの設定に戻そうと思ったのですが、このコマンドは Get-MgDomainFederationConfiguration で確認できるフェデレーション設定ごとのIDが必要です。そのため Remove-MgDomainFederationConfiguration コマンドは使えず、結局以下のように Set-MsolDomainAuthentication コマンドを使用してもとに戻しました。

Set-MsolDomainAuthentication -DomainName "my.custom.domain" -Authentication Managed

本ブログエントリ作成時点では幸いなことにまだ使えたので、Set-MsolDomainAuthenticationでもとに戻しました。
※正しい戻し方がもっと他にあるのかもしれませんが。。

・WS-Federation？SAML？どっちなんだい？

前回のブログでMicrosoft 365の認証をWorkspace ONE Accessにフェデレーションした際は、WS-Federationというプロトコルを選択してフェデレーションしています。
実際、前回のブログで設定したドメインに対してSet-MsolDomainAuthenticationコマンドを実行してみたら、wsFedと表示されました。

Get-MgDomainFederationConfiguration -DomainId my.custom.domain | Format-List

New-MgDomainFederationConfigurationコマンドも、実行するとデフォルトでWS-FederationでWorkspace ONE Accessに認証を委任してくれます。
ただ、2024年5月18日時点では、New-MgDomainFederationConfigurationコマンドを使用してWS-FederationでWorkspace ONE Accessに認証を委任しても、SP Initiated SSOを実施すると、Workspace ONE Access側にリダイレクトされたときに以下のような画面になり、正常にユーザー認証が行えない状況となりました(IdP Initiated SSOであれば成功しました)。

PowerShell内で認証プロトコルとしてsamlを指定したところ、上記の画面は解消し、ユーザー認証を行ってログインが行えるようになりました。
※なお、Workspace ONE Access側は、前回のブログポストと同じWebアプリケーションのエントリを使用しており、WS-Federationで設定されています。

・実行したいコマンドに必要な権限について

例としてGet-MgDomainに必要な権限を調べるときは、以下のコマンドが便利でした。

(Find-MgGraphCommand -Command Get-MgDomain).permissions

今ログイン中のアカウントがどんな権限を持っているかは、以下で確認できました。

(Get-MgContext).scopes

このブログの人気の投稿

●久々に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 »

■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 »