準備透過目錄同步處理將使用者佈建到 Office 365

比起在 Office 365 直接管理您的公司或學校帳戶,以目錄同步處理佈建使用者需要更多的規劃和準備。為確保您的內部部署 Active Directory 正確同步處理至 Azure Active Directory,這些額外規劃和準備工作是必要的。貴組織新增的效益包括:

  • 減少貴組織內的系統管理程式

  • 可選擇是否啟用單一登入案例

  • Office 365 帳戶變更自動化

目錄同步處理具有哪些優點,詳細資訊請參閱目錄同步處理藍圖,以及了解 Office 365 身分識別與 Azure Active Directory

若要找出最適合您組織的案例,請檢閱目錄整合工具比較

目錄清理工作

在開始同步處理您的目錄之前,必須先清理目錄。

另請參閱透過 Azure AD Connect 同步到 Azure Active Directory 的屬性

警告: 如果您同步處理前並未執行目錄清理作業,可能會對部署程序造成嚴重的負面影響。系統可能要幾天,甚至是幾週的時間,才能完成完整流程 (即目錄同步處理、識別錯誤以及重新同步處理)。

在您的內部部署目錄中,請執行下列清理工作:

  • 確定每一位將獲指派 Office 365 服務產品的使用者,在 proxyAddresses 屬性中具有有效且唯一的電子郵件地址。

  • proxyAddresses 屬性中移除任何重複的值。

  • 如果可能,請確定每一位將獲指派 Office 365 服務產品的使用者,其 user 物件的 userPrincipalName 屬性中都具有有效且唯一的值。為獲得最佳同步處理體驗,請確定內部部署 Active Directory UPN 與雲端 UPN 一致。如果使用者的 userPrincipalName 屬性沒有任何值,則 user 物件的 sAMAccountName 屬性必須包含有效且唯一的值。請移除 userPrincipalName 屬性中任何重複的值。

  • 若要充分運用全域通訊清單 (GAL),請確定下列屬性中的資訊是否正確:

    • 顯示名稱

    • 職稱

    • 部門

    • 辦公室

    • 辦公室電話

    • 行動電話

    • 傳真號碼

    • 街道地址

    • 城市

    • 省/市

    • 郵遞區號

    • 國家/地區

目錄物件和屬性準備

若要讓內部部署目錄和 Office 365 的目錄同步處理順利完成,您必須為內部部署目錄屬性做好萬全準備。舉例來說,您必須確定與 Office 365 環境同步的某些屬性未使用特定字元。未預期的字元不會導致目錄同步處理失敗,但系統可能會傳回警告。無效字元則會導致目錄同步處理失敗。

此外,如果部分 Active Directory 使用者有一或多個重覆屬性,目錄同步處理也會失敗。每個使用者都必須擁有唯一的屬性。

以下列出您需要準備的屬性:

附註:您也可以使用 IdFix 工具,讓這個處理程序更加簡單。

  • displayName

    • 如果屬性存在於使用者物件中,將會與 Office 365 同步處理。

    • 如果這個屬性存在於使用者物件中,則必須有屬性值。也就是說,屬性不能為空白。

    • 最大字元數:255

  • givenName

    • 如果屬性存在於使用者物件中,將會與 Office 365 同步處理,但 Office 365 並不需要或使用該屬性。

    • 最大字元數:63

  • mail

    • 屬性值在目錄中必須是唯一的。

      附註: 如果有重複值,則擁有該值的第一個使用者會進行同步處理。後續新增的使用者將不會在 Office 365 中顯現。您必須修改 Office 365 中的值,或修改內部部署目錄中的兩個值,如此兩個使用者才會在 Office 365 中顯現。

  • mailNickname (Exchange 別名)

    • 屬性值無法使用句號 (.) 做為開頭。

    • 屬性值在目錄中必須是唯一的。

  • proxyAddresses

    • 多重值屬性

    • 每個值的最大字元數:256

    • 屬性值不能包含空格。

    • 屬性值在目錄中必須是唯一的。

    • 無效的字元:< > ( ) ; , [ ] “

      請注意,無效的字元適用於類型分隔字元和 ":" 之後的字元,例如允許 SMTP:User@contso.com,但不允許 SMTP:user:M@contoso.com。

      重要: 所有的 Simple Mail Transport Protocol (SMTP) 位址應該符合電子郵件訊息標準。如果存在重複或不想要的位址,請參閱說明主題:在 Exchange 中移除重複而不想要的 Proxy 位址

  • sAMAccountName

    • 最大字元數:20

    • 屬性值在目錄中必須是唯一的。

    • 無效的字元:[ \ “ | , / : < > + = ; ? * ]

    • 如果使用者有無效的 sAMAccountName 屬性,但有有效的 userPrincipalName 屬性,則代表使用者帳戶是在 Office 365 中所建立。

    • 如果 sAMAccountNameuserPrincipalName 皆無效,則內部部署 Active DirectoryuserPrincipalName 屬性必須進行更新。

  • sn (姓)

    • 如果屬性存在於使用者物件中,將會與 Office 365 同步處理,但 Office 365 並不需要或使用該屬性。

  • targetAddress

    為使用者填入的 targetAddress 屬性 (例如:SMTP:tom@contoso.com) 必須出現在 Office 365 GAL 中。在協力廠商訊息移轉案例中,這需要 Office 365 內部部署目錄的結構描述延伸模組。Office 365 結構描述延伸模組在使用內部部署目錄的目錄同步處理工具時,也新增了其他有用的屬性以管理填入的 Office 365 物件。例如,將會新增管理隱藏信箱或通訊群組的 msExchHideFromAddressLists 屬性。

    • 最大字元數:255

    • 屬性值不能包含空格。

    • 屬性值在目錄中必須是唯一的。

    • 無效的字元:\ < > ( ) ; , [ ] “

      所有的 Simple Mail Transport Protocol (SMTP) 位址應該符合電子郵件訊息標準。

  • userPrincipalName

    • userPrincipalName 屬性必須使用網際網路樣式的登入格式,使用者名稱後面為 @ 符號及網域名稱:例如 user@contoso.com。

      所有的 Simple Mail Transport Protocol (SMTP) 位址應該符合電子郵件訊息標準。

    • userPrincipalName 屬性的最大字元數為 113。@ 符號前後允許的特定字元數,如下所示:

      • @ 符號前之使用者名稱的最大字元數:64

      • @ 符號後之網域名稱的最大字元數:48

    • 無效的字元:\ % & * + / = ?  { } | < > ( ) ; : , [ ] “

      變母音也是無效字元。

    • 每個 userPrincipalName 值皆需要 @ 字元。

    • 每個 userPrincipalName 值的第一個字元不可以是 @ 字元。

    • 使用者名稱結尾不可以是句號 (.)、& 符號、空格,或是 @ 符號。

    • 使用者名稱不能包含任何空格。

    • 必須使用可路由的網域;舉例來說,不可使用本機或內部網域。

    • Unicode 會轉換為底線字元。

    • 在目錄中,userPrincipalName 不能包含任何重複的值。

