Entra Connectで同期すべき必須情報
基本は既定値の同期ルールで同期すればよい
同期する属性は、既定値の同期ルールで同期すれば Microsoft Entra ハイブリッド参加を構成できます(どの属性値を同期するかしないかの考慮は基本的に不要です)
同期ルールの確認方法
同期ルールの具体的な設定値などを確認したい場合は、Microsoft Entra Connect をインストールした後に利用できる Synchronization Rules Editor で確認できます。
同期に必要となる最低限のユーザーの属性
ユーザーを同期をするために最低限以下のオンプレミスの属性の同期が必要です。
accountEnabled
sourceAnchor
sAMAccountName
(代替ログイン ID を利用する場合など含め環境によってはさらに追加されます)
まず、下記の公開情報に sourceAnchor および accountEnabled が必須である旨が記載されています。
参考情報: Microsoft Entra Connect 同期: 既定の構成について – Microsoft Entra ID | Microsoft Learn
//////////////一部抜粋//////////////
ユーザー オブジェクトは次の要件を満たさないと同期されません。
- sourceAnchor が含まれている必要があります。
- Microsoft Entra ID でオブジェクトが作成された後は、sourceAnchor を変更できません。 オンプレミスで値が変更された場合、sourceAnchor が前の値に戻るまでオブジェクトは同期を停止します。
- accountEnabled (userAccountControl) 属性が入力されている必要があります。 オンプレミスの Active Directory があれば、この属性は常に存在し、入力されています。
//////////////ここまで//////////////
また、sAMAccountName の値が空の場合は Microsoft Entra Connect でフィルターされ Microsoft Entra ID へ同期されません。そのため、sAMAccountName も必須となります。
上記公開情報には sAMAccountName がないユーザーは同期されないこと (= ユーザーを同期するには sAMAccountName が必要であること) も記載されています。
//////////////一部抜粋//////////////
次のユーザー オブジェクトは Microsoft Entra ID に同期されません。
- IsPresent([isCriticalSystemObject])。 組み込み管理者アカウントなど、Active Directory の既定のオブジェクトの多くは同期されません。
- IsPresent([sAMAccountName]) = False。 sAMAccountName 属性のないユーザー オブジェクトが同期されていないことを確認します。 このような局面は、現実的には NT4 からアップグレードされたドメインでのみ発生します。
//////////////ここまで//////////////
accountEnabled は、同期されるオブジェクトが有効か無効かを示す値であり、オンプレ AD オブジェクトの userAccountControl 属性をもとに生成されます。
sourceAnchor は Microsoft Entra Connect の構成に依存しますが、既定では msDS-ConsistencyGUID あるいは ObjectGUID の値が sourceAnchor 属性として同期されます。（AD上にsourceAnchorという属性が存在している訳ではなく、あくまで概念的な属性となります。実体は、上記記載の通り、msDS-ConsistencyGUIDやObjectGUIDとなります）
sAMAccountName は 必須属性 の一つで、ADにてユーザー作成時に 必ず値が設定されます。明示的に値を指定しなかった場合は、ADが自動で値を作ってセットしてくれます（m.tsurutaのような値です。手動でセットすることも可能です）
ちなみに、UserPrincipalName も必須ではないか？と思われるかもしれませんがEntra Connect の既定の同期ルールでは、オンプレミス AD 側の UserPrincipalName が空の場合でも、sAMAccountName の値を利用して Entra ID 側の UserPrincipalName の値が計算され、ユーザーは同期されるため、UserPrincipalName は必須ではありません。
ユーザーの属性は、既定のルールで同期することが推奨値となっています。ただ、要件によっては同期したくない属性がある場合があります（個人情報に近しい情報をクラウド上に同期したくない など）
この場合にその同期したくない属性の同期を既定のルールから除外することを、アプリへの影響を考慮しつつアプリ単位で影響を検討する、というのが同期の基本的な設計方法になります。
つまり、同期する属性を積み上げていくのではなく、既定値から同期しない属性を除く、という設計の考え方になります。
★★注意点
- 既定で同期対象となっている属性について、AD側でその属性の値が設定されているかは別の話
- M365側のアプリによっては、同期対象となっていたとしても、AD側にその属性の値がセットされておらず、Entra ID側でもその属性の値が空になることで、不具合が発生する可能性がある
- ちゃんとやろうとすると、M365のアプリ毎に必要な属性を確認して、その属性の値がEntra ID側でも漏れなくセットされるように、AD側の属性の値もセットしておく必要があります。
- Microsoft Entra Connect によって同期される属性 – Microsoft Entra ID | Microsoft Learn こちらのサイトに、M365アプリ毎に利用する可能性がある属性が記載されています（あくまで「利用する可能性がある属性（最大値）」）であり、必須の項目ではありません。どれが必須かはアプリ毎にＭＳサポートに確認が必要です（アプリ側の使い方によって、必須属性が増減する可能性もあります）
- 現実的に、設計段階で、必要な属性を洗い出すのは困難（稼働が非常にかかるため）、「一度、同期した上で、利用しようとしているＭ３６５アプリが問題なく動作するか確認する」、というやり方が現実解な気がしています。
アプリによって利用している属性
Microsoft Entra Connect によって同期される属性 – Microsoft Entra ID | Microsoft Learn
それぞれのアプリが、既定値で同期される属性のどの値を使っているかを示している表になります。
使わないアプリがある場合は、既定値で同期される属性から “Azure AD (Microsoft Entra ) アプリと属性フィルター" を利用して同期する属性を制限する (減らす) ことができますが、その際に参考にする情報となります。
（補足）「利用場所」属性
・Entra ID側で、ユーザにライセンスを割り当てると、Entraテナントの場所の情報が、「利用場所」属性に割り振られるので、個人的な見解としては、ADからこの属性を同期する必要性はあまり感じていません。
(追記１）20250603
「利用場所」属性に値がない場合、ライセンス付与の際にエラーが出る事象に遭遇しました（MS側の仕様が変わった可能性があります
（補足）
「利用場所」 は Entra ID 側では usageLocation 属性が該当します、既定で同期元となるオンプレミス AD 側の属性は msExchUsageLocation 属性となります。
msExchUsageLocation 属性は Exchange 関連属性であるため、オンプレミス側で Exchange サーバーが構成されている (オンプレミス AD で Exchange スキーマ拡張が行われている) 場合に存在する属性です。
このため、Exchange サーバーが構成されていない場合、既定では Entra ID 側の利用場所 (usageLocation 属性) は同期処理で値が設定されず、空となります。Entra ConnectにおけるADDSコネクタの受信同期ルールで、「利用場所」属性を設定することで、Entra ID側への同期が可能となります。
Exchange サーバーが構成済みの場合、Microsoft Entra Connect 構成ウィザード上における “Azure AD (Microsoft Entra ) アプリと属性フィルター" の項目にて特段同期する属性を制限していない場合は、Microsoft Entra Connect としては、同期する属性の一覧として含まれます。
また Entra ID 側でクラウド ユーザーを直接作成した場合でも、利用場所を設定しなかった場合は利用場所が空となります。
（補足）userPrincipalName, displayName, mailNickname 属性
これらの属性は、オンプレミス AD 側の同期元の属性が空である場合に自動で設定されます（これらの属性は例外であり、基本的には、同期元であるオンプレミス AD 側の属性に値が設定されていない場合、基本的に該当の属性は Entra ID には同期されず空のままとなります）
userPrincipalName 属性が空の場合、sAMAccountName 属性を利用して同期する値を計算するように Entra Connect の規定の同期ルールが構成されています。
displayName 属性が空の場合も同様に、クラウド側の displayName 属性として代わりに cn 属性を同期するように規定の同期ルールが構成されています。
mailNickname 属性については、 Entra ID 側において、下記ドキュメントの [Microsoft Entra の MailNickName 属性値の計算] の項目に記載された優先順位で値が自動計算されます。
このためオンプレミスの mailNickName 属性が空の場合でも、proxyAddresses 属性や mail 属性、userPrincipalName 属性の値を利用して Entra ID 側で自動計算されます。
Title : Microsoft Entra UserPrincipalName の作成 | Microsoft Entra の MailNickName 属性値の計算
mail, proxyAddresses 属性
mail 属性および proxyAddresses 属性は Entra ID でユーザーを作成する際に必須となる属性ではありませんが、シナリオ次第ではオンプレミス AD 側の値が空でも、Entra ID 側では値が設定される場合があります。
具体的には、オンプレミス AD 側で mail 属性と proxyAddresses 属性が空であっても、Entra ID 側で Exchange Online のライセンスが割り当てられた場合は、mail 属性や proxyAddresses 属性が自動で計算され、値が設定されます。
(詳細は後述のドキュメントの[シナリオ 1] を確認ください)
また、オンプレミス AD 側で mail 属性が設定されており proxyAddresses 属性が空である場合、Entra ID 側でも mail 属性が同期されますが、Entra ID 側の動作として mail 属性の値が proxyAddresses 属性のプライマリ SMTP アドレスに自動で設定されます。
この場合はオンプレミス AD 側では proxyAddresses 属性が空ですが、Entra ID 側では値が設定されます。
(詳細は後述のドキュメントの[シナリオ 2] をご確認ください)
このように mail 属性や proxyAddresses 属性はシナリオ次第では、オンプレミス AD 側の値が空でも、Entra ID 側で自動で値が計算・設定される場合があります。
Entra ID 側で mail 属性や proxyAddresses 属性が計算される動作は “プロキシ計算" と呼ばれ、下記のドキュメントに詳細な動作やシナリオが記載されています。
Title : Microsoft Entra ID に proxyAddresses 属性を設定する方法
同期に必要となる最低限のデバイスの属性
説明になっていないかもしれないですが、デバイスの属性は、既定値での利用がよいです（MSサポート曰く）。
MSサポートに上記の通りわれた以上、本当に「最低限のデバイスの属性」について確認するのを止めました。
デバイスの同期する属性自体は、Synchronization Rules Editor にて 「In from AD – Computer Join」ルールなどで確認ができます。
しかしながら、これらのデバイス同期のルールの変更が非推奨事項となっているらしく（MSサポート曰く）、やはり既定値で利用が無難そうです。
参考
デバイスの同期も必須か
Microsoft Entra ハイブリッド参加を構成する際には、AD FS がなければ Microsoft Entra Connect でのデバイスの同期が必須です(AD FS がある場合も同期したほうが運用の手間は減る傾向にあります）