Office 365: GoogleをメインのIdPに使う構成方法
概要
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の作成」のところで「次へ」を押して、ドメイン登録が終わった段階で中断する手順で記載している。
それでは、ドメインのところまで終わったら、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で利用しているドメインを追加する。
追加すると、ドメインの所有を確認するための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レコードで管理権限を持っていることを証明しなければならない。
先程の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をクリック。
Microsoft Office 365を探して追加。
証明書をダウンロードして、SSO URLとEntity IDをコピーしておく。
SSO URL: https://accounts.google.com/o/saml2/idp?idpid=●●●●●●●●●
Entity ID: https://accounts.google.com/o/saml2?idpid=●●●●●●●●●
次のservice provider detailsのところは特に変更必要なし。画面は「署名付き応答」にチェック入ってないけど、これチェック入れること。忘れた場合あとからチェックは入れられる。次へ進む。
続いて、属性マッピングは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の設定は以下のように行う。
| 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アプリで、ログインして利用する方法を教えて下さい。
上の手順３．４でUPNを変更しているユーザについては、Windowsの場合は、Officeアプリのログインユーザも自動で切り替わっているので、特に追加作業は必要ないでしょう。職場のアカウントで、Google WorkspaceのアカウントをWindows上で足す方法を案内してもいいかもしれません。
一方で、Mac OSユーザについては、Google Workspaceのアカウントでログインしなおす必要があります。
Word/Excel/PowerPointなど、アプリを開いて左上のアカウント名部分を開いて、ログインします。
Googleにリダイレクトされますが、このときはメールアドレスには入力引き継がれません。もう一度、Googleのアカウントを入れて、ログインして完了。
2step VerificationをGoogle側で有効にしていれば、このOfficeからのログインでも2FAは実行されます。
おわりに
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認証が走らないから、なのかもですが、これは引き続き検証していこうと思います。
Discussion
他の記事と比べて群を抜いて分かりやすい記事でした。
ただ、自分も同じような形でやってみたのですが、画像のようにうまく引き継がれずエラーが出てしまいます。
どうしたらよいか分からないのですが、ご教授いただけますでしょうか。
これは、federation realm object does not existと書いてあるので、GoogleのSSO URLが存在しないと言ってますね。どのタイミングで出ているエラーですかね。
Powershellでfederatedに切り替える段階なのか、SSOでアクセスしようとして出ているエラーなのか。SSOの場合は、GoogleのSAML AppがOnになっていないとか、SAML AppをOnにしたけど実際にOnになるまで若干のタイムラグがあってアクセスできない (Chrome Appからアクセスすると403とかになる)、とか色々あります。
ChromeのGoogle Appランチャー（画面右側にある9点リーダ）に表示されているMicrosoft365からアクセスした際に表示されます。
Microsoft365のサインインページからサインインしようとしても、「組織のサインインページにアクセスしています」が表示された後に、同じような画面が表示されます。
Google側もSAML AppはONになっています。
となると、たぶん、AzureとGoogleとでIssuer URLの値が違っているのかも。 ChromeのDeveloper Toolを使って、SAMLの中身見て、Issuer URLの値が双方でマッチしているか、確認すると良さそう。
記事を拝見しての質問です。
運用中のGoogleworkspaceのドメインを【M365管理センター】もしくは【AzureAD】へ
DNSレコード・TXTレコードにて追加した以降につきまして、
現状Gmailをメインで利用していますが、Officeのメールも同ドメイン(Googleユーザー)で利用することとなるかと認識しています。
メールの受信の動きに関しまして、受信先が競合してしまいどちらのメールにも届かないといったことはありますでしょうか？もしくはどちらかが優先してしまい一方しか届かない等の動きがあったりしますでしょうか？
もしご存知でしたらご教示いただけますと幸いです。
通常、Gmailをメインで使う組織は、Exchange onlineは使わない、という形にしたほうが幸せ。
何らかの理由で両方使わなければいけない場合は、ドメインを分けるほうが楽。
一緒のドメインで使いつつ、ユーザによってどちらにするかを制御したい、という場合は、Gmailをメインで受信するようにして、Exchangeを使うユーザだけExchangeに転送、というやり方ができます。
Gmailメインの場合は、GmailのDefault route機能を使って、GmailでExchange側に転送が必要なアドレスのメールを受け取ったら、GmailからOffice 365に転送する、という実装ができます。
Gmailの設定でメールの転送先としてのEOP(Exchange Online Protection)のサーバを追加する。 追加するEOPのホスト名は、Microsoft 365管理センターのドメインの設定画面から確認できる。(Microsoft 365管理センター > 設定 > ドメイン)
Gmailで受信したメールのうち、O365で受け取る必要のあるメールをEOP側に転送するルールを作る。
続いて、O365側で、Gmailと同じドメインでメールを送信できるように設定します。
デフォルトでは、登録したドメインがAuthoritativeとしてExchangeサーバが設定されている。これは、メールを最終的に受信するための設定になっていて、Azure ADのGAL(Global Address List)を見て配送先が不明のメールについては、NDR (Non-delivery report)を返す役割になる。
ドメインがAuthoritativeのままOutlookからGmailのドメインにメールを送信すると何が起こるか？というと、ドメインはExchangeにAuthoritativeとして設定されているので、自ドメイン宛のメールがユーザがから送信されると、自分のExchangeのメールボックスがあると想定して処理される。ところが、Gmailメインの会社の場合、全員のOutlookのmailboxを有効化しているわけではないため、送信先ユーザがGmailにしかメールボックスがないアカウントの場合、mailboxが見つからない、としてNDRを返すことになる。Exchangeサーバが最終配送先となるMailboxであればこの設定でいいのだが、今回のようにメインのmailboxがGmail側にある場合は、Exchangeサーバ上にmailboxが見つからない場合にGmailに転送する動きが取れないといけない。
この動きを可能にするには、ExchangeサーバのAccepted Domainsの設定で、AuthoritativeからInternal Relayに設定変更する必要がある。
さらに、Gmailから転送されるメールがEOPでspam扱いされないための工夫なんかも、Mail flowルールを使って色々検討する必要があります。Gmailで転送するときに、特殊なヘッダーを突っ込んで、それを信頼するようにEOP側を構成する、とか。
一応、うちの会社ではこの方式で一部利用していて、半年くらい運用してますが、特に大きな問題にはなっていません。ただ、かなりトリッキーな使い方なので、検証して大丈夫か確認してからやることをおすすめします。
あくまでもTXTレコード追加はドメイン所有の確認ということと認識しました。
同ドメインの同アカウントでGmail、Exchange両方を使わない限り影響は生まないと
理解しました。
ご教示ありがとうございます。
メールの配送先はMXレコードで制御されてます。今はGmailのサーバーが指定されていると思います。
この記事のTXTレコードはおっしゃる通り、ドメインの所有確認のためだけに使います。
私も2019年頃から同じ設定で運用しています。
年に何回かはGoogle WorkspaceからMicorosft 365へのユーザの同期（プロビジョニング）が止まってしまう問題が発生しています。