準備 userPrincipalName 屬性

Active Directory 的設計目的是要讓貴組織中的使用者以 sAMAccountNameuserPrincipalName 登入您的目錄。同樣地,使用者也可以用其公司或學校帳戶的使用者主體名稱 (UPN) 登入 Office 365。目錄同步處理會嘗試使用您內部部署目錄中相同的 UPN 來建立 Azure Active Directory 中的新使用者。UPN 的格式類似電子郵件地址。在 Office 365,UPN 是用來產生電子郵件地址的預設屬性。將 userPrincipalName (內部部署及 Azure Active Directory 中) 與 proxyAddresses 中之主要電子郵件地址設定為不同的值非常簡單。當兩者設定為不同值時,容易讓系統管理員與使用者感到混淆。

最好的方法是對齊這些屬性,以減少混淆。若要符合使用 Active Directory 同盟服務 (AD FS) 2.0 單一登入的需求,您必須確定 Azure Active Directory 中的 UPN 與您內部部署的 Active Directory 相符合,且使用有效的網域命名空間。

新增替代的 UPN 尾碼至 AD DS

您可能需要新增替代的 UPN 尾碼,以與 Office 365 環境中的使用者公司認證建立關聯。UPN 尾碼是 UPN 字元中 @ 右側的部分。用於單一登入的 UPN 可以包含字母、數字、句點、虛線和底線,但不可包含其他類型的字元。

如需如何新增替代的 UPN 尾碼至 Active Directory 的詳細資訊,請參閱為目錄同步處理做好準備

讓內部部署 UPN 符合 Office 365 UPN

如果您已設定目錄同步處理,則使用者的 Office 365 UPN 可能不符合您內部部署目錄服務中所定義之使用者的內部部署 UPN。在驗證網域之前如果已指派使用者授權,就可能會發生這種情況。若要修正此問題,請使用 PowerShell 修正重複的 UPN 來更新使用者的 UPN,以確保 Office 365 UPN 符合企業的使用者名稱和網域。若您正在更新內部部署目錄服務中的 UPN,並希望 UPN 與 Azure Active Directory 身分識別進行同步處理,則在變更內部部署之前,您需要在 Office 365 移除使用者的授權。

另請參閱如何準備無法路由傳送的網域 (例如 .local 網域) 以用於目錄同步處理

目錄整合工具

「目錄同步處理」是指將內部部署 Active Directory 環境的目錄物件 (使用者、群組和連絡人) 同步處理到 Office 365 目錄基礎結構 (即 Azure Active Directory) 的作業。請參閱目錄整合工具以取得可用工具清單並了解其功能。建議您使用的工具為 Microsoft Azure Active Directory Connect。如需有關 Azure Active Directory 連線的詳細資訊,請參閱整合內部部署身分識別與 Azure Active Directory

當使用者帳戶與 Office 365 目錄第一次同步處理時,會被標示為尚未啟動。他們無法傳送或接收電子郵件,也不會耗用訂閱授權。當您準備好要指派 Office 365 訂閱給特定的使用者時,您必須選取使用者並指派有效的授權以啟用。

您也可以使用 PowerShell 來指派授權。請參閱如何使用 PowerShell 自動指派授權給您的 Office 365 使用者,以了解自動化的解決方案。

相關主題

整合 Office 365 與內部部署環境
修正 Office 365 目錄同步處理的問題

擴展您的技能
探索訓練
優先取得新功能
加入 Office 測試人員

這項資訊有幫助嗎?

感謝您的意見反應!

感謝您的意見反應! 我們將協助您與其中一位 Office 支援專員連絡以深入了解您的意見。

×