本文適用於 Microsoft 365 企業版和 Office 365 企業版。
如果您在此解決方案的 步驟 2 中選擇混合式身分識別模型，並設定系統管理員帳戶的保護，並在步驟 3 中設定使用者帳戶的保護，則下一個工作是部署目錄同步處理。 目錄同步處理對貴組織的好處包括：
- 減少組織中的管理程式
- 選擇性地啟用單一登入案例
- 在 Microsoft 365 中自動變更帳戶
如需使用目錄同步處理優點的詳細資訊，請參閱 使用 Microsoft Entra ID 的混合式身分識別。
不過，目錄同步處理需要規劃和準備，以確保您的 Active Directory 網域服務 (AD DS) 同步處理至 Microsoft 365 訂用帳戶的Microsoft Entra租用戶，且錯誤最少。
請按照以下步驟操作以獲得最佳結果。
AD DS 準備
若要協助確保使用同步處理順暢地轉換至 Microsoft 365，您必須先準備 Microsoft DS 樹系，才能開始 Microsoft 365 目錄同步處理部署。
您的目錄準備應著重於下列工作：
移除重複的 proxyAddress 和 userPrincipalName 屬性。
使用有效的 userPrincipalName 屬性更新空白和無效的 userPrincipalName 屬性。
移除 givenName、姓氏 ( sn ) 、 sAMAccountName、 displayName、 mail、 proxyAddresses、 mailNickname 和 userPrincipalName 屬性中的無效和可疑字元。 如需準備屬性的詳細資訊，請參閱 Azure Active Directory 同步處理工具同步處理的屬性清單。
注意事項
這些屬性與 Microsoft Entra Connect 同步處理的屬性相同。
多樹系部署考量
針對多個樹系和 SSO 選項，請使用 Microsoft Entra Connect 的自訂安裝。
如果您的組織有多個樹系進行驗證 (登入樹系) ，我們強烈建議您執行下列動作：
- 考慮鞏固你的森林。 一般而言，維護多個樹系需要更多額外負荷。 除非您的組織有需要個別樹系的安全性限制，否則請考慮簡化內部部署環境。
- 僅在您的主要登入樹系中使用。 請考慮只在主要登入樹系中部署 Microsoft 365，以初始推出 Microsoft 365。
如果您無法合併多樹系 AD DS 部署，或使用其他目錄服務來管理身分識別，您可以在 Microsoft 或合作夥伴的協助下同步處理它們。
如需詳細資訊，請參閱 Microsoft Entra Connect 的拓撲。
相依於目錄同步處理的功能
下列特性與功能需要目錄同步處理：
- Microsoft Entra無縫單一登入 (SSO)
- Skype共存
- Exchange 混合式部署，包括：
- 內部部署 Exchange 環境與 Microsoft 365 之間完全共用全域通訊清單 (GAL) 。
- 同步處理來自不同郵件系統的 GAL 資訊。
- 能夠將使用者新增至 Microsoft 365 服務供應專案，以及從中移除使用者。 這需要以下內容：
- 在目錄同步設定期間必須配置雙向同步。 依預設，目錄同步處理工具只會將目錄資訊寫入雲端。 當您設定雙向同步處理時，您會啟用回寫功能，以便從雲端複製有限數目的物件屬性，然後將它們寫回本機 AD DS。 回寫也稱為 Exchange 混合模式。
- 內部部署 Exchange 混合式部署。
- 能夠將某些使用者信箱移至 Microsoft 365，同時將其他使用者信箱保留在內部部署。
- 內部部署的安全寄件者和封鎖的寄件者會複寫至 Microsoft 365。
- 基本委派和代表發送電子郵件功能。
- 您有整合式內部部署智慧卡或多重要素驗證解決方案。
- 同步相片、縮圖、會議室和安全群組
一、目錄清理任務
將 AD DS 同步處理至 Microsoft Entra 租使用者之前，您必須先清除 AD DS。
重要事項
如果您在同步處理之前未執行 AD DS 清除，可能會對部署程式造成重大負面影響。 可能需要數天甚至數週的時間來完成目錄同步、識別錯誤和重新同步的週期。
在您的 AD DS 中，針對將獲指派 Microsoft 365 授權的每個使用者帳戶完成下列清除工作：
確保 proxyAddresses 屬性中具有有效且唯一的電子郵件地址。
移除 proxyAddresses 屬性中的任何重複值。
可能的話，請確定使用者使用者物件中userPrincipalName 屬性的有效且唯一的值。 為了獲得最佳同步處理體驗，請確定 AD DS UPN 符合 Microsoft Entra UPN。 如果使用者沒有 userPrincipalName 屬性的值，則 使用者 物件必須包含 sAMAccountName 屬性的有效且唯一值。 移除 userPrincipalName 屬性中的任何重複值。
若要以全域通訊清單 (GAL) 的最佳使用方式，請確定 AD DS 使用者帳戶下列屬性中的資訊正確無誤：
- givenName
- 姓
- displayName
- 職稱
- 部門
- 辦公室
- 辦公室電話
- 行動電話
- 傳真號碼
- 街道地址
- 城市
- 州/省
- 郵遞區號
- 國家或地區
二、目錄物件與屬性準備
AD DS 與 Microsoft 365 之間的成功目錄同步處理需要正確準備 AD DS 屬性。 例如，您必須確保特定字元不會在與 Microsoft 365 環境同步處理的特定屬性中使用。 非預期的字元不會導致目錄同步處理失敗，但可能會傳回警告。 無效字元會導致目錄同步失敗。
如果您的某些 AD DS 使用者有一或多個重複的屬性，目錄同步處理也會失敗。 每個使用者都必須具有唯一的屬性。
您需要準備的屬性如下：
顯示名稱
- 如果屬性存在於使用者物件中，則會與 Microsoft 365 同步處理。
- 如果此屬性存在於使用者物件中，則必須有其值。 也就是說，屬性不得為空白。
- 字元數上限：256
givenName
- 如果屬性存在於使用者物件中，則會與 Microsoft 365 同步處理，但 Microsoft 365 不需要或使用它。
- 字元數上限：64
寄
屬性值在目錄內必須是唯一的。
注意事項
如果有重複的值，則會同步處理具有該值的第一個使用者。 後續使用者不會出現在 Microsoft 365 中。 您必須修改 Microsoft 365 中的值，或修改 AD DS 中的兩個值，才能讓這兩個使用者都出現在 Microsoft 365 中。
mailNickname (Exchange 別名)
屬性值不能以句點 (.) 開頭。
屬性值在目錄內必須是唯一的。
注意事項
同步名稱中的底線 (“_”) 表示此屬性的原始值包含無效字元。 如需此屬性的詳細資訊，請參閱 Exchange 別名屬性。
代理位址
多值屬性
每個值的字元數上限：256
屬性值不得包含空格。
屬性值在目錄內必須是唯一的。
無效字元： <> ( ) ; ， [ ] ”
帶有變音符號的字母，例如元音變音符號、重音符號和波浪號，是無效字元。
無效字元會套用至類型分隔符號和 “：” 之後的字元，因此允許 SMTP：User@contso.com ，但不允許 SMTP：user：M@contoso.com 。
重要事項
所有簡易郵件傳輸協定 (SMTP) 位址都應符合電子郵件訊息標準。 刪除重複或不需要的地址（如果存在）。
sAMAccount名稱
- 字元數上限：20
- 屬性值在目錄內必須是唯一的。
- 無效字元： [ \ “ | ， / ： <> + = ; ？ * ']
- 如果使用者具有無效的 sAMAccountName 屬性，但具有有效的 userPrincipalName 屬性，則會在 Microsoft 365 中建立使用者帳戶。
- 如果 sAMAccountName 和 userPrincipalName 都無效，則必須更新 AD DS userPrincipalName 屬性。
SN (姓氏)
- 如果屬性存在於使用者物件中，則會與 Microsoft 365 同步處理，但 Microsoft 365 不需要或使用它。
目標地址
例如，為使用者填入的 targetAddress 屬性 (SMTP ：tom@contoso.com) 必須出現在 Microsoft 365 GAL 中。 在協力廠商傳訊移轉案例中，這需要 AD DS 的 Microsoft 365 架構延伸模組。 Microsoft 365 架構延伸模組也會新增其他有用的屬性，以管理使用 AD DS 目錄同步處理工具填入的 Microsoft 365 物件。 例如，將會新增 msExchHideFromAddressLists 屬性來管理隱藏的信箱或通訊群組。
- 字元數上限：256
- 屬性值不得包含空格。
- 屬性值在目錄內必須是唯一的。
- 無效字元： \ <> ( ) ; ， [ ] ”
- 所有簡易郵件傳輸協定 (SMTP) 位址都應符合電子郵件訊息標準。
userPrincipalName
- userPrincipalName 屬性必須採用網際網路樣式登入格式，其中使用者名稱後面接著 at 符號 (@) 和網域名稱：例如 user@contoso.com。 所有簡易郵件傳輸協定 (SMTP) 位址都應符合電子郵件訊息標準。
- userPrincipalName 屬性的字元數上限為 113。 在 at 符號 (@) 之前和之後允許特定數量的字元，如下所示：
- 位於 at 符號 (@) 前面的使用者名稱字元數上限：64
- 在 at 符號 (@) 之後的網域名稱字元數上限：48
- 無效字元：\ % & * + / = ？ { } | <> ( ) ; : , [ ] "
- 允許的字符：A – Z、a - z、0 – 9、' 。 - _ ! # ^ ~
- 帶有變音符號的字母，例如元音變音符號、重音符號和波浪號，是無效字元。
- 每個 userPrincipalName 值中都需要 @ 字元。
- @ 字元不能是每個 userPrincipalName 值中的第一個字元。
- 使用者名稱不能以句點 (.) 、& (&) 、空格或 at 符號 (@) 結尾。
- 使用者名稱不能包含任何空格。
- 必須使用可路由網域;例如，無法使用本機或內部網域。
- Unicode 會轉換為底線字元。
- userPrincipalName 不能在目錄中包含任何重複的值。
3.準備userPrincipalName屬性
Active Directory 的設計目的是允許組織中的終端使用者使用 sAMAccountName 或 userPrincipalName 登入您的目錄。 同樣地，使用者可以使用其公司或學校帳戶的使用者主體名稱 (UPN) 登入 Microsoft 365。 目錄同步處理會嘗試使用 AD DS 中的相同 UPN，在 Microsoft Entra ID 中建立新使用者。 UPN 的格式類似於電子郵件地址。
在 Microsoft 365 中，UPN 是用來產生電子郵件地址的預設屬性。 很容易在 AD DS 和 Microsoft Entra ID) 中取得 userPrincipalName (，並將 proxyAddresses 中的主要電子郵件地址設定為不同的值。 當它們設定為不同的值時，系統管理員和使用者可能會感到困惑。
最好對齊這些屬性以減少混淆。 若要符合 Active Directory 同盟服務 (AD FS) 2.0 單一登入的需求，您必須確定 Microsoft Entra ID 中的 UPN 和 AD DS 相符，並使用有效的網域命名空間。
4. 將替代 UPN 尾碼新增至 AD DS
您可能需要新增替代 UPN 尾碼，才能將使用者的公司認證與 Microsoft 365 環境產生關聯。 UPN 尾碼是 @ 字元右側的 UPN 部分。 用於單一登入的 UPN 可包含字母、數字、句號、虛線和底線，但不得包含其他字元類型。
如需如何將替代 UPN 尾碼新增至 Active Directory 的詳細資訊，請參閱 準備目錄同步處理。
5. 將 AD DS UPN 與 Microsoft 365 UPN 進行比對
如果您已設定目錄同步處理，則使用者的 Microsoft 365 UPN 可能不符合 AD DS 中定義的使用者 AD DS UPN。 當使用者在驗證網域之前獲指派授權時，可能會發生此狀況。 若要修正此問題，請使用 PowerShell 修正重複的 UPN 以更新使用者的 UPN，以確保 Microsoft 365 UPN 符合公司使用者名稱和網域。 如果您要更新 AD DS 中的 UPN，並希望它與 Microsoft Entra 身分識別同步處理，您必須先在 Microsoft 365 中移除使用者的授權，才能在 AD DS 中進行變更。
另請參閱 如何準備不可路由的網域 (，例如 .local domain) 進行目錄同步處理。
後續步驟
完成步驟 1 到 5 之後，請參閱 設定目錄同步處理。