これまでほぼWorkspace ONE UEMによるデバイス管理について書いてましたが、Workspace ONE Accessについて全然書いていなかったことに気がつきました。
つきましてWorkspace ONE Accessに関する検証をして何本かブログにしたいと思います。
まずはWorkspace ONE AccessとMicrosoft 365(Office 365)のシングルサインオン(SSO)連携についてです。
初めに記載しておきますが、Workspace ONE AccessとOffice365のSSO連携についてはVMwareさんが丁寧なガイドを公開してくれているので詳細な手順はこちらを参考にすることをお勧めします。
・Workspace ONE PoCガイド Chapter 3 Office 365連携 編
https://vmware-juku.jp/resource/workspaceone-poc-guide-ch-03/
(なのでこのブログ記事は私が個人的に概要手順を再確認したい時やコマンドをコピペするのが主な目的です…)
■環境イメージ
構成メージはこんな感じです。
ユーザーがMicrosoft 365(Office 365)にアクセスしようとすると、Workspace ONE Access(IDP)にリダイレクトされ認証が求められます。プロトコルはWS-Federationです。
検証に使用した環境ですが、Workspace ONE AccessはこれまでのWorkspace ONE UEMのブログと同様にvExpertの特典で使用可能になったTestDriveのサンドボックス環境を使用します。
vExpertの特典以外にも、VMwareのパートナー企業であれば、指定のVTSPを取得すれば利用可能になります。エンドユーザーの場合はパートナー企業やVMware社員から招待があれば期間限定ですが利用可能になります。また、VMUG Advantage メンバーの方も使えるようです。
Microsoft 365の環境も評価版環境を発行して検証しています。
・Microsoft 365 を無料で試す
https://www.microsoft.com/ja-jp/microsoft-365/try
その他必要なものとしては、独自ドメインです。
Microsoft 365(Office 365)のテナントを作ると"XXX.onmicrosoft.com"のドメインがデフォルトで作成されますが、Workspace ONE Accessなどの別のIDPにフェデレーションする場合はこの"XXX.onmicrosoft.com"のドメインでは使用できません。
よって自社(個人)で取得しているドメインが必要になります。
今回の検証では私個人がお名前.comで取得したドメインを使います。ちなみにドメイン名によっては初年度1円とかで取得できるので検証にはもってこいです。
独自ドメインはMicrosoft 365管理センターかAzure Active Directory管理センターでドメイン追加をして有効化します。
小さいですが画面キャプチャの"tech〜.work"が追加登録したドメイン(カスタムドメイン)です。
追加したカスタムドメインにプライマリのチエックがついている場合はWorkspace ONE AccessとのSSO連携ができないため"XXX.onmicrosoft.com"のドメインをプライマリにします。
SSOの動作確認用に、登録したカスタムドメインのユーザーをAzure ADに追加します。
Microsoft 365のライセンスも事前に割り当ててます。
Workspace ONE Access側にも同じくSSOの動作確認用に、アカウントを追加します。
今回SSOの動作検証だけが目的なのでローカルユーザーで作成していますが、望ましいのはActive Directory ドメインコントローラーなどからそれぞれ同期してID管理する構成です。
この件については、ブログ後半に記載します。
■設定 - Workspace ONE Access
では、SSO連携の設定を適用していきます。まずWorkspace ONE Access側から。
Workspace ONE Accessの管理画面を開き、[カタログ]タブの[新規]から新規アプリケーションを追加します。
新規SaaSアプリケーションの検索から[Office365 with Provisioning]を選択します。
事前に必要な設定が準備されているので設定が簡単です。
※"with Provisioning"の名前のとおり、Microsoft 365(Azure AD)に対してWorkspace ONE AccessからIDやグループ情報をプロビジョニングする機能があるのですがその機能は別のブログで。
名前の値がユーザーのアプリポータル画面に表示される名前なので、適宜変更します。下記はOffice365にしています。[次へ]を選択します。
"アプリケーションパラメーター"の項目で、下記項目ごとに値を設定します。
tenant・・・Office365(Azure AD)テナントのドメイン名です。Microsoft 365(Office 365)のテナントを作った時に生成された"XXX.onmicrosoft.com"の"XXX"の部分です。
issuer・・・Workspace ONE AccessのテナントのFQDNを入力します。日本のテナントだと大体"XXX.vmwareidentity.asia"とかだと思います。
[高度なプロパティ]をクリックし"カスタム属性マッピング"の値を確認します。
ADと連携した構成などの場合は大体デフォルトでOKですが、今回のブログの検証環境のように手動作成している場合へ変更が必要な場合があります。詳細は、ブログ後半に記載します。
アクセスポリシーの設定はデフォルトのまま[次へ]をクリックします。
サマリが表示されるので[保存して割り当て]をクリックします。
作成したアプリを今回のテスト用ユーザーに割り当てます。[保存]をクリックします。
これでWorkspace ONE Access側の設定は完了です。
■設定 - Microsoft 365 (Office 365)
次にMicrosoft 365 (Office 365)の設定を行いますが、まず設定のために必要な情報をWorkspace ONE Accessの画面で確認します。
Workspace ONE Accessの管理画面で、[カタログ]-[設定]を開き[SAMLメタデータソース]の"署名証明書"をコピーします。
コピーした証明書のテキストデータをテキストエディタに貼り付けます。
開始タグ“-----BEGIN CERTIFICATE-----"、終了タグ” -----END CERTIFICATE-----”を削除し、改行を削除して1行に修正します。
※テキストエディタの置換を使用して改行を一斉置換したほうがいいです。
次に、PoerShellを使用して Microsoft365に接続します。
このブログではWindows 10のPowerShellを管理者権限で起動して確認しましたが、詳細手順は以下Microsoftのドキュメントをご確認下さい。
・PowerShell を使用して Microsoft 365 に接続する
まず、MsOnlineモジュールをインストールします。
Microsoft 365(Office365)テナントに接続します。下記コマンドを実行するとポップアップで認証画面が出てくるので、Microsoft 365(Office365)テナントの管理者アカウントでログインします。
次に下記コマンドを実行して、正常にMicrosoft 365(Office365)テナントに接続できていることと、ドメインの状態を確認します。
フェデレーションするドメイン"tech〜.work"の"Authentication"が"Managed"になっていることがわかります。
ではWorkspace ONE Accessへのフェデレーションを有効化します。Set-MsolDomainAuthenticationを実行します。
1行で実行するか、下記の様にバッククォート[`]で改行します。
Set-MsolDomainAuthentication `
-DomainName "フェデレーションするOffice365(Azure AD)に登録したカスタムドメイン名" `
-Authentication Federated `
-IssuerUri "AccessのテナントFQDN" `
-FederationBrandName "VMware" `
-PassiveLogOnUri "https://<AccessのテナントFQDN>/SAAS/API/1.0/POST/sso" `
-LogOffUri "https://login.microsoftonline.com/logout.srf" `
-ActiveLogOnUri "https://<AccessのテナントFQDN>/SAAS/auth/wsfed/active/logon" `
-MetadataExchangeUri "https://<AccessのテナントFQDN>/SAAS/auth/wsfed/services/mex" `
-SigningCertificate "Accessの証明書(先程1行に変換したもの)"
正常に設定が適用された後に"Get-MsolDomain"コマンドで状態を確認すると、フェデレーションするドメイン"tech〜.work"の"Authentication"が"Federated"になっていることがわかります。
これで、設定は完了です。
設定完了後に、Microsoft 365(Office365)にテストユーザーでアクセスしてみます。
"組織のサインインページに移動します"のメッセージが表示され、自動的にWorkspace ONE Accessのログイン画面が表示されます。
Workspace ONE Accessに作成したアカウントでログインします。
Microsoft 365(Office365)のTop画面が開きます。
テストユーザーでログインできていることが確認できます。
Workspace ONE Accessのポータル画面(Intelligent Hub)からもアプリのアイコンをクリックすることでアクセスできます。
以上で、Workspace ONE AccessとOffice365のSSO連携は完了です。
Microsoft 365(Office365)はWorkspace ONE Access側にカタログとして事前準備があるので比較的簡単に設定できました。
次回ブログでは、Workspace ONE AccessからAzure AD(Microsoft 365)へのIDプロビジョニングを検証してみたいと思います。
■Appendix - Immutable IDとIDソースについて
Workspace ONE AccessとMicrosoft 365(Office365)のSSO連携の多くの場合の構成では、Active Directory ドメインコントローラーに登録されたIDやグループ情報をWorkspace ONE AccessとAzure ADへそれぞれのコネクターを使って同期します。
この場合、Active Directory ドメインコントローラーに登録されたアカウントのなにかの属性を使って同じアカウントだということを判別しSSOを実現します。
Active Directory ドメインコントローラーからID情報を同期されたAzure ADでは一般的に"ObjectGUID"(または"ms-DS-ConsistencyGuid")を"Immutable ID"として登録します。
SSO時、Workspace ONE Accessでユーザーが取得したセキュリティトークンに埋め込まれた"UPN (User Principal Name) "と"ObjectGUID"の値をAzure AD側で照合し、ユーザーを識別します。
今回の検証時の構成はActive Directory ドメインコントローラーなどIDソースとなる製品が無いため、それぞれのサービスにアカウントを手動作成していますが、その場合"同じユーザーであること"を識別するための属性をどうすか考える必要があります。
例えば、下記イメージ図のようにUPNと従業員IDを使って同じユーザーであることを識別します。
また、今回の検証で知ったのですがAzure ADに手動作成したユーザーは"Immutable ID"の値がない為、手動で設定する必要がありました。
#Immutable IDの確認
Get-MsolUser -UserPrincipalName "対象ユーザーの UPN" | select ImmutableID
#Immutable IDの手動設定
Set-MsolUser -UserPrincipalName "対象ユーザーの UPN" -ImmutableId "値(検証時は従業員番号)"
Workspace ONE Accessのユーザー情報にも従業員IDとプリンシパル名(UPN)を手動設定しました。
また、セキュリティトークンに埋め込まれる値を、従業員IDに変更する必要があるため、Workspace ONE AccessのOffice365アプリの設定を開き、[構成]のカスタム属性マッピングで"ImmutableID"の値を従業員ID"${user.employeeID}" に変更しました。
■Appendix - フェデレーションの解除
検証が終わった後にフェデレーションを解除するコマンドを備忘として記載します。
Set-MsolDomainAuthentication -Authentication Managed -DomainName "ドメイン名"
正常に設定が適用された後に"Get-MsolDomain"コマンドで状態を確認すると、フェデレーションしていたドメイン "tech〜.work"の"Authentication" が "Managed" になり、元の状態に戻っていることがわかります。