SEくぼたの事件簿

インフラSEとしての活動を記録していきます

指定のドメイン名がどこかの Microsoft Entra ID ( Microsoft 365 ) にカスタム ドメインとしてすでに登録されているか確認する方法

こんにちは。


[ ドメイン名がすでにどこかの Microsoft Entra ID テナントのカスタム ドメインとして登録されちゃってるか確認する方法ありますか?] ってたまに聞かれることがあります。

Microsoft 365 などでは、以下の公開情報のアプリケーションからサインアップするとセルフサービス サインアップ テナントが作成されます。

learn.microsoft.com



その際サインアップに使用したメールアドレスのドメインがまだどこの ME-ID のテナントのカスタムドメインとしても使用されていない場合、該当のドメインがカスタムドメインとして非管理テナントが作成されます。
※これをセルフサービス サインアップ テナントと呼びます。


このように使いたいドメインがすでに ME-ID 上にカスタムドメインに登録されていたりすると、セルフサービス サインアップ テナント側からカスタムドメインを削除した後に、使用したいテナント上でカスタムドメインを登録するという手順が必要になります。

実際にカスタムドメインを追加する際のエラーなどですでに登録されているか確認してもよいのですが、事前に確認したいという要望があったりします。

そんな時、ドメイン名からどこかのテナントに登録されているか確認するための API があります。

テナント ID からテナントを確認するための API などもあるので、ME-ID のサインイン ログから外部のテナントにアクセスしていることを確認した時などにテナント ID から対象のテナントを確認することも可能です。

・確認手順

1.以下の URL から Graph Explorer にアクセスします。
 Graph Explorer | Try Microsoft Graph APIs - Microsoft Graph

2.画面右上のアイコンをクリックします。


3.どこかのテナントの管理者アカウントでサインインします。
 

3.再度右上のアイコンをクリックします。
 


4.[ Consent to permissions ] をクリックします。


5.検索ボックスで [ CrossTenantInformation.ReadBasic.All ] を検索し、Consent をクリックします。
※画面例はクリック後の状態です。


