準備將目錄同步處理至 Microsoft 365

發行項
09/25/2024

本文適用於 Microsoft 365 企業版和 Office 365 企業版。

如果您在本解決方案的步驟 3 的步驟 2 和使用者帳戶中選擇混合式身分識別模型並設定了系統管理員帳戶的保護，則下一個工作是部署目錄同步處理。您組織目錄同步處理的優點包括：

減少組織中的系統管理程式
選擇性地啟用單一登錄案例
在 Microsoft 365 中自動化帳戶變更

如需使用目錄同步處理優點的詳細資訊，請參閱具有 Microsoft Entra 標識碼的混合式身分識別。

不過，目錄同步處理需要規劃和準備，以確保您的 Active Directory 網域服務 (AD DS) 同步處理至 Microsoft 365 訂用帳戶的 Microsoft Entra 租使用者，併發生最少的錯誤。

請遵循下列步驟，以獲得最佳結果。

注意事項

AD DS 使用者帳戶上的任何屬性不會同步處理非 ASCII 字元。

AD DS 準備

為了協助確保使用同步處理順暢地轉換至 Microsoft 365，您必須在開始 Microsoft 365 目錄同步處理部署之前準備 AD DS 樹系。

您的目錄準備應該著重於下列工作：

拿掉重複的 proxyAddress 和 userPrincipalName 屬性。
使用有效的userPrincipalName屬性更新空白和無效的userPrincipalName屬性。
拿掉 givenName、surname ( 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。
- 基本委派和傳送代理者電子郵件功能。
- 您有整合的內部部署智慧卡或多重要素驗證解決方案。
同步處理相片、縮圖、會議室和安全組

1.目錄清除工作

將 AD DS 同步處理至 Microsoft Entra 租使用者之前，您必須清除 AD DS。

重要事項

如果您在同步處理之前未執行 AD DS 清除，可能會對部署程式造成顯著的負面影響。可能需要數天甚至數周的時間，才能經歷目錄同步處理、識別錯誤和重新同步處理的迴圈。

在您的 AD DS 中，針對將獲指派 Microsoft 365 授權的每個用戶帳戶，完成下列清除工作：

請確定 proxyAddresses 屬性中有有效且唯一的電子郵件位址。
移除 proxyAddresses 屬性中的任何重複值。
可能的話，請確定用戶用戶物件中userPrincipalName屬性的有效且唯一值。如需最佳的同步處理體驗，請確定 AD DS UPN 符合 #D18BB431F991B49769CED4A991A790088 UPN。如果使用者沒有 userPrincipalName 屬性的值，則 使用者 對象必須包含 sAMAccountName 屬性的有效唯一值。移除 userPrincipalName 屬性中的任何重複值。
若要最佳使用 GAL) (全域通訊清單，請確定 AD DS 使用者帳戶下列屬性中的資訊正確無誤：
- givenName
- 姓
- displayName
- 職稱
- 部門
- 辦公室
- 辦公室電話
- 行動電話
- 傳真號碼
- 街道地址
- 城市
- 州/省
- 郵遞區號
- 國家或地區

2.目錄對象和屬性準備

在 AD DS 與 Microsoft 365 之間成功同步處理目錄時，必須正確備妥 AD DS 屬性。例如，您必須確保特定字元不會用於與 Microsoft 365 環境同步的特定屬性中。非預期的字元不會導致目錄同步處理失敗，但可能會傳回警告。無效的字元會導致目錄同步處理失敗。

如果您的某些 AD DS 使用者有一或多個重複的屬性，目錄同步處理也會失敗。每個用戶都必須有唯一的屬性。

您需要準備的屬性如下所欄：

displayName
- 如果屬性存在於用戶物件中，則會與 Microsoft 365 同步處理。
- 如果此屬性存在於用戶物件中，則必須有其值。也就是說，屬性不得為空白。
- 字元數目上限：256
givenName
- 如果屬性存在於用戶物件中，則會與 Microsoft 365 同步處理，但 Microsoft 365 不需要或使用它。
- 字元數目上限：64
mail
- 屬性值在目錄內必須是唯一的。
  
  注意事項
  
  如果有重複的值，則會同步處理具有該值的第一個使用者。後續的使用者將不會出現在 Microsoft 365 中。您必須修改 Microsoft 365 中的值，或修改 AD DS 中的兩個值，才能讓這兩位使用者出現在 Microsoft 365 中。
mailNickname (Exchange 別名)
- 屬性值不能以句號 (.) 開頭。
- 屬性值在目錄內必須是唯一的。
  
  注意事項
  
  同步名稱中的底線 (“_”) 表示這個屬性的原始值包含無效的字元。如需此屬性的詳細資訊，請參閱 Exchange 別名屬性。
proxyAddresses
- 多重值屬性
- 每個值的字元數目上限：256
- 屬性值不得包含空格。
- 屬性值在目錄內必須是唯一的。
- 無效的字元： <> ( ) ; ， [ ] ”
- 具有斜線標記的字母，例如 umlauts、輔色和波狀符號，都是無效的字元。
  
  無效的字元會套用至類型分隔符和 “：” 之後的字元，因此允許 SMTP：User@contso.com ，但不允許 SMTP：user：M@contoso.com 不是。
  
  重要事項
  
  所有簡易郵件傳輸通訊協定 (SMTP) 位址都應該符合電子郵件訊息標準。如果重複或不想要的位址存在，請移除這些位址。
sAMAccountName
- 字元數目上限：20
- 屬性值在目錄內必須是唯一的。
- 不合法的字元： [ \ “ | ， / ： <> + = ; ？ * ']
- 如果使用者的 sAMAccountName 屬性無效，但具有有效的 userPrincipalName 屬性，則會在 Microsoft 365 中建立用戶帳戶。
- 如果 sAMAccountName 和 userPrincipalName 都無效，則必須更新 AD DS userPrincipalName 屬性。
sn (surname)
- 如果屬性存在於用戶物件中，則會與 Microsoft 365 同步處理，但 Microsoft 365 不需要或使用它。
targetAddress

targetAddress 屬性必須 (例如 SMTP：tom@contoso.com為使用者填入的) 必須出現在 Microsoft 365 GAL 中。在第三方傳訊移轉案例中，這需要 AD DS 的 Microsoft 365 架構延伸模組。 Microsoft 365 架構延伸模組也會新增其他有用的屬性，以管理使用 AD DS 的目錄同步處理工具填入的 Microsoft 365 物件。例如，會新增 msExchHideFromAddressLists 屬性來管理隱藏的信箱或通訊群組。
- 字元數目上限：256
- 屬性值不得包含空格。
- 屬性值在目錄內必須是唯一的。
- 無效的字元： \ <> ( ) ; [ ] ”
- 所有簡易郵件傳輸通訊協定 (SMTP) 位址都應該符合電子郵件訊息標準。
userPrincipalName
- userPrincipalName 屬性必須是因特網樣式的登入格式，其中使用者名稱後面接著 at sign (@) 和功能變數名稱：例如。 user@contoso.com 所有簡易郵件傳輸通訊協定 (SMTP) 位址都應該符合電子郵件訊息標準。
- userPrincipalName 屬性的最大字元數為 113。在 at 符號 (@) 前後允許特定數目的字元，如下所示：
- at 符號前面的用戶名稱字元數目上限 (@) ：64
- 在 at 符號之後的域名字符數目上限 (@) ：48
- 不合法的字元： \ % & * + / = ？ { } | <> ( ) ; : , [ ] "
- 允許的字元：A – Z、a - z、0 – 9、' 。 - _ ! # ^ ~
- 具有斜線標記的字母，例如 umlauts、輔色和波狀符號，都是無效的字元。
- 每個 userPrincipalName 值中都需要 @ 字元。
- @ 字元不能是每個 userPrincipalName 值中的第一個字元。
- 使用者名稱的結尾不能是句號 (.) 、連字元 (&) 、空格或 at sign (@) 。
- 用戶名稱不能包含任何空格。
- 必須使用可路由網域;例如，無法使用本機或內部網域。
- Unicode 會轉換成底線字元。
- userPrincipalName 不能在目錄中包含任何重複的值。

3.準備 userPrincipalName 屬性

Active Directory 的設計目的是要允許組織中的使用者使用 sAMAccountName 或 userPrincipalName 登入您的目錄。同樣地，使用者可以使用用戶主體名稱 (公司或學校帳戶的 UPN) 登入 Microsoft 365。目錄同步處理會嘗試使用AD DS中的相同UPN，在Microsoft Entra識別碼中建立新的使用者。 UPN 的格式就像電子郵件地址一樣。

在 Microsoft 365 中，UPN 是用來產生電子郵件地址的預設屬性。在 AD DS 和 Microsoft Entra 識別子) 中，將 proxyAddresses 中的主要電子郵件地址設定為不同的值，很容易就能取得 userPrincipalName (。當它們設定為不同的值時，系統管理員和使用者可能會混淆。

最好對齊這些屬性，以減少混淆。若要符合使用 Active Directory 同盟服務 (AD FS) 2.0 進行單一登錄的需求，您必須確定 Microsoft Entra 標識符中的 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 身分識別同步處理，您必須在 AD DS 中進行變更之前，先移除 Microsoft 365 中的使用者授權。

另請參閱如何準備不可路由傳送的網域 (，例如 .local 網域) 以進行目錄同步處理。

後續步驟

完成步驟 1 到 5 之後，請參閱設定目錄同步處理。

共用方式為