🛠️

Office 365: GoogleをメインのIdPに使う構成方法

14 min read

概要

Google WorkSpaceをメインに利用する組織で、PCにMicrosoft Officeは必要、というケースは多く発生すると思う。そのようなとき、Microsoft 365 Apps for Businessを使うケースが多いと思うのだが、ユーザの認証にAzure ADがついてきてしまう。abc.onmicrosoft.comみたいなドメインで作成されるやつ。

一人情シス筆頭に少ない人数で管理している組織では、Azure ADとGoogleと両方個別管理するのは微妙に面倒くさい。GoogleをIdPにして、Microsoft 365はライセンスの付与・管理だけにしたい、と考える方も多いのではないだろうか。

そこで手順を検索してみるのだが、Azure ADをメインにGoogleを使う方法は沢山見つかるものの、その逆のGoogle WorkSpaceをAzure ADのIdPとして利用する手順は、英語/日本語含めて少ない。実際にやってみると、微妙なハマりポイントがあって複数のソースを探してやらなければならなかったこともあり、ざっくり手順をまとめておこうと思う。スクリーンショットを多様しているが、MicrosoftもGoogleも改変しなければ技術資料への利用OK、というルールがあるようなので、一部隠しているが読む人が理解しやすいように添付している。もし著作権上問題、ということであれば、取り除くので著者まで一報いただければ幸いです。

この手順は、新規にAzure AD環境を作る場合と、すでに onmicrosoft.com で運用始めちゃったけど、GoogleをIdPとして使うように変えたい、というケースにも対応している。Azure ADをすでに持っている方は、(環境準備)部分を飛ばして、手順1から実施してください。

(環境準備) 新規にApps for Businessを使う場合

今までOffice 365を使っていなくて、これからApps for Businessを使う、というケースでは、Microsoftが30日限定の評価版の提供を行っているので、評価版の取得から開始すると良い。

このページから評価版を選んで、会社のメールアドレスでアカウントを登録し、ドメインを登録すると、Azure AD環境の構築が整う。なお、支払い情報としてクレジットカードを入力しないと、Apps for Businessの評価版の有効化まで進まないのだが、実のところAzure ADの環境は、アカウントを作ってドメインを取得した③の段階で作成されている。評価版の有効化は、Office 365の管理画面からもできるので、ここでは、評価版の登録は最後までやらずに、以下の画面の「③仕事用IDの作成」のところで「次へ」を押して、ドメイン登録が終わった段階で中断する手順で記載している。

評価版の登録

2021年6月時点ではこれで問題ないのだが、将来的には変わるかもしれないので、そのときはご容赦を。

③の段階でドメインが登録できない場合は、すでに誰かが会社ドメインでO365のテナントを作っている可能性があるので、社内で確認すること。

それでは、ドメインのところまで終わったら、Azure ADに入る。

特にパスワード入力に進むのでもなく、Azure ADの管理画面に入れていると思う。

この状態では、まだMicrosoft 365 Apps for Businessのトライアルは有効化されていないので、今度はMicrosoft 365の管理画面に進む。

左のメニューから「課金情報」をクリックして展開、「サービスを購入する」をクリックして、検索画面に「apps」と入れて検索すると、Microsoft 365 Apps for Businessが見つかると思う。

評価版の検索

クリックして進むと、評価版を有効化するリンクがあると思うので、それをクリックし、購入(実際には課金されない)に進む。

再度左のメニューから「お使いの製品」に進むと、評価版がリストされていると思う。

お使いの製品

以上で、とりあえずOfficeの評価版ライセンスとAzure ADのテナントは準備できた。

1. Google WorkSpaceドメインの追加

続いて、Google WorkSpaceで利用しているドメインをAzure ADに追加する。この作業を行うには、使用しているドメインのDNSサーバにTXTレコードを追加しなければならないので、DNS管理者と連携して作業する必要がある。

カスタムドメイン管理画面に入ると、今はonmicrosoft.comのドメインだけが表示されていると思うので、Add custom domainをクリックして、Google WorkSpaceで利用しているドメインを追加する。

AADドメイン管理画面

カスタムドメインの追加

追加すると、ドメインの所有を確認するためのTXTレコードをDNSに登録するよう要求される。DNS管理者に、画面に表示された MS=ms90795453 (この値は自動生成されて毎回変わる)の部分のTXTレコードを追記するよう依頼しよう。