6.Graph Explorer の画面に戻り下図の通り、クエリに [ https://graph.microsoft.com/v1.0/tenantRelationships/findTenantInformationByDomainName(domainName='domain name') ] を入力します。

例 : https://graph.microsoft.com/v1.0/tenantRelationships/findTenantInformationByDomainName(domainName='contoso.com')


7.Run query をクリックすると、OK のステータスとともにテナントの情報が出力されます。
 


※テナント ID から検索したい場合にはクエリを以下に変更します。

クエリ情報
[ https://graph.microsoft.com/v1.0/tenantRelationships/findTenantInformationByTenantId(tenantId='tenant id') ]


結果



・参考情報
実行する API の参考 URL
tenantRelationship: findTenantInformationByDomainName - Microsoft Graph v1.0 | Microsoft Learn

tenantRelationship: findTenantInformationByTenantId - Microsoft Graph v1.0 | Microsoft Learn



--------------------------------------------------

さいごに

--------------------------------------------------

上記で紹介した通りカスタムドメインとしてすでに指定のドメイン名が使われているか確認することができます。
使用頻度は多くないかとは思いますが、いざという時使うことがあるかもしれないので、興味がある方は試してみてください。

Twitterでも情報発信したいと思いますので、興味があったらフォローしてください!

 

Microsoft Entra Connect ( 旧 AADC ) で発生するエラー( DeletingCloudOnlyObjectNotAllowed ) の原因と対応方法

こんにちは

今回はオンプレ AD と同期済みのユーザーをクラウド ユーザーに変換した際に Microsoft Entra Connect 上で発生する DeletingCloudOnlyObjectNotAllowed というエラーの原因と対応方法について記載していきたいと思います。

 

この記事を書こうと思い続けて 2 年近く経過して名称が Azure AD Connect ( AADC ) から Microsoft Entra Connect に変更されてしまいました。

 

Microsoft 365 を利用している環境でオンプレ AD のユーザーと Microsoft Entra ID を同期しているパターンは結構多いんじゃないかと思います。

 

この運用においてたまに元々同期ユーザーだったけれど、同期されていないクラウド ユーザーに戻したいという要件があったりします。

 

この場合、通常オンプレ AD にて Microsoft Entra Connect の同期対象外にした後で、 Microsoft Entra ID で削除済みユーザーを復元という手順を実施するかと思いますが、この時に DeletingCloudOnlyObjectNotAllowed というエラーが Microsoft Entra Connect 上で発生することがあります。

 

また Microsoft Entra Connect Health などを利用している場合には [ その他のエラー ] とだけ表示され、対象のオブジェクトの詳細なども表示されないためどのオブジェクトで問題が発生しているかわかりにくいという状態となってしまいます。

 

例 : Synchronization Service Manager 上でのエラー

 

例 : Microsoft Entra Connect Health 上でのエラー

 

この記事では、エラーが発生する理由とその対応方法を詳細に記載していきます。

 

本エラーの発生原因の説明のため Microsoft Entra Connect の動作原理を先に説明します。

 

Microsoft Entra Connect の動作原理

 

通常同期処理が行われると以下の順で処理が行われていきます。

[ 処理順序 ]

1.Import 

 オンプレ AD と Microsoft Entra ID のそれぞれから Microsoft Entra Connect のデータベース上の Connector Space ( CS ) という領域に情報を取り込みます。

 

 

2.Syncronization

 Import 処理で CS に取り込まれたそれぞれの情報を Metaverse ( MV ) という領域に情報をマージします。

 

3.Export

 Synchronization 処理した情報をオンプレ AD と Microsoft Entra ID のそれぞれに Export して同期します。

 

 

・DeletingCloudOnlyObjectNotAllowed の発生原因

DeletingCloudOnlyObjectNotAllowed のエラーはオンプレ AD からユーザーを削除した後に、Microsoft Entra Connect にて 2 回 同期を行っていない場合に発生します。

 

上記に記載の通り Microsoft Entra Connect では 1 度の同期処理で Microsoft Entra ID に対しユーザーの削除要求を出します。

しかしその次の同期処理にて Microsoft Entra ID から情報を取得した際に、削除要求を出したはずのユーザーが Microsoft Entra ID で復元されていると、削除されていないと判断し本エラーを出力します。

 

この一連の動作状態を図にしたものが以下です。

 

1.Import 処理にてオンプレ AD からユーザーの削除情報を受け取ります。

 

2.Synchronization 処理にてユーザーの削除情報をマージします。

 

3.Export 処理で Microsoft Entra ID にユーザーの削除処理を実施します。

4.この後、次の同期処理 ( 規定では 30 分間隔 ) が実行される前に Microsoft Entra ID 上で削除済みユーザーを復元します。

 

5.4 の処理の後、定期実行される同期や手動での同期処理を実行すると上記で説明した同期処理が再度実行されますが、 Microsoft Entra ID からの Import 処理で削除した結果を受け取ることができない状態となります。 ( 4 でユーザーを復元しているため )

 

このように Microsoft Entra Connect はユーザーが削除された結果を次回の同期処理にて受け取りますが、その際に削除したユーザーが復活している!?!?!?という状態となってしまうので DeletingCloudOnlyObjectNotAllowed のエラーが発生します。

 

・発生させないための方法

本エラーの発生を防ぐためには上記で説明した動作原理の通り、ユーザーが削除された次の同期処理でユーザーが削除された情報を Microsoft Entra Connect に取り込めばよいのです。

そのため、以下の流れで処理を行えばこのエラーを発生させないことが可能です。

 

[ 処理の流れ ]

1.ユーザーをオンプレ AD で削除または同期の対象外とします。

2.Microsoft Entra Connect 上で PowerShell を起動し以下のコマンドレットを実行して差分同期を行います。

  Start-ADSyncSyncCycle -PolicyType Delta

3.Microsoft Entra Connect サーバー上にインストールされている Synchronization Service Manager で Export 処理まで完了することを確認します。

4.再度 PowerShell コンソール上で以下を実行して差分同期を行います。

  Start-ADSyncSyncCycle -PolicyType Delta

5.Synchronization Service Manager で Export 処理まで完了することを確認します。

6.Microsoft Entra ID ( Azure Portal や Entra 管理センター ) で削除済みユーザーよりユーザーを復元します。

 

 

・発生してしまった場合の対応方法

問題本問題が発生してしまった場合には以下の方法で対応可能です。

しかし対応するためには一時的に再度 Microsoft Entra ID のユーザーを削除済みユーザーに移す必要があります。

この処理を行っている間 Microsoft Entra ID のユーザーを利用することができません。

Microsoft 365 のアプリケーションを利用できない状態となります。

 

上記にて何度か記載した通り、 Microsoft Entra ID のユーザーが削除済みになっている状態で Microsoft Entra Connect 上で同期処理が行われることでエラーが解消します。

 

そのため対応するために処理の流れは以下の通りです。

 

[ 対応の流れ ]

1.Microsoft Entra ID 側でユーザーを削除し、削除済みユーザーへ格納します。
  

 

2.Microsoft Entra Connect 上で PowerShell を起動し以下のコマンドレットを実行して差分同期を行います。

  Start-ADSyncSyncCycle -PolicyType Delta

3.Microsoft Entra Connect サーバー上にインストールされている Synchronization Service Manager で Export 処理まで完了することを確認します。

4.再度 Microsoft Entra ID 上で削除済みユーザーからユーザーを復元します。

 

対応方法としては以上の通りではありますが、発生してしまった後に Microsoft Entra Connect Health 上のエラーを見てもどのユーザーが対象のユーザーなのかわからない。。。。。。という問題が発生します。

 

どのユーザーが対象のユーザーなのか確認するには以下の方法を使用します。

 

1.Microsoft Entra Connect 上の Synchronization Service Manager 上で DeletingCloudOnlyObjectNotAllowed のエラーをクリックします。

 

2.表示された画面の Detail をクリックします。

 

3.表示された画面内の Object ID の Value の値を控えます。

4.控えた値を Azure Portal や Entra 管理センターの [ すべてのユーザー ] 内の上部にある検索ボックスに貼り付けると該当のユーザーが表示されます。

 

このようにユーザーを特定することが可能です。


~~~~~~~~~~~~~~~~~~~
2024.1.26 追記
~~~~~~~~~~~~~~~~~~~
この方法で同期されたユーザーをクラウドユーザーに変換する方法が非推奨ではなくサポート外の操作に該当する可能性があります。
エラーとしては上記で解消可能ですが、クラウドユーザーへの変換についてはお気を付けください。


--------------------------------------------------

さいごに

--------------------------------------------------

ここまでで説明した通り同期されたユーザーをクラウド ユーザーにする場合には手順を誤るとエラーとなりますが、エラーの解消のためには 1 ユーザーずつ対応していく必要があるので結構大変です。

この動作を覚えてエラーが発生しないようにしていただけると嬉しいです。

 

ただし!!!!

Microsoft 社としてはこの手順でのクラウド ユーザーへの変換を推奨していません。

でも他に方法がないのもまた事実。。。。。。クラウド ユーザーへの変換も需要としてはあると思うので、そういった機能がでてくるとよいですね!

今回は以上です。

 

Twitterでも情報発信したいと思いますので、興味があったらフォローしてください!

 

Azure AD のクロステナント同期を試してみる

こんにちは。

1年ほどブログを更新できていなかったので久しぶり更新したいと思っています。

 

今回はプレビュー機能として登場した Azure AD Cross Tenant Sync について記載していきます。

2023/1 段階ではパブリック プレビューなのですが今のうちに動作見ていきたいと思います。

 

はじめに Microsoft の公開情報は以下です。

現段階では日本語がないので英語のサイトで確認くださいー!

※翻訳でなんとなくわかりますね!

URL : Configure cross-tenant synchronization (preview) - Microsoft Entra | Microsoft Learn

 

今回は以下の流れで記載していきます。

 

1. クロステナント同期とは

2. 設定

3. 注意点

 

--------------------------------------------------

1. クロステナント同期とは

--------------------------------------------------

Azure AD のクロステナント同期は、その名の通り、 2 つのテナント間のユーザーを同期するというものです。

従来 Azure AD B2B を利用してゲスト ユーザーとしてユーザーを招待していたかと思います。

クロステナント同期を利用することで 2 つの Azure AD のテナントのユーザーを同期し、ゲスト招待のような扱いにすることができます。

 

この機能の何が嬉しいかというと以下の点が大きくあげられるかと思います。

 

・招待の処理や承諾の処理をスキップできる

・招待元テナントの情報変更が反映される ( 従来同期されなかった属性も同期できる )

 

■嬉しい点 1 ( 招待の処理や承諾の処理をスキップできる )

従来の Azure AD B2B の招待では、以下の 2 つのフェーズを必要としていました。

 

1.招待元テナントでの対象ユーザーの招待

2.招待されたユーザーの承諾

 

招待元テナントでの招待は Azure Portal からの GUI での招待か、 PowerShell を利用した招待を行っていました。

その後、招待されたユーザーは必ず招待の引き換えを行い承諾を行う必要がありました。

 

クロステナント同期を利用することで、対象のユーザー指定して承諾まで完了した状態で同期を行うことができます。

 

■嬉しい点 2 ( 招待元テナントの情報変更が反映される )

Azure AD B2B での招待では、ゲスト ユーザーは招待の承諾を行ったタイミングにてゲスト ユーザーのホームテナント側に設定された表示名 ( DisplayName ) を招待元テナントのゲスト ユーザーの表示名に設定します。

 

しかし、その後の運用にてゲスト ユーザーのホームテナント側でメールアドレスや表示名などが更新されてもゲストの招待元テナント上ではその情報が更新されませんでした。

 

しかしクロステナント同期では、定期的 ( 40 分に 1 回 ) に同期処理がおこなわれているため随時情報が更新されます。

 

■難しい点

この機能の難しい点は、機能のコンセプトとして 2 つのテナントを保有する会社が同じ組織であることを想定している点です。

そのため、他社のユーザーをゲスト招待する!といったシナリオには適していません。

 

会社内にてマルチテナントで利用していて、そのテナント間のユーザーを同期して管理したい!というシナリオを想定しているようです。

 

抜粋

~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~

参考 : What is a cross-tenant synchronization in Azure Active Directory? (preview) - Microsoft Entra | Microsoft Learn

 

 

クロステナント同期のイメージは以下の抜粋の図の通り、テナントに作成されているユーザーを別のテナントに作成!という動作のようです。

後述する設定画面から察するにエンタープライズ アプリケーションでのプロビジョニングと同様に SCIM によるプロビジョニングをしていそうな予感

 

抜粋

~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~

参考 : What is a cross-tenant synchronization in Azure Active Directory? (preview) - Microsoft Entra | Microsoft Learn

 

--------------------------------------------------

2. 設定

--------------------------------------------------

■前提条件

・テナント間同期を行う双方のテナントで Azure AD Premium P1 または P2 を保有している

・双方のテナントで設定を行うアカウントに最低限 ハイブリッド ID 管理者の Azure AD ロールが付与されている

・ 2 つのテナントの テナント ID を把握している

 ※テナント ID の確認はこちらの手順をご利用ください。

  テナント ID を見つける方法 - Azure Active Directory - Microsoft Entra | Microsoft Learn

 

■補足

設定では、 2 つのテナントを行き来するため、同期するゲスト ユーザーがいる側テナントを comtoso.com, 同期される側のテナントを fabricam.com として記載していきます。

※画面ショットの表示名が違う点はご了承を・・・

 

■設定

fabricam.com の Azure Portal にサインインして、External Indentities をクリック

 

テナント間アクセス設定をクリックし、組織の設定をクリック

組織の追加をクリック

contoso.com のテナント ID を入力して追加

受信アクセスの [ 既定値から継承 ] をクリック

テナント間同期 をクリックして、 [ ユーザーにこのテナントへの同期を許可する ] にチェックを入れて保存

信頼の設定で [ 他のテナントのユーザーが、自分のテナント内の・・・・ ] にチェックを入れて保存クリック

 

Contoso.com のテナントの Azure Portal にサインインして、上記と同様の手順で External Indentities から組織の追加をクリックして、 Fabricam.com のテナントのテナント ID を入力して追加をクリック

送信アクセスの [ 既定値から継承 ] をクリック

信頼の設定から [ 自分のテナントのユーザーが・・・ ] にチェックを入れて保存をクリック

 

Contoso.com のテナントの Azure Portal で テナント間同期 をクリック

構成 から 新しい構成をクリック

同期を行う構成に任意の名前を入力して作成をクリック

作成された構成をクリック ( 表示までに少し時間がかかります )

作業の開始をクリック

プロビジョニング モードを自動に変更して保存クリック

Fabricam.com のテナント ID を入力し、テスト接続をクリック

テストが完了したら保存クリック

 

下図のマッピングの内容が表示されることを確認

 

Provision Azure Active Directory Users のリンクをクリックすることで属性マッピングやスコープ フィルターも編集可能です。

※既定の属性マッピングの注意事項についても後述します。

 

テナント間同期の構成内の ユーザーとグループをクリックして ユーザーまたはグループの追加をクリックし、同期を行うユーザーを追加

ユーザーが追加されたことを確認

プロビジョニングの開始をクリック

下図が画面右上に表示されれば完了

 

設定は以上です。

 

設定の UI を確認するとエンタープライズ アプリケーションと設定方式はほぼ一緒でした。

プロビジョニングのサイクルも 40 分間隔です。

 

40 分待つのが面倒だったので、即時でプロビジョニングしました。

要求時にプロビジョニングするをクリック

 

設定手順でアサインしたユーザーを選択

アサインしていないユーザーは対象外として処理がスキップされるのでご注意を

プロビジョニング結果が出力されます。

・・・・・結果の画面の画面ショット取り忘れた・・・・・・笑

 

Fabricam.com のテナントでプロビジョニングしたユーザーを確認します。

 

ちゃんと同期されてる!!!!

Contoso.com で mail 属性を testmail@contoso.com にして再度同期してみた!

ちゃんと更新された!!

 

ちゃんと承諾済みで同期されたことも確認できます

 

ゲスト ユーザーを動的グループでまとめたりするなら、 Company 属性を属性マッピングで設定してあげて、会社ごとのグループを作ったりするのも管理しやすそうですね!

 

--------------------------------------------------

3. 注意点

--------------------------------------------------

同期した後に気づいたんですが、、、、、既定の属性マッピングを再度見直すと。。。

userType を Menber として同期してた!!!!

 

なので。。。ユーザーの種類がメンバーで同期されてる!!!

 

これで OK であれば問題ないですが、 Azure AD B2B と同様にゲストにしたい場合は、以下の設定を行います。

 

属性マッピングで下記の赤枠をクリック

定数値を Guest に修正し、ユーザー作成時以外にもこのマッピングを適用する場合は、常時を選択して OK をクリック
※常時を選択しないとすでに同期されたユーザーの情報は更新はされません。。。。

 

再度即時で更新処理!

ちゃんと Guest の情報をプロビジョニングしました

 

Fabricam.com のテナント側でもゲストの表示に切り替わりました!

 

--------------------------------------------------

さいごに

--------------------------------------------------

まだプレビュー段階なので今後機能が追加されてくるかもしれませんね!!

複数テナントを保有していて毎回双方にゲスト招待をするのが大変!!って方は利用をお試しいただいてもよいかもですね!

 

Twitterでも情報発信したいと思いますので、興味があったらフォローしてください!