確認済みドメインの変更中のユーザーの一括更新について
この記事では、確認済みドメインの変更によってトリガーされる多くの UserPrincipalName の更新が監査ログに表示される一般的なシナリオについて説明します。 この記事では、確認済みドメインの変更中に発生する監査ログの UserManagement 更新の原因と考慮事項について説明します。 この記事では、Microsoft Entra ID で大量のオブジェクトの変更をトリガーするバックエンド操作について詳しく説明します。
現象
Microsoft Entra 監査ログに、Microsoft Entra テナントで発生した複数のユーザー更新が示されています。 これらのイベントのアクター情報は空であるか、N/A と表示されています。
一括更新には、UserPrincipalName のドメインを組織の優先ドメインから既定の *.onmicrosoft.com ドメイン サフィックスに変更することが含まれています。
サンプル監査ログの詳細
アクティビティの日付 (UTC): 2022-01-27 07:44:05
アクティビティ: ユーザーの更新
アクターの種類: その他
アクターの UPN: N/A
状態: 成功
カテゴリ: UserManagement
サービス: コア ディレクトリ
ターゲット ID: aaaaaaaaa-bbbb-0000-11111-bbbbbbbbbbbbb
ターゲット名: user@contoso.com
ターゲットの種類: ユーザー
監査ログ エントリの詳細内で、modifiedProperties セクションを探します。 このセクションには、ユーザー オブジェクトに加えられた変更が示されます。 oldValue および newValue フィールドには、ドメインの変更が示されます。
"modifiedProperties":
"displayName": "UserPrincipalName",
"oldValue": "[\"user@contoso.onmicrosoft.com\"]",
"newValue": "[\"user@contoso.com\"]"
原因
大量のオブジェクト変更が発生する一般的な理由の 1 つは、非同期のバックエンド操作によるものです。 この操作により、Microsoft Entra のユーザー、グループ、または連絡先で更新される適切な UserPrincipalName と proxyAddresses が決定されます。
このバックエンド操作の目的は、UserPrincipalName と proxyAddresses が Microsoft Entra ID 内でいつでも一貫していることを保証することです。 確認ドメインの変更などの明示的な変更によって、この操作がトリガーされます。
たとえば、確認済みドメイン Fabrikam.com を Contoso.onmicrosoft.com テナントに追加すると、このアクションにより、テナント内の "すべての" オブジェクトに対してバックエンド操作がトリガーされます。 このイベントは、確認済みドメインの追加イベントの後に続くユーザーの更新イベントとして Microsoft Entra 監査ログに取り込まれます。
Fabrikam.com が Contoso.onmicrosoft.com テナントから削除された場合、すべてのユーザーの更新イベントの前に確認済みドメインの削除イベントが発生します。
解決方法
この問題が発生した場合は、Microsoft Entra Connect を使用してオンプレミスのディレクトリと Microsoft Entra ID の間でデータを同期するとメリットが得られる場合があります。 このアクションにより、UserPrincipalName と proxyAddresses が両方の環境で一貫していることが保証されます。
これらのオブジェクトを手動で追加または維持しようとすると、別のバックエンド操作によって一括変更がトリガーされるリスクが発生します。
これらの概念を理解するには、次の記事を参照してください。
考慮事項
このバックエンド操作では、以下に該当する特定のオブジェクトに対する変更は行われません。
- アクティブな Microsoft Exchange ライセンスがない
MSExchRemoteRecipientTypeが Null に設定されている- 共有リソースとみなされない
共有リソースとは、CloudMSExchRecipientDisplayType に次の値のいずれかが含まれているものです。
MailboxUser(共有)PublicFolderConferenceRoomMailboxEquipmentMailboxArbitrationMailboxRoomListTeamMailboxUserGroupMailboxSchedulingMailboxACLableMailboxUserACLableTeamMailboxUser
この 2 つの異なるイベント間の相関関係をさらに高めるため、Microsoft では、監査ログ内のアクター情報を更新して、これらの変更が確認済みドメインの変更によってトリガーされたことを識別することに取り組んでいます。 このアクションにより、確認済みドメインの変更イベントがいつ発生し、各自のテナント内のオブジェクトの大量更新がいつ開始されたかをチェックすることができます。
ほとんどの場合、UserPrincipalName と proxyAddresses には一貫性があるため、ユーザーに対する変更はありません。そのため、Microsoft では、オブジェクトに対する実際の変更の原因となった更新のみを監査ログに表示することに取り組んでいます。 このアクションにより、監査ログ内のノイズが防止され、管理者が残りのユーザー変更を確認済みドメイン変更イベントに関連付けることができます。
詳しく調べる
バックグラウンドで何が起こっているかについてより詳しい説明が必要でしょうか? ここでは、Microsoft Entra ID で大量のオブジェクトの変更をトリガーするバックエンド操作について詳しく説明します。 本題に入る前に、「Microsoft Entra Connect Sync サービス シャドウ属性」の記事を参照して、シャドウ属性を理解してください。
UserPrincipalName
クラウド限定ユーザーの場合、UserPrincipalName は確認済みドメイン サフィックスに設定されます。 一貫性のない UserPrincipalName が処理されると、操作によって既定の onmicrosoft.com サフィックスに変換されます (例: username@Contoso.onmicrosoft.com)。
同期されたユーザーの場合、UserPrincipalName は確認済みドメイン サフィックスに設定され、オンプレミスの値 (ShadowUserPrincipalName) と一致します。 一貫性のない UserPrincipalName が処理されると、操作によって ShadowUserPrincipalName と同じ値に戻されます。ドメイン サフィックスがテナントから削除されている場合は、既定の *.onmicrosoft.com ドメイン サフィックスに変換されます。
ProxyAddresses
クラウド限定ユーザーの場合、一貫性とは、proxyAddresses が確認済みドメイン サフィックスと一致していることを意味します。 一貫性のない proxyAddresses が処理されると、バックエンド操作によって既定の *.onmicrosoft.com サフィックスに変換されます (例: SMTP:username@Contoso.onmicrosoft.com)。
同期ユーザーの場合、一貫性とは、proxyAddresses がオンプレミスの proxyAddresses 値 (つまり、ShadowProxyAddresses) と一致していることを意味します。 proxyAddresses は ShadowProxyAddresses と同期されていることが期待されています。 同期ユーザーに Exchange ライセンスが割り当てられている場合は、クラウドとオンプレミスの値が一致する必要があります。 これらの値は、確認済みドメイン サフィックスとも一致する必要があります。
このシナリオでは、バックエンド操作によって、未確認のドメイン サフィックスを持つ一貫性のない proxyAddresses がサニタイズされ、Microsoft Entra ID 内のオブジェクトから削除されます。 その未確認ドメインが後で確認された場合、バックエンド操作によって ShadowProxyAddresses から proxyAddresses が再計算され、Microsoft Entra ID 内のオブジェクトに追加されます。
Note
同期オブジェクトの場合、バックエンド操作ロジックによる予期しない計算結果を避けるために、オンプレミス オブジェクトの Microsoft Entra 確認済みドメインに proxyAddresses を設定することをお勧めします。