DNS側でTXTレコードを追加して、名前検索できるようになったか確認する。下は、Macでdigコマンドで確認する場合の例。dig TXT <ドメイン名>で、TXTレコードが正しく追加されたか確認できる。

~ % dig TXT *******.co.jp
; <<>> DiG 9.10.6 <<>> TXT *******.co.jp.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47027
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;*******.co.jp.		IN	TXT

;; ANSWER SECTION:

*******.co.jp.        3600 IN  TXT "MS=ms90795453"

Windowsの場合は、nslookupを使う。set type=TXTと打つと、TXTレコードの検索ができる。

C:\>nslookup
既定のサーバー:  resolver1-fs.opendns.com
Address:  208.67.222.123

> set type=TXT
> *******.co.jp.
サーバー:  resolver1-fs.opendns.com
Address:  208.67.222.123

権限のない回答:
*******.co.jp      text =
                   "MS=ms90795453"

TXTレコードが確認できたら、Azure ADの管理画面でverifyボタンを押して、検証を完了させる。完了すると、2つのドメインが登録された状態になると思う。

(補足) 謎エラーが出てドメインが追加出来ないケース

ここで、以下のようなエラー画面が出て、ドメインがスムーズに登録できないケースがあるかもしれない。

こういうときは、会社の誰かが、PowerBIかDRM(Digital Rights Management)の評価を過去に実施したことがあって、Google WorkSpaceのドメインがすでに使われているケースに該当する。
Microsoftのサービスは、無償のサービスについても、裏側にAzure ADがいるらしく、そこで登録予定のドメイン名が使われていると、このエラー画面に到達することになる。
こういう場合は、Force domain takeoverのオプションで強引にManaged ADに移行させるのも一つだけど、一応誰に使われているのか確認して移管の必要性をチェックしてから実行した方が安全。ではどうやるか?

Google Workspaceのメールアドレスを使ったアカウントでPowerBIのアカウントを作成し、無償評価を開始して、ドメインの管理者を奪う。

ログインしたら、左上のメニューから「管理」に入って管理者権限を奪取する。

奪取する際には、TXTレコードで管理権限を持っていることを証明しなければならない。

TXTレコード

先程のAzure AD用にTXTレコードを追加したのと同様に、DNS管理者にTXTレコードの追加を依頼する。

レコードを追加した後、「レコードを追加しました」をクリックすると、管理者になれるので、ユーザ一覧から、社内の誰が使っているかチェックして、PowerBIを消して良いかを確認する。もしまだ継続利用必要、という場合は、アカウントをonmicrosoft.comのドメインに変更して、Google WorkSpaceのドメインを使っているユーザーが一人もいない状態にする。

以上の手順により、Google WorkSpaceのドメインがAzure ADに追加できるようになる。

2. Google SAMLアプリの追加

続いて、Google WorkSpace側で、SAMLアプリを登録する。こちらは、Google WorkSpaceの管理者アカウントが必要。

Add AppsからSearch for Appsをクリック。
search for apps

Microsoft Office 365を探して追加。

o365 web app

証明書をダウンロードして、SSO URLとEntity IDをコピーしておく。

SSO URL: https://accounts.google.com/o/saml2/idp?idpid=●●●●●●●●●
Entity ID: https://accounts.google.com/o/saml2?idpid=●●●●●●●●●

saml

次のservice provider detailsのところは特に変更必要なし。画面は「署名付き応答」にチェック入ってないけど、これチェック入れること。忘れた場合あとからチェックは入れられる。次へ進む。

service provider detail

続いて、属性マッピングはprimary email addressをIDPemailにマッピング。以上で完了。

Google WorkSpace上にSAMLアプリが登録される。

3. Azure ADのユーザ作成

3.1 Powershell環境の準備

この後の作業では、MSOnlineというPowershellモジュールを使った作業が必要になるので、Windows PCにインストールする。なお、Mac版のPowershellではサポートされていないようなので、Macしか手元にない場合は、Windows環境をVMなどで準備する必要がある。

Microsoft Windows [Version 10.0.19042.804]
(c) 2020 Microsoft Corporation. All rights reserved.
                                                                                                                       C:\Windows\system32>powershell

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

新しいクロスプラットフォームの PowerShell をお試しください https://aka.ms/pscore6

