🛠️Office 365: GoogleをメインのIdPに使う構成方法2021/06/22に公開9件GoogleMicrosofttechDiscussionakimo41102022/01/20他の記事と比べて群を抜いて分かりやすい記事でした。 ただ、自分も同じような形でやってみたのですが、画像のようにうまく引き継がれずエラーが出てしまいます。 どうしたらよいか分からないのですが、ご教授いただけますでしょうか。 cestquigucci2022/01/23これは、federation realm object does not existと書いてあるので、GoogleのSSO URLが存在しないと言ってますね。どのタイミングで出ているエラーですかね。 Powershellでfederatedに切り替える段階なのか、SSOでアクセスしようとして出ているエラーなのか。SSOの場合は、GoogleのSAML AppがOnになっていないとか、SAML AppをOnにしたけど実際にOnになるまで若干のタイムラグがあってアクセスできない (Chrome Appからアクセスすると403とかになる)、とか色々あります。 返信を追加akimo41102022/01/23ChromeのGoogle Appランチャー（画面右側にある9点リーダ）に表示されているMicrosoft365からアクセスした際に表示されます。 Microsoft365のサインインページからサインインしようとしても、「組織のサインインページにアクセスしています」が表示された後に、同じような画面が表示されます。 Google側もSAML AppはONになっています。 返信を追加cestquigucci2022/01/25となると、たぶん、AzureとGoogleとでIssuer URLの値が違っているのかも。 https://docs.microsoft.com/en-us/troubleshoot/azure/active-directory/authentication-fails-with-error ChromeのDeveloper Toolを使って、SAMLの中身見て、Issuer URLの値が双方でマッチしているか、確認すると良さそう。 https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/troubleshoot_saml_view-saml-response.html 返信を追加help2022/05/24記事を拝見しての質問です。 運用中のGoogleworkspaceのドメインを【M365管理センター】もしくは【AzureAD】へ DNSレコード・TXTレコードにて追加した以降につきまして、 現状Gmailをメインで利用していますが、Officeのメールも同ドメイン(Googleユーザー)で利用することとなるかと認識しています。 メールの受信の動きに関しまして、受信先が競合してしまいどちらのメールにも届かないといったことはありますでしょうか？もしくはどちらかが優先してしまい一方しか届かない等の動きがあったりしますでしょうか？ もしご存知でしたらご教示いただけますと幸いです。 cestquigucci2022/05/24通常、Gmailをメインで使う組織は、Exchange onlineは使わない、という形にしたほうが幸せ。 何らかの理由で両方使わなければいけない場合は、ドメインを分けるほうが楽。 一緒のドメインで使いつつ、ユーザによってどちらにするかを制御したい、という場合は、Gmailをメインで受信するようにして、Exchangeを使うユーザだけExchangeに転送、というやり方ができます。 Gmailメインの場合は、GmailのDefault route機能を使って、GmailでExchange側に転送が必要なアドレスのメールを受け取ったら、GmailからOffice 365に転送する、という実装ができます。 Exchange Online Protectionをhostsとして追加 Gmailの設定でメールの転送先としてのEOP(Exchange Online Protection)のサーバを追加する。 追加するEOPのホスト名は、Microsoft 365管理センターのドメインの設定画面から確認できる。(Microsoft 365管理センター > 設定 > ドメイン) GmailのDefault Route設定 Gmailで受信したメールのうち、O365で受け取る必要のあるメールをEOP側に転送するルールを作る。 続いて、O365側で、Gmailと同じドメインでメールを送信できるように設定します。 SPFレコードにO365のサーバを追加して、O365から送信しても大丈夫なようにする DKIMをO365用に設定して署名をONに Accepted Domainの設定変更をする。 デフォルトでは、登録したドメインが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側を構成する、とか。 一応、うちの会社ではこの方式で一部利用していて、半年くらい運用してますが、特に大きな問題にはなっていません。ただ、かなりトリッキーな使い方なので、検証して大丈夫か確認してからやることをおすすめします。 help2022/05/26あくまでもTXTレコード追加はドメイン所有の確認ということと認識しました。 同ドメインの同アカウントでGmail、Exchange両方を使わない限り影響は生まないと 理解しました。 ご教示ありがとうございます。 cestquigucci2022/05/26メールの配送先はMXレコードで制御されてます。今はGmailのサーバーが指定されていると思います。 この記事のTXTレコードはおっしゃる通り、ドメインの所有確認のためだけに使います。 返信を追加Matsukura Yuki2024/03/01に更新私も2019年頃から同じ設定で運用しています。 年に何回かはGoogle WorkspaceからMicorosft 365へのユーザの同期（プロビジョニング）が止まってしまう問題が発生しています。 https://matsu.teraren.com/blog/2022/11/08/google-workspace-office-365/ 返信を追加
akimo41102022/01/20他の記事と比べて群を抜いて分かりやすい記事でした。 ただ、自分も同じような形でやってみたのですが、画像のようにうまく引き継がれずエラーが出てしまいます。 どうしたらよいか分からないのですが、ご教授いただけますでしょうか。 cestquigucci2022/01/23これは、federation realm object does not existと書いてあるので、GoogleのSSO URLが存在しないと言ってますね。どのタイミングで出ているエラーですかね。 Powershellでfederatedに切り替える段階なのか、SSOでアクセスしようとして出ているエラーなのか。SSOの場合は、GoogleのSAML AppがOnになっていないとか、SAML AppをOnにしたけど実際にOnになるまで若干のタイムラグがあってアクセスできない (Chrome Appからアクセスすると403とかになる)、とか色々あります。 返信を追加
cestquigucci2022/01/23これは、federation realm object does not existと書いてあるので、GoogleのSSO URLが存在しないと言ってますね。どのタイミングで出ているエラーですかね。 Powershellでfederatedに切り替える段階なのか、SSOでアクセスしようとして出ているエラーなのか。SSOの場合は、GoogleのSAML AppがOnになっていないとか、SAML AppをOnにしたけど実際にOnになるまで若干のタイムラグがあってアクセスできない (Chrome Appからアクセスすると403とかになる)、とか色々あります。
akimo41102022/01/23ChromeのGoogle Appランチャー（画面右側にある9点リーダ）に表示されているMicrosoft365からアクセスした際に表示されます。 Microsoft365のサインインページからサインインしようとしても、「組織のサインインページにアクセスしています」が表示された後に、同じような画面が表示されます。 Google側もSAML AppはONになっています。 返信を追加
cestquigucci2022/01/25となると、たぶん、AzureとGoogleとでIssuer URLの値が違っているのかも。 https://docs.microsoft.com/en-us/troubleshoot/azure/active-directory/authentication-fails-with-error ChromeのDeveloper Toolを使って、SAMLの中身見て、Issuer URLの値が双方でマッチしているか、確認すると良さそう。 https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/troubleshoot_saml_view-saml-response.html 返信を追加
help2022/05/24記事を拝見しての質問です。 運用中のGoogleworkspaceのドメインを【M365管理センター】もしくは【AzureAD】へ DNSレコード・TXTレコードにて追加した以降につきまして、 現状Gmailをメインで利用していますが、Officeのメールも同ドメイン(Googleユーザー)で利用することとなるかと認識しています。 メールの受信の動きに関しまして、受信先が競合してしまいどちらのメールにも届かないといったことはありますでしょうか？もしくはどちらかが優先してしまい一方しか届かない等の動きがあったりしますでしょうか？ もしご存知でしたらご教示いただけますと幸いです。 cestquigucci2022/05/24通常、Gmailをメインで使う組織は、Exchange onlineは使わない、という形にしたほうが幸せ。 何らかの理由で両方使わなければいけない場合は、ドメインを分けるほうが楽。 一緒のドメインで使いつつ、ユーザによってどちらにするかを制御したい、という場合は、Gmailをメインで受信するようにして、Exchangeを使うユーザだけExchangeに転送、というやり方ができます。 Gmailメインの場合は、GmailのDefault route機能を使って、GmailでExchange側に転送が必要なアドレスのメールを受け取ったら、GmailからOffice 365に転送する、という実装ができます。 Exchange Online Protectionをhostsとして追加 Gmailの設定でメールの転送先としてのEOP(Exchange Online Protection)のサーバを追加する。 追加するEOPのホスト名は、Microsoft 365管理センターのドメインの設定画面から確認できる。(Microsoft 365管理センター > 設定 > ドメイン) GmailのDefault Route設定 Gmailで受信したメールのうち、O365で受け取る必要のあるメールをEOP側に転送するルールを作る。 続いて、O365側で、Gmailと同じドメインでメールを送信できるように設定します。 SPFレコードにO365のサーバを追加して、O365から送信しても大丈夫なようにする DKIMをO365用に設定して署名をONに Accepted Domainの設定変更をする。 デフォルトでは、登録したドメインが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側を構成する、とか。 一応、うちの会社ではこの方式で一部利用していて、半年くらい運用してますが、特に大きな問題にはなっていません。ただ、かなりトリッキーな使い方なので、検証して大丈夫か確認してからやることをおすすめします。 help2022/05/26あくまでもTXTレコード追加はドメイン所有の確認ということと認識しました。 同ドメインの同アカウントでGmail、Exchange両方を使わない限り影響は生まないと 理解しました。 ご教示ありがとうございます。 cestquigucci2022/05/26メールの配送先はMXレコードで制御されてます。今はGmailのサーバーが指定されていると思います。 この記事のTXTレコードはおっしゃる通り、ドメインの所有確認のためだけに使います。 返信を追加
cestquigucci2022/05/24通常、Gmailをメインで使う組織は、Exchange onlineは使わない、という形にしたほうが幸せ。 何らかの理由で両方使わなければいけない場合は、ドメインを分けるほうが楽。 一緒のドメインで使いつつ、ユーザによってどちらにするかを制御したい、という場合は、Gmailをメインで受信するようにして、Exchangeを使うユーザだけExchangeに転送、というやり方ができます。 Gmailメインの場合は、GmailのDefault route機能を使って、GmailでExchange側に転送が必要なアドレスのメールを受け取ったら、GmailからOffice 365に転送する、という実装ができます。 Exchange Online Protectionをhostsとして追加 Gmailの設定でメールの転送先としてのEOP(Exchange Online Protection)のサーバを追加する。 追加するEOPのホスト名は、Microsoft 365管理センターのドメインの設定画面から確認できる。(Microsoft 365管理センター > 設定 > ドメイン) GmailのDefault Route設定 Gmailで受信したメールのうち、O365で受け取る必要のあるメールをEOP側に転送するルールを作る。 続いて、O365側で、Gmailと同じドメインでメールを送信できるように設定します。 SPFレコードにO365のサーバを追加して、O365から送信しても大丈夫なようにする DKIMをO365用に設定して署名をONに Accepted Domainの設定変更をする。 デフォルトでは、登録したドメインが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側を構成する、とか。 一応、うちの会社ではこの方式で一部利用していて、半年くらい運用してますが、特に大きな問題にはなっていません。ただ、かなりトリッキーな使い方なので、検証して大丈夫か確認してからやることをおすすめします。
help2022/05/26あくまでもTXTレコード追加はドメイン所有の確認ということと認識しました。 同ドメインの同アカウントでGmail、Exchange両方を使わない限り影響は生まないと 理解しました。 ご教示ありがとうございます。
cestquigucci2022/05/26メールの配送先はMXレコードで制御されてます。今はGmailのサーバーが指定されていると思います。 この記事のTXTレコードはおっしゃる通り、ドメインの所有確認のためだけに使います。
Matsukura Yuki2024/03/01に更新私も2019年頃から同じ設定で運用しています。 年に何回かはGoogle WorkspaceからMicorosft 365へのユーザの同期（プロビジョニング）が止まってしまう問題が発生しています。 https://matsu.teraren.com/blog/2022/11/08/google-workspace-office-365/ 返信を追加
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へのユーザの同期（プロビジョニング）が止まってしまう問題が発生しています。