PS C:\Windows\system32> Install-Module MSOnline

MSOnlineをインストールする際には、NuGetのインストールと信頼されていないレポジトリの警告について聞かれるので、どちらも「Y」を入力してインストールする。

Office 365の管理アクセスをするには、Connect-MsolServiceコマンドを使う。
コマンドを打つと、ポップアップ画面でMicrosoftのログイン画面が出てくるので、Global Admin権限のあるユーザ(onmicrosoft.comドメインのアカウント)でログインする。Get-MsolDomainコマンドを打つと、onmicrosoft.comドメインと、検証の完了したGoogle Workspaceドメインの2つが見えていると思う。

PS > Connect-MsolService
PS > Get-MsolDomain

Name                 Status   Authentication
----                 ------   --------------
****.onmicrosoft.com Verified Managed
*****.co.jp          Verified Managed

3.2 テストユーザでまずはSSO動作の確認を実施

Google WorkspaceドメインのユーザをAzure ADに追加するとともに、そのユーザが所属するGoogle WorkspaceのOUまたはGroupに、先ほど2で作成したMicrosoft Office 365アプリを有効化する。
以下の例では、Google上で、テストに参加するメンバーだけが入っている「Office365 test users」というグループを作っていて、そのGroupでSAMLアプリを有効化している。
アプリの有効化は、上の手順2の最後の画面のところで、「User Access」から設定する。

ここで注意点を一つ。Azure ADやOffice 365の管理画面からテスト用ユーザを足した場合、GoogleとのSAML認証に必要な"ImmutableID"というパラメータに値がセットされていないので、ログインに失敗する。このImmutableIDをGUIから設定する方法がないので、Powershellで手動でセットしないといけない。testuser@*****.co.jpというアカウントのImmutableIDをセットする方法は以下の通り。

$userUPN = "testuser@*****.co.jp"
Get-MsolUser -UserPrincipalName $userUPN | Set-MsolUser -ImmutableId $userUPN

ちなみに、後ほどGoogleで自動プロビジョニングを有効化した際には、ImmutableIDに値がセットされた状態でAzure AD側のユーザが作成されるので、テストの時だけ注意すればOK。

テストユーザの作成が完了したら、ドメインの設定をManagedからfederatedに切り替える。これにより、Federationが有効化されて、GoogleをIdPとして利用するように変わる。切り替えにあたっては、手順2でコピーしたSSO URLとEntitiy ID、証明書をパラメータとしてセットする必要がある。
以下のcert(証明書)の部分は、改行など取り除いて、1行で全て貼り付ける。

PS > $ssoUrl = "https://accounts.google.com/o/saml2/idp?idpid=●●●●●●●●●"
PS > $entity = "https://accounts.google.com/o/saml2?idpid=●●●●●●●●●"
PS > $domain = "*******.co.jp"
PS > $cert = "MIIDdDCC...(snip)...1xNkb"
PS > Set-MsolDomainAuthentication -Authentication Federated  -DomainName $domain -ActiveLogOnUri $ssoUrl -PassiveLogOnUri $ssoUrl -IssuerUri $entity -LogOffUri $ssoUrl -SigningCertificate $cert -PreferredAuthenticationProtocol SAMLP
PS > Get-MsolDomain

Name                 Status   Authentication
----                 ------   --------------
****.onmicrosoft.com Verified Managed
*******.co.j         Verified Federated

Federatedに切り替えが完了したら、ログインをテストする。

テストユーザでログインしているChromeを立ち上げて、Google appsから、Microsoft Office 365のアプリを選択する。

リダイレクトされて、officeのサイトが表示されれば、SSOは正しく動作している。

3.3 自動プロビジョニングの有効化

続いて、自動プロビジョニングの有効化をGoogle側で行う。Microsoft Office 365アプリケーションの自動プロビジョニングをONにすると、機能が有効化されたユーザを自動でAzure AD側に同期する。

Attribute Mappingの設定は以下のように行う。

Google Azure AD
Address > Locality city
Address > County country
Employee details > Department department
Additional Details > Formatted Name displayName* (required)
Basic Information > First Name givenName
Employee details > Title jobTitle
Alias Name mailNickname* (required)
Phone > Value mobilePhone
Basic Information > Username onPremisesImmutableId* (required)
Address > Postal code postalCode
Address > Region state
Address > Value streetAddress
Basic Information > Last name surname
Basic Information > Username userPrincipalName* (required)
- userType

最後のuserTypeは、Azure AD側は、memberかguestかの2つの値しか受け取らないので、ここでは特にセットしていない。

Auto provisioningをONにしてAuthorizeしたら完了。Authorizeする際には、Azure ADのGlobal Adminのアカウントで承認する必要あり。

Google側が以下のように「Syncing Active」の表示になっていればOK。

続いて、先程作成したテストグループにもう一名追加してみて、自動でAzure AD側に追加されるかをチェック。同期まで数分〜10数分かかるが、動作していれば自動で作成されるはずだ。プロビジョニングに関するログは、view sync logのリンクをクリックしてAuditログを見ると閲覧できる。

3.4 すでにonmicrosoft.comでユーザを作っていて移行する場合

すでにAzure ADにonmicrosoft.comでアカウント発行しているケースでは、onmicrosoft.com の既存ユーザをGoogle Workspaceのユーザに変更する必要が出ると思う。
この作業では、PowershellでUPNを変更する必要がある。

3.3までの手順で、今はfederationを有効にした状態だが、federationが有効な状態ではUPNは変更できない。よって、Powershellで一度Federationを切る必要がある。

PS > Set-MsolDomainAuthentication -Authentication managed -DomainName <ドメイン名>

対象のユーザを、old、new、というカラムに保存したCSVファイルを作って、以下のPowershellコマンドでUPNを更新する。ImmutableIDのセットも忘れずに。

old new
user01@*****.onmicrosoft.com user01@*****.co.jp
user02@*****.onmicrosoft.com user02@*****.co.jp
user03@*****.onmicrosoft.com user03@*****.co.jp
Import-CSV .\user-list.csv | foreach {
Set-MsolUserPrincipalName -UserPrincipalName $_.old  -NewUserPrincipalName $_.new
Set-MsolUser -UserPrincipalName $_.new -ImmutableID $_.new
}

変更が終わったら、再度Federatedに切り替えて完了 (上の手順3.2のコマンドを参照)

後は、GoogleのOU全体でMicrosoft Office 365アプリを有効化するか、グループを新たに作って、そこにユーザを追加するか、自分の組織の運用形態にあった形で設定すればOK。

4. ユーザへの案内

最後はユーザへの案内です。
まずは、Chromeのプロファイルの使い方を教えて、Google WorkSpaceにログインして同期をONにした状態で使う方法を教えて下さい。そして、Google AppsからMicrosoft Office 365アプリを選択するだけで、Officeサイトにいけることを教えましょう。

続いて、Microsoft Officeアプリで、ログインして利用する方法を教えて下さい。
上の手順3.4でUPNを変更しているユーザについては、Windowsの場合は、Officeアプリのログインユーザも自動で切り替わっているので、特に追加作業は必要ないでしょう。職場のアカウントで、Google WorkspaceのアカウントをWindows上で足す方法を案内してもいいかもしれません。

一方で、Mac OSユーザについては、Google Workspaceのアカウントでログインしなおす必要があります。
Word/Excel/PowerPointなど、アプリを開いて左上のアカウント名部分を開いて、ログインします。

Googleにリダイレクトされますが、このときはメールアドレスには入力引き継がれません。もう一度、Googleのアカウントを入れて、ログインして完了。

2step VerificationをGoogle側で有効にしていれば、このOfficeからのログインでも2FAは実行されます。

おわりに

1点だけ、この手法での課題が1つあります。

私がいくつか検証している限り、Windows PCをAzure AD Joinして、PCのログインアカウントをAzure ADで管理(つまりGoogleアカウントでPCも管理)しよう、というケースが正しく動作しません。したがって、Windows PCにアカウントを追加するときは、「職場アカウント」のところでAzure AD Joinを選んではいけません。Azure AD Joinは普通に完了するのですが、Azure ADのアカウントではPCにログインできない状態になります。

ただ、Windows PCを初期化して、初期セットアップ時にGoogleとSAML連携されたアカウントでAzure AD Joinするとなぜか普通に使えます。Windows Helloの設定まで初期セットアップで完結すると、GoogleへのWeb認証が走らないから、なのかもですが、これは引き続き検証していこうと思います。