共用方式為

設定 Microsoft Entra ID 以將使用者佈建到 LDAP 目錄

  • 發行項

下列文件提供的設定和教學課程資訊會示範如何將使用者從 Microsoft Entra ID 佈建到 LDAP 目錄。

本文件說明將使用者從 Microsoft Entra ID 自動佈建和取消佈建至 LDAP 目錄所需執行的步驟。 本文說明將使用者佈建到 AD LDS 做為範例 LDAP 目錄的方式，但您可以佈建到下列各節所述的任何支援 LDAP 目錄伺服器。 不支援透過此解決方案將使用者佈建到 Active Directory Domain Services。

如需此服務的用途、運作方式和常見問題等重要詳細資訊，請參閱使用 Microsoft Entra ID 對 SaaS 應用程式自動佈建和取消佈建使用者和內部部署應用程式佈建架構。 下列影片提供內部部署佈建的概觀。

將使用者佈建至 LDAP 目錄的必要條件

內部部署必要條件

  • 使用目錄伺服器來查詢使用者的應用程式。
  • 目標目錄，除 Active Directory Domain Services 以外，您可以在其中建立、更新和刪除使用者。 例如 Active Directory 輕量型目錄服務 (AD LDS)。 此目錄執行個體不該是同時用來將使用者佈建至 Microsoft Entra ID 的目錄，因為兩種情節都可能因為 Microsoft Entra Connect 產生迴圈。
  • 具備至少 3 GB RAM 的電腦，用於託管佈建代理程式。 電腦應具有 Windows Server 2016 或更新版本的 Windows Server，配備目標目錄的連線能力及 login.microsoftonline.com 的連線輸出、其他 Microsoft Online Services 和 Azure 網域。 例如，裝載於 Azure IaaS 或 Proxy 後方的 Windows Server 2016 虛擬機器。
  • 必須安裝 .NET Framework 4.7.2。
  • 選用：雖然並非必要，但建議您下載適用於 Windows Server 的 Microsoft Edge，並用其取代 Internet Explorer。

支援的 LDAP 目錄伺服器

連接器會依賴各種技巧來偵測和識別 LDAP 伺服器。 連接器會使用根 DSE、廠商名稱/版本，而且檢查結構描述，以找出已知存在某些 LDAP 伺服器中的唯一物件和屬性。

  • OpenLDAP
  • Microsoft Active Directory 輕量型目錄服務
  • 389 Directory Server
  • Apache Directory Server
  • IBM Tivoli DS
  • Isode Directory
  • NetIQ eDirectory
  • Novell eDirectory
  • Open DJ
  • Open DS
  • Oracle (之前為 Sun ONE) Directory Server Enterprise Edition
  • RadiantOne Virtual Directory Server (VDS)

如需更多資訊，請參閱泛型 LDAP 連接器參考文件。

雲端需求

  • 一個具有 Microsoft Entra ID P1 或 Premium P2 (或 EMS E3 或 E5) 授權的 Microsoft Entra 租用戶。

    使用此功能需要 Microsoft Entra ID P1 授權。 若要尋找適合您需求的授權，請參閱比較 Microsoft Entra ID 正式推出的功能。

  • 用於設定佈建代理程式的混合式身分識別系統管理員角色，以及用來在 Azure 入口網站中設定佈建的應用程式系統管理員或雲端應用程式系統管理員角色。

  • 要佈建至 LDAP 目錄的 Microsoft Entra 使用者必須已填入目錄伺服器結構描述所需的屬性，而且是每個使用者特有的屬性。 例如，如果目錄伺服器要求每位使用者擁有介於 10000 到 30000 之間的唯一數位作為其使用者識別碼，以支援 POSIX 工作負載，則您必須從使用者的現有屬性產生該號碼，或擴充 Microsoft Entra 結構描述，並在 LDAP 型應用程式範圍內的使用者填入該屬性。 如需如何建立其他目錄延伸模組，請參閱 Graph 擴充性。

更多建議和限制

下列項目符號點是更多的建議和限制。

  • 不建議您使用相同的代理程式進行雲端同步和內部部署應用程式佈建。 Microsoft 建議使用不同的代理程式來進行雲端同步，並使用一個代理程式來進行內部部署應用程式佈建。
  • AD LDS 目前無法以密碼佈建使用者。 因此，您必須停用 AD LDS 的密碼原則，或在停用狀態下佈建使用者。
  • 對於其他目錄伺服器，可以設定初始隨機密碼，但無法將 Microsoft Entra 使用者的密碼佈建到目錄伺服器。
  • 不支援將使用者從 Microsoft Entra ID 佈建至 Active Directory Domains Services。
  • 不支援將使用者從 LDAP 佈建至 Microsoft Entra ID。
  • 不支援將群組和使用者成員資格佈建至目錄伺服器。

選取執行設定檔

當您建立連接器的設定以與目錄伺服器互動時，會先設定連接器讀取目錄的結構描述，對應該結構描述至 Microsoft Entra ID，然後透過執行設定檔來設定連接器應該持續使用的方法。 您將為每個執行設定檔指定連接器產生 LDAP要求的方式，以從目錄伺服器匯入或匯出資料。 將連接器部署至現有的目錄伺服器之前，您必須與組織中的目錄伺服器操作員討論將會與其目錄伺服器一起執行的作業模式。

  • 設定之後，當佈建服務啟動時，就會自動執行 [完整匯入] 執行設定檔中所設定的互動。 在此執行設定檔中，連接器會使用 LDAP 搜尋作業，讀取目錄中所有使用者的記錄。 此執行設定檔是必要的，因為如此一來，Microsoft Entra ID 需要變更使用者時，Microsoft Entra ID 就會更新目錄中該使用者的現有物件，而不是為該使用者建立新的物件。

  • 每次在 Microsoft Entra ID 進行變更 (例如將新使用者指派給應用程式或更新現有使用者) 時，佈建服務都會執行匯出執行設定檔中的 LDAP 互動。 在匯出執行設定檔中，Microsoft Entra ID 會發出 LDAP 要求，以在目錄中新增、修改、移除或重新命名物件，以便讓目錄的內容與 Microsoft Entra ID 同步。

  • 如果您的目錄予以支援，則您也可以選擇性地設定「差異匯入」執行設定檔。 在此執行設定檔中，Microsoft Entra ID 將會讀取自上次完整匯入或差異匯入以來，目錄中非 Microsoft Entra ID 進行的變更。 此執行設定檔為選用，因為目錄可能尚未設定為支援差異匯入。 例如，如果您的組織使用 OpenLDAP，則必須使用啟用存取記錄重疊功能來部署 OpenLDAP。

判斷 Microsoft Entra LDAP 連接器會如何與a目錄伺服器互動

將連接器部署至現有的目錄伺服器之前，您必須與組織中的目錄伺服器操作員討論整合其目錄伺服器的方式。 您將收集的資訊包括如何連線到目錄伺服器的網路資訊、連接器應該如何向目錄伺服器驗證、目錄伺服器已選取哪些結構描述來建立使用者模型、命名內容的基準辨別名稱和目錄階層規則、如何將目錄伺服器中的使用者與 Microsoft Entra ID 中的使用者產生關聯， 以及當使用者超出 Microsoft Entra ID 的範圍時會發生什麼事。 部署此連接器可能需要變更目錄伺服器的設定以及 Microsoft Entra ID 的設定。 對於在生產環境中整合 Microsoft Entra ID 與第三方目錄伺服器的部署，我們建議客戶與其目錄伺服器廠商或部署夥伴合作以取得協助、指導和支援此整合。 本文針對 AD LDS 和 OpenLDAP 使用下列兩個目錄的範例值。

組態設定 設定值的位置 範例值
目錄伺服器的主機名稱 設定精靈連線能力頁面 APP3
目錄伺服器的連接埠號碼 設定精靈連線能力頁面 636.對於基於 SSL 或 TLS 的 LDAP (LDAPS)，請使用連接埠 636。 針對 Start TLS，請使用連接埠 389。
用來向目錄伺服器識別本身的連接器帳戶 設定精靈連線能力頁面 針對 AD LDS、CN=svcAccountLDAP,CN=ServiceAccounts,CN=App,DC=contoso,DC=lab 和 OpenLDAP，cn=admin,dc=contoso,dc=lab
用來向目錄伺服器驗證本身的連接器密碼 設定精靈連線能力頁面
目錄伺服器中使用者的結構物件類別 設定精靈物件類型頁面 針對 AD LDS User 和針對 OpenLDAPinetOrgPerson
目錄伺服器中使用者的輔助物件類別 Azure 入口網站佈建頁面屬性對應 針對具有 POSIX 架構的 OpenLDAP，posixAccount 和shadowAccount
在新使用者上填入屬性 設定精靈選取屬性頁面和 Azure 入口網站佈建頁面屬性對應 針對 AD LDS msDS-UserAccountDisabled、userPrincipalName、displayName 和針對 OpenLDAP cn、gidNumber、homeDirectory、mail、objectClass、sn、uid、uidNumber、userPassword
目錄伺服器所需的命名階層 Azure 入口網站佈建頁面屬性對應 將新建立使用者的 DN 設定為緊接在 AD LDS 的 CN=CloudUsers,CN=App,DC=Contoso,DC=lab 下方，並針對 OpenLDAP 設定 DC=Contoso,DC=lab
共同關係使用者的屬性可跨 Microsoft Entra ID 和目錄伺服器 Azure 入口網站佈建頁面屬性對應 針對未設定為此範例的 AD LDS，是適用於初始空白目錄，和 OpenLDAP，mail
當使用者超出 Microsoft Entra ID 的範圍時，取消佈建行為 設定精靈取消佈建頁面 從目錄伺服器刪除使用者

目錄伺服器的網路位址是主機名稱和 TCP 通訊埠號碼，通常是連接埠 389 或 636。 除了目錄伺服器與相同 Windows Server 上的連接器共置，或是您使用的是網路層級安全性，否則從連接器到目錄伺服器的網路連線必須使用 SSL 或 TLS 來保護。 連接器支持連線到連接埠 389 上的目錄伺服器，並使用開始 TLS 在工作階段內啟用 TLS。 連接器也支援在連接埠 636 上連線到 LDAPS - 基於 TLS 的 LDAP 的目錄伺服器。

您必須有連接器的已識別帳戶，才能向目錄伺服器中已設定的目錄伺服器進行驗證。 此帳戶通常會以辨別名稱進行識別，且具有相關聯的密碼或用戶端憑證。 若要在連接的目錄中的物件上執行匯入及匯出作業，連接器帳戶必須在目錄的存取控制模組內具有足夠的權限。 連接器需要寫入權限才能匯出，需要讀取權限才能匯入。 權限設定是在目標目錄本身的管理經驗內執行。

目錄結構描述會指定物件類別和屬性，這些物件類別和屬性代表目錄中的實際實體。 連接器支援以結構物件類別表示的使用者，例如 inetOrgPerson，以及選用的額外輔助物件類別。 為了在 Azure 入口網站中的設定期間，讓連接器能夠將使用者佈建到目錄伺服器，您將定義從 Microsoft Entra 結構描述到所有必要屬性的對應。 這包括結構物件類別的強制屬性、該結構物件類別的任何超級類別，以及任何輔助物件類別的強制屬性。 此外，您可能也會設定這些類別的一些選選用屬性對應。 例如，OpenLDAP 目錄伺服器可能需要物件，讓新使用者擁有類似下列範例的屬性。

dn: cn=bsimon,dc=Contoso,dc=lab
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
cn: bsimon
gidNumber: 10000
homeDirectory: /home/bsimon
sn: simon
uid: bsimon
uidNumber: 10011
mail: bsimon@contoso.com
userPassword: initial-password

目錄伺服器所實作的目錄階層規則，描述每個使用者的物件以及目錄中現有物件彼此相關的方式。 在大部分的部署中，組織選擇在其目錄伺服器中有一個一般階層，其中每個使用者的每個物件都位於通用基底物件之下。 例如，如果目錄伺服器中命名內容的基準辨別名稱是 dc=contoso,dc=com，則新使用者會有像 cn=alice,dc=contoso,dc=com的辨別名稱。 不過，某些組織可能會有更複雜的目錄階層，在此情況下，您必須在指定連接器的辨別名稱對應時實作規則。 例如，目錄伺服器可能會預期使用者依部門位於組織單位，因此新使用者會有像 cn=alice,ou=London,dc=contoso,dc=com 的辨別名稱。 由於連接器不會為組織單位建立中繼物件，因此目錄伺服器規則階層預期的任何中繼物件都必須存在於目錄伺服器中。

接下來，您必須定義連接器應該如何判斷目錄伺服器中是否有使用者對應至 Microsoft Entra 使用者的規則。 每個 LDAP 目錄都有目錄伺服器中每個物件唯一的辨別名稱，不過，Microsoft Entra ID 中的使用者通常不會有辨別名稱。 相反地，組織可能會有不同的屬性，例如 mail 或 employeeId，其目錄伺服器結構描述中也會存在於其 Microsoft Entra ID 中的使用者。 然後，當連接器將新的使用者佈建到目錄伺服器時，連接器可以搜尋該目錄中是否有使用者具有該屬性的特定值，而且只有在目錄伺服器中沒有使用者時，才會在目錄伺服器中建立新的使用者。

如果您的案例牽涉到在 LDAP 目錄中建立新使用者，而不只是更新或刪除現有的使用者，則您也必須判斷使用該目錄伺服器的應用程式該如何處理驗證。 建議的方法是讓應用程式使用 SAML、OAuth 或 OpenID Connect 等同盟或 SSO 通訊協定向 Microsoft Entra ID 進行驗證，並且只依賴目錄伺服器的屬性。 傳統上，應用程式可以使用 LDAP 目錄透過檢查密碼來驗證使用者，但多重要素驗證或使用者已經過驗證時，則無法使用此使用案例。 有些應用程式可以從目錄中查詢使用者的 SSH 公開金鑰或憑證，可能適合使用者已持有這些表單的認證。 不過，如果您的應用程式依賴目錄伺服器，但不支援新式驗證通訊協定或增強的認證，則您必須在目錄中建立新使用者時設定應用程式特定的密碼，因為 Microsoft Entra ID 不支援佈建使用者的 Microsoft Entra 密碼。

最後，您必須同意取消佈建行為。 當連接器已設定，且 Microsoft Entra ID 已為 Microsoft Entra ID 使用者與目錄中的使用者建立連結時，無論是針對目錄現有使用者或新使用者，Microsoft Entra ID 都可將屬性變更從 Microsoft Entra ID 使用者佈建到目錄中。 如果在 Microsoft Entra ID 中刪除指派給應用程式的使用者，則 Microsoft Entra ID 會將刪除作業傳送至目錄伺服器。 當使用者超出可使用應用程式的範圍時，您也許會想要讓 Microsoft Entra ID 更新目錄伺服器中的物件。 此行為取決於將使用目錄伺服器的應用程式，因為許多目錄，例如 OpenLDAP，可能沒有預設的方式來指出使用者帳戶已停用。

準備 LDAP 目錄

如果您還沒有目錄伺服器並想要試用這項功能，請參閱從 Microsoft Entra ID 準備 Active Directory 輕量型目錄服務以用於佈建，顯示如建立測試 AD LDS 環境。 如果您已經部署了另一個目錄伺服器，您可以跳過該文章，並繼續安裝及設定 ECMA 連接器主機。

安裝並設定 Microsoft Entra Connect 佈建代理程式

如果您已經下載佈建代理程式，並已為另一個內部部署應用程式設定，請繼續閱讀下一節。

  1. 登入 Azure 入口網站。
  2. 移至企業應用程式，然後選取 [新的應用程式]。
  3. 搜尋 [內部部署 ECMA 應用程式] 的應用程式，提供應用程式名稱，然後選取 [建立] 以將其新增至您的租用戶。
  4. 從功能表瀏覽至應用程式的 [佈建] 頁面。
  5. 選取開始使用。
  6. 在 [佈建] 頁面上，將模式變更為 [自動]。

顯示選取 [自動] 的螢幕擷取畫面。

  1. 在 [內部部署連線能力] 下，選取 [下載並安裝]，然後選取 [接受條款並下載]。

顯示代理程式下載位置的螢幕擷取畫面。

  1. 離開入口網站，並開啟佈建代理程式的安裝程式，同意服務條款，然後選取 [安裝]。
  2. 等待 Microsoft Entra 佈建代理程式設定精靈，然後選取 [下一步]。
  3. 在 [選擇延伸模組] 步驟中，選取 [內部部署應用程式佈建]，然後選取 [下一步]。
  4. 佈建代理程式會使用作業系統的網頁瀏覽器來顯示快顯視窗，讓您驗證 Microsoft Entra ID，並有可能會顯示您組織的識別提供者。 如果您使用 Internet Explorer 做為 Windows Server 上的瀏覽器，您可能需要將 Microsoft 網站新增至瀏覽器的受信任網站清單，以允許 JavaScript 正確執行。
  5. 當系統提示您授權時，請提供 Microsoft Entra 系統管理員的認證。 使用者必須至少有混合式身分識別系統管理員角色。
  6. 選取 [確認] 以確認設定。 安裝成功之後，您可以選取 [離開]，同時關閉 [佈建代理程式套件] 安裝程式。

設定內部部署 ECMA 應用程式

  1. 返回入口網站，在 [內部部署連線能力] 區段中，選取您已部署的代理程式，然後選取 [指派代理程式]。

    顯示如何選取並指派代理程式的螢幕擷取畫面。

  2. 在您使用設定精靈完成下個步驟的設定時，請讓此瀏覽器視窗保持開啟。

設定 Microsoft Entra ECMA Connector Host 憑證

  1. 在已安裝佈建代理程式的 Windows Server 上，從 [開始] 功能表以滑鼠右鍵按一下 [Microsoft ECMA2Host Configuration Wizard]，然後以系統管理員身分執行。 精靈必須以 Windows 系統管理員身分執行，才能建立必要的 Windows 事件記錄檔。
  2. 啟動 ECMA Connector Host Configuration 之後，如果這是您第一次執行精靈，系統會要求您建立憑證。 保留預設連接埠 8585 並選取 [產生憑證] 來產生憑證。 自動產生的憑證將會自我簽署成為可信任根的一部分。 SAN 符合主機名稱。 顯示進行設定的螢幕擷取畫面。
  3. 選取 [儲存]。

注意

如果您選擇產生新的憑證，請記下憑證到期日，以確保排程傳回設定精靈，並在憑證到期之前重新產生憑證。

設定一般 LDAP 連接器

視您選取的選項而定，部分的精靈畫面可能無法使用，且資訊可能稍有不同。 為了進行此範例設定，會針對 AD LDS 顯示具有 [使用者] 物件類別的使用者，以及OpenLDAP的 [inetOrgPerson] 物件類別。 使用下列資訊引導您進行設定。

  1. 產生用來向連接器驗證 Microsoft Entra ID 的秘密權杖。 每個應用程式至少應為 12 個字元且是唯一的。 如果您還沒有密碼產生器，您可以使用如下所示的 PowerShell 命令來產生隨機字串範例。

    -join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_})

  2. 如果您尚未這麼做，請從 [開始] 功能表啟動 Microsoft ECMA2Host Configuration Wizard。

  3. 選取新增連接器。 顯示選擇 [新增連接器] 的螢幕擷取畫面。

  4. 在 [屬性] 頁面上，在方塊中填入影像後面表格中所指定的值，然後選取 [下一步]。 顯示輸入屬性的螢幕擷取畫面。

    屬性 值
    名稱 您為連接器選擇的名稱，該名稱在環境中的所有連接器中應都是唯一的。 例如： LDAP 。
    自動同步計時器 (分鐘) 120
    祕密權杖 在這裡輸入您的秘密權杖。 最少 12 個字元。
    延伸模組 DLL 針對泛型 LDAP 連接器，請選取 [Microsoft.IAM.Connector.GenericLdap.dll]。

  5. 在 [連線能力] 頁面上，您將設定 ECMA Connector 主機如何與您的目錄伺服器通訊，並設定部分設定選項。 在方塊中填入影像後面表格中所指定的值，然後選取 [下一步]。 當您選取 [下一步]時，連接器會查詢目錄伺服器是否有其設定。 顯示 [連線能力] 頁面的螢幕擷取畫面。

    屬性 描述
    Host LDAP 伺服器所在的主機名稱。 此範例會使用 APP3 作為範例主機名稱。
    連接埠 TCP 連接埠號碼。 如果目錄伺服器已針對 LDAP over SSL 進行設定，請使用連接埠 636。 針對 Start TLS，或如果您使用網路層級安全性，請使用連接埠 389。
    連接逾時 180
    繫結 此屬性會指定連接器如何向目錄伺服器進行驗證。 透過 Basic 設定，或使用 SSL 或 TLS 設定且未設定任何用戶端憑證，連接器會傳送 LDAP 簡單系結，以辨別名稱和進行密碼驗證。 透過 SSL 或 TLS 設定和指定的用戶端憑證，連接器會傳送 LDAP SASL EXTERNAL 繫結以向用戶端憑證進行驗證。
    使用者名稱 ECMA Connector 如何向目錄伺服器驗證它自己。 在此 AD LDS 範例中，範例使用者名稱為 CN=svcAccount,CN=ServiceAccounts,CN=App,DC=contoso,DC=lab，而 OpenLDAP 則為cn=admin,dc=contoso,dc=lab
    密碼 使用者的密碼，將 ECMA Connector 向目錄伺服器驗證它自己。
    領域/領域 只有在您選取 Kerberos 做為 [繫結] 選項時，才需要此設定，才能提供使用者的領域/網域。
    [MSSQLSERVER 的通訊協定內容] 只有在您選取 SSL 或 TLS 做為 [繫結] 選項時，才會使用本節中的設定。
    屬性別名 屬性別名文字方塊使用於以 RFC4522 語法在結構描述中定義的屬性。 在結構描述偵測期間無法偵測這些屬性，而連接器需要協助才能識別這些屬性。 例如，如果目錄伺服器沒有發佈 userCertificate;binary，而且您希望佈建該屬性，則必須在 [屬性別名] 方塊中輸入下列字串，才能正確地將 userCertificate 屬性識別為二進位屬性：userCertificate;binary。 如果您的結構描述中不需要任何特殊屬性，您可以將此保留空白。
    包括操作屬性 選取 [Include operational attributes in schema] 核取方塊，同時包括目錄伺服器所建立的屬性。 其中包含物件的建立時間和上次更新時間等屬性。
    包括可延伸屬性 如果目錄伺服器中使用可延伸物件(RFC4512/4.3)，請選取 [Include extensible attributes in schema] 核取方塊。 啟用此選項可讓所有物件上使用每個屬性。 選取此選項會讓結構描述變得非常大，所以除非連接的目錄使用這項功能，否則建議不要選取這個選項。
    允許手動選取錨點 請勿核取。

    注意

    如果您在嘗試連線時遇到問題，並且無法進行 [全域] 頁面，請確定已啟用 AD LDS 或其他目錄伺服器中的服務帳戶。

  6. 在 [全域] 頁面上，如有需要，您將設定差異變更記錄的辨別名稱，以及其他 LDAP 功能。 此頁面會預先填入以 LDAP 伺服器所提供的資訊。 檢閱顯示的值，然後選取 [下一步]。

    屬性 說明
    支援的 SASL 機制 最上方區段顯示伺服器本身所提供的資訊，包括列出 SASL 機制。
    伺服器憑證詳細資料 如果已指定 SSL 或 TLS，精靈將會顯示目錄伺服器傳回的憑證。 確認簽發者、主旨和指紋，適用於正確的目錄伺服器。
    找到必要功能 連接器也會確認強制控制項是否位於根 DSE 中。 如果未列出這些控制項，則會顯示一則警告。 某些 LDAP 目錄不會列出根 DSE 中的所有功能，而即使出現警告，連接器也可能正常運作。
    支援的控制項 [支援的控制項] 核取方塊可控制特定作業的行為
    差異匯入 變更記錄檔 DN 是差異變更記錄檔所使用的命名內容，例如 cn=discovery。 必須指定此值，才能夠進行差異匯入。
    密碼屬性 如果目錄伺服器支援不同的密碼屬性或密碼雜湊，您可以指定密碼變更的目的地。
    磁碟分割名稱 在其他資料分割清單中，可以新增其他未自動偵測到的命名空間。 比方說，如果有幾部應同時全部匯入的伺服器組成一個邏輯叢集，則可使用此設定。 就如同 Active Directory 可以在一個樹系中有多個網域，而所有網域都共用一個結構描述，在此方塊中輸入其他命名空間就可以模擬此狀況。 每個命名空間都可以從不同的伺服器匯入，並可在 [設定資料分割和階層] 頁面上進一步設定。

  7. 在 [資料分割] 頁面上保留預設值，然後選取 [下一步]。

  8. 在 [執行配置檔] 頁面上，確定已選取 [匯出] 核取方塊和 [完整匯入] 核取方塊。 然後選取下一步。 顯示 [執行設定檔] 頁面的螢幕擷取畫面。

    屬性 說明
    Export 將資料匯出至 LDAP 目錄伺服器的執行設定檔。 此執行設定檔是必要的。
    完整匯入 此執行設定檔會從先前指定的 LDAP 來源匯入所有資料。 此執行設定檔是必要的。
    差異匯入 執行設定檔，此設定檔只會匯入自上次完整或差異匯入之後 LDAP 的變更。 只有在您確認目錄伺服器符合必要需求時，才啟用此執行設定檔。 如需更多資訊，請參閱泛型 LDAP 連接器參考文件。

  9. 在 [匯出] 頁面上保留預設值不變，然後按一下 [下一步]。

  10. 在 [完整匯入] 頁面上保留預設值不變，然後按一下 [下一步]。

  11. 在 [增量匯入] 頁面上 (如有) 保留預設值不變，然後按一下 [下一步]。

  12. 在 [物件類型] 頁面上，填寫方塊，然後選取 [下一步]。

    屬性 說明
    目標物件 此值是 LDAP 目錄伺服器中使用者的結構物件類別。 例如，openLDAP 的 inetOrgPerson，或 AD LDS 的 User。 請勿在此欄位中指定輔助物件類別。 如果目錄伺服器需要輔助物件類別，則會使用 Azure 入口網站中的屬性對應來設定。
    錨點 此屬性的值對於目標目錄中的每個物件而言應該是唯一的。 Microsoft Entra 佈建服務會在初始週期之後使用此屬性查詢 ECMA Connector 主機。 針對 AD LDS，請使用 ObjectGUID 和其他目錄伺服器，請參閱下表。 請注意，辨別名稱可能會選取為 -dn-。 多重值屬性，例如 OpenLDAP 架構中的 uid 屬性，不能當做錨點使用。
    查詢屬性 此屬性應該與 [錨點] 相同，例如，如果 AD LDS 是目錄伺服器，則為 objectGUID，如果是 OpenLDAP 則為 _distinguishedName。
    DN 目標物件的 distinguishedName。 保留 -dn-。
    自動產生 unchecked

    下表列出 LDAP 伺服器清單和所使用的錨點：

    Directory 錨點
    Microsoft AD LDS 和 AD GC objectGUID。 您必須使用代理程式 1.1.846.0 版或更新版本，ObjectGUID 才能作為錨點運作。
    389 Directory Server dn
    Apache Directory dn
    IBM Tivoli DS dn
    Isode Directory dn
    Novell/NetIQ eDirectory GUID
    Open DJ/DS dn
    Open LDAP dn
    Oracle ODSEE dn
    RadiantOne VDS dn
    Sun One Directory Server dn

  13. ECMA 主機會探索目標目錄所支援的屬性。 您可以選擇要公開給 Microsoft Entra ID 的屬性。 接著即可在 Azure 入口網站中設定這些屬性，以供佈建。 在 [選取屬性] 頁面上，逐一新增下拉式清單中的所有屬性，這些屬性是必要屬性或您想要從 Microsoft Entra ID 佈建的屬性。 顯示 [選取屬性] 頁面的螢幕擷取畫面。
    [屬性] 下拉式清單會顯示在目標目錄中探索到而且未在先前使用組態精靈的 [選取屬性] 頁面上選擇的任何屬性。

    請確定已對於 objectClass 屬性取消核取的 Treat as single value 核取方塊，如果已設定 userPassword，則對於 userPassword 屬性無法選取或檢查。

    如果您使用 OpenLDAP 搭配 inetOrgPerson 結構描述，請設定下列屬性的可見性。

    屬性 將其視為單一個值
    cn Y
    mail Y
    objectClass
    sn Y
    userPassword Y

    如果您使用 OpenLDAP 搭配 POSIX 結構描述，請設定下列屬性的可見性。

    屬性 將其視為單一個值
    _distinguishedName
    -dn-
    export_password
    cn Y
    gidNumber
    homeDirectory
    mail Y
    objectClass
    sn Y
    uid Y
    uidNumber
    userPassword Y

    所有相關屬性都新增完成後，請選取 [下一步]。

  14. 在 [取消佈建] 頁面上，您可以指定是否要在使用者超出應用程式範圍時，讓 Microsoft Entra ID 從目錄中移除使用者。 若是，請在 [停用流程] 底下選取 [刪除]，然後在 [刪除流程] 底下選取 [刪除]。 如果已選擇 Set attribute value，在前一頁選取的屬性將無法在 [取消佈建] 頁面上選取。

注意

如果您使用 [設定屬性值]，請注意屬性值只允許布林值。

  1. 選取 [完成]。

確定 ECMA2Host 服務正在執行中，並可從目錄伺服器讀取

請遵循下列步驟，確認連接器主機已啟動，並已從目錄伺服器的連接器主機識別出任何現有的使用者。

  1. 在執行 Microsoft Entra ECMA Connector 主機的伺服器上，選取 [啟動]。
  2. 視需要選取 [執行]，然後在方塊中輸入 services.msc。
  3. 在 [服務] 清單中，確定 Microsoft ECMA2Host 存在且正在執行。 如果並未執行，請選取 [開始]。 顯示正在執行服務的螢幕擷取畫面。
  4. 如果您最近已啟動服務，且目錄伺服器中有許多使用者物件，則請等候數分鐘，讓連接器與目錄伺服器建立連線。
  5. 在執行 Microsoft Entra ECMA Connector 主機的伺服器上，啟動 PowerShell。
  6. 變更為已安裝 ECMA 主機的資料夾，例如 C:\Program Files\Microsoft ECMA2Host。
  7. 變更為子目錄 Troubleshooting。
  8. 如下列範例中所示目錄中執行指令碼 TestECMA2HostConnection.ps1，並提供連接器名稱和ObjectTypePath值cache作為引數。 如果您的連接器主機未接聽 TCP 連接埠 8585，則您可能也需要提供 -Port 引數。 出現提示時，輸入為該連接器設定的秘密權杖。 
    PS C:\Program Files\Microsoft ECMA2Host\Troubleshooting> $cout = .\TestECMA2HostConnection.ps1 -ConnectorName LDAP -ObjectTypePath cache; $cout.length -gt 9
Supply values for the following parameters:
SecretToken: ************
  9. 如果指令碼顯示錯誤或警告訊息，請檢查服務是否正在執行，且連接器名稱和秘密權杖是否符合您在設定精靈中設定的值。
  10. 如果指令碼顯示輸出 False，則連接器尚未在來源目錄伺服器中看到現有使用者的任何內容。 如果這是新的目錄伺服器安裝，則此為正常情況，您可以繼續進行下一節。
  11. 不過，如果目錄伺服器已經包含一或多個使用者，但指令碼顯示 False，則此狀態表示連接器無法讀取目錄伺服器中的內容。 如果您嘗試佈建，則 Microsoft Entra ID 可能無法正確比對該來源目錄中的使用者與 Microsoft Entra ID 中的使用者。 請等待幾分鐘，等到連接器主機完成從現有目錄伺服器讀取物件，再重新執行指令碼。 如果輸出持續為 False，請檢查連接器的設定，以及目錄伺服器中的權限是否允許連接器讀取現有的使用者。

測試從 Microsoft Entra ID 到連接器主機的連線

  1. 返回您在入口網站中設定應用程式佈建的網頁瀏覽器視窗。

    注意

    如果視窗逾時，您則必須重新選取代理程式。

    1. 登入 Azure 入口網站。
    2. 移至 [企業應用程式] 和 [內部部署 ECMA 應用程式] 應用程式。
    3. 按一下 [佈建]。
    4. [開始] 出現時，將模式變更為 [自動]，在 [內部部署連線能力] 區段中，選取您剛剛部署的代理程式，然後選取 [指派代理程式]，然後等待 10 分鐘。 否則，請移至 [編輯佈建]。

  2. 在 [管理員認證] 區段底下，輸入下列 URL。 將 connectorName 部分取代為 ECMA 主機上的連接器名稱，例如 LDAP。 如果您是透過 ECMA 主機的憑證授權單位提供憑證，請將 localhost 取代為已安裝 ECMA 主機的伺服器主機名稱。

    屬性 值
    租用戶 URL https://localhost:8585/ecma2host_connectorName/scim

  3. 輸入您在建立連接器時定義的 [秘密權杖] 值。

    注意

    如果您只是將代理程式指派給應用程式，請等候 10 分鐘讓註冊完成。 在註冊完成之前，連線測試將無法運作。 在您的伺服器上重新啟動佈建代理程式來強制完成代理程式註冊，可以加速註冊程式。 移至您的伺服器、在 Windows 搜尋列中搜尋 [服務]、找出 [Microsoft Entra Connect 佈建代理程式服務]、以滑鼠右鍵按一下服務，然後重新啟動。

  4. 選取 [測試連線]，然後等待一分鐘。

  5. 連線測試成功，並顯示提供的認證已獲授權啟用佈建後，請選擇 [儲存]。
    顯示測試代理程式的螢幕擷取畫面。

擴展 Microsoft Entra 結構描述 (選用)

如果您的目錄伺服器需要不屬於使用者預設 Microsoft Entra 結構描述的其他屬性，則當您佈建時，您可以設定提供常數中這些屬性的值、從其他 Microsoft Entra 屬性轉換的運算式，或擴充 Microsoft Entra 結構描述。

如果目錄伺服器要求使用者具有屬性，例如 OpenLDAP POSIX 結構描述的 uidNumber，而且該屬性已經不屬於使用者的 Microsoft Entra 結構描述的一部分，而且每個使用者都必須是唯一 的，則您必須透過運算式從使用者的其他屬性產生該屬性，或使用 目錄擴充功能，將該屬性新增為延伸模組。

如果您的使用者源自 Active Directory 網域服務，且在該目錄中具有該屬性，則您可以使用 Microsoft Entra Connect 或 Microsoft Entra Connect 雲端同步，來設定屬性應該從 Active Directory Domain Services 同步至 Microsoft Entra ID，使其可供佈建至其他系統。

如果您的使用者源自Microsoft Entra ID，則您必須針對每個新屬性儲存在使用者上，您必須定義目錄擴充。 然後，更新計劃佈建的 Microsoft Entra 使用者，為每位使用者提供這些屬性的值。

設定屬性對應

在本節中，您將組態 Microsoft Entra 使用者屬性與先前在 ECMA 主機組態精靈中所選屬性之間的對應。 稍後當連接器在目錄伺服器中建立物件時，Microsoft Entra 使用者的屬性接著會透過連接器傳送至目錄伺服器，成為該新物件的一部分。

  1. 在 Microsoft Entra 系統管理中心的 [企業應用程式] 底下，選取 [內部部署 ECMA 應用程式] 應用程式，然後選取 [佈建] 頁面。

  2. 選取 [編輯佈建]。

  3. 擴展 [對應] 區段然後選取 [佈建 Microsoft Entra 使用者]。 如果這是您第一次設定此應用程式的屬性對應，則這對於預留位置來說，將只會有一個對應。

  4. 若要確認資料庫結構描述可在 Microsoft Entra ID 中使用，請選取 [顯示進階選項] 核取方塊，然後選取 [編輯 ScimOnPremises 的屬性列表]。 確定已列出組態精靈中選取的所有屬性。 如果沒有，請等候數分鐘讓結構描述重新整理，然後在導覽列中選取 [屬性對應]，然後再次選取 [編輯 ScimOnPremises 的屬性清單] 以重新載入頁面。 一旦您看到列出的屬性，請取消此頁面以返回對應清單。

  5. 目錄中的每個使用者都必須有唯一的辨別名稱。 您可以使用屬性對應來指定連接器應該如何建構辨別名稱。 選取 [新增對應]。 使用下列範例中的值來建立對應，將運算式中的辨別名稱變更為與目標目錄中的組織單位或其他容器相符的名稱。

    • 對應類型：運算式
    • 運算式，如果在 AD LDS 中佈建：Join("", "CN=", Word([userPrincipalName], 1, "@"), ",CN=CloudUsers,CN=App,DC=Contoso,DC=lab")
    • 運算式，如果在 OpenLDAP 中佈建：Join("", "CN=", Word([userPrincipalName], 1, "@"), ",DC=Contoso,DC=lab")
    • 目標屬性：urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:-dn-
    • 套用此對應：僅在物件建立期間

  6. 如果目錄伺服器需要多個結構化物件類別值或輔助物件類別值，才能在 objectClass 屬性中提供，則將對應新增至該屬性。 針對此佈建至 AD LDS 的範例，不需要對應 objectClass，但對於其他目錄伺服器或其他結構描述而言有可能是必要。 若要新增 objectClass 的對應，請選取 [新增對應]。 使用下列範例中的值來建立對應，將運算式中的物件類別名稱變更為符合目標目錄結構描述的名稱。

    • 對應類型：運算式
    • 運算式，如果佈建 inetOrgPerson 結構描述：Split("inetOrgPerson",",")
    • 運算式，如果佈建 POSIX 結構描述：Split("inetOrgPerson,posixAccount,shadowAccount",",")
    • 目標屬性：urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:objectClass
    • 套用此對應：僅在物件建立期間

  7. 如果您要佈建至 AD LDS，而且從 userPrincipalName 到 PLACEHOLDER具有對應，請按一下該對應並加以編輯。 使用下列值來更新對應。

    • 對應類型：直接
    • 來源屬性：userPrincipalName
    • 目標屬性：urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPrincipalName
    • 比對優先順序：1
    • 套用此對應：僅在物件建立期間

  8. 果您要佈建至 AD LDS，請新增 isSoftDeleted 的對應。 選取 [新增對應]。 使用下列值來建立對應。

    • 對應類型：直接
    • 來源屬性：isSoftDeleted
    • 目標屬性：urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:msDS-UserAccountDisabled

  9. 針對目錄伺服器下表中的每個對應，選取 [新增對應]，然後指定來源和目標屬性。 如果您要佈建至現有使用者的現有目錄，您必須編輯屬性的共通對應，以便設定該屬性的 [使用此屬性比對物件]。 在這裡深入了解屬性對應。

    針對 AD LDS：

    對應類型 來源屬性 目標屬性
    直接 displayName urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:displayName

    針對 OpenLDAP：

    對應類型 來源屬性 目標屬性
    直接 displayName urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:cn
    直接 surname urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:sn
    直接 userPrincipalName urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:mail

    針對具有 POSIX 結構描述的 OpenLDAP，您也需要提供 gidNumber、homeDirectory、uid 和 uidNumber 屬性。 每個使用者都需要唯一的 uid 和唯一的 uidNumber。 通常 homeDirectory 是由衍生自使用者 userID 的運算式所設定。 例如，如果使用者的 uid 是由衍生自其使用者主體名稱的運算式所產生，則該使用者主目錄的值可能會由類似的運算式產生，其使用者主體名稱也衍生自其使用者主體名稱。 視您的使用案例而定，您可能想要讓所有使用者都位於相同的群組中，因此會從常數指派 gidNumber。

    對應類型 來源屬性 目標屬性
    運算式 ToLower(Word([userPrincipalName], 1, "@"), ) urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:uid
    直接 (目錄特有的屬性) urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:uidNumber
    運算式 Join("/", "/home", ToLower(Word([userPrincipalName], 1, "@"), )) urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:homeDirectory
    持續性 10000 urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:gidNumber

  10. 如果佈建至 AD LDS 以外的目錄，請新增對應至設定使用者初始隨機密碼的 urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPassword。 針對 AD LDS，userPassword 沒有對應。

  11. 選取 [儲存]。

請確定使用者已佈建 Microsoft Entra ID 中具有必要屬性的應用程式

如果 LDAP 目錄中有現有的使用者帳戶，則必須確保 Microsoft Entra 使用者表示法具有比對所需的屬性。

如果您打算在 LDAP 目錄中建立新的使用者，則必須確定這些使用者 Microsoft Entra 表示法具有目標目錄的使用者結構描述所需的來源屬性。

您可以使用 Microsoft Graph PowerShell Cmdlet，為所需的屬性自動化檢查使用者。

例如，假設您的佈建需要使用者有三個屬性 DisplayName、surname 和 extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty。 您可以使用 Get-MgUser Cmdlet 來擷取每個使用者，並檢查所需的屬性是否存在。 請注意，Graph v1.0 Get-MgUser Cmdlet 預設不會傳回任何使用者的目錄擴充屬性，除非在要求中指定該屬性做為要傳回的屬性之一。

$userPrincipalNames = (
 "alice@contoso.com",
 "bob@contoso.com",
 "carol@contoso.com" )

$requiredBaseAttributes = ("DisplayName","surname")
$requiredExtensionAttributes = ("extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty")

$select = "id"
foreach ($a in $requiredExtensionAttributes) { $select += ","; $select += $a;}
foreach ($a in $requiredBaseAttributes) { $select += ","; $select += $a;}

foreach ($un in $userPrincipalNames) {
   $nu = Get-MgUser -UserId $un -Property $select -ErrorAction Stop
   foreach ($a in $requiredBaseAttributes) { if ($nu.$a -eq $null) { write-output "$un missing $a"} }
   foreach ($a in $requiredExtensionAttributes) { if ($nu.AdditionalProperties.ContainsKey($a) -eq $false) { write-output "$un missing $a" } }
}

從 LDAP 目錄收集現有的使用者

許多 LDAP 目錄 (例如 Active Directory) 都包含可輸出使用者清單的命令。

  1. 識別該目錄中哪些使用者屬於應用程式的使用者。 此選擇取決於應用程式的設定。 對於某些應用程式，任何存在於 LDAP 目錄中的使用者都是有效的使用者。 其他應用程式可能規定使用者必須有特定屬性，或必須是該目錄中群組的成員。

  2. 執行命令，從您的 LDAP 目錄中擷取該部分的使用者。 請確定輸出包含用來比對 Microsoft Entra ID 的使用者屬性。 這些屬性的例子包括員工識別碼、帳戶名稱和電子郵件地址。

    例如，此命令在 Windows 上使用 AD LDS csvde 程式會在現行檔案系統目錄中產生 CSV 檔案，其中包含 LDAP 目錄中每個人的 userPrincipalName 屬性：

    $out_filename = ".\users.csv"
csvde -f $out_filename -l userPrincipalName,cn -r "(objectclass=person)"

  3. 如有需要，請將包含使用者清單的 CSV 檔案，傳輸至已安裝 Microsoft Graph PowerShell Cmdlet 的系統。

  4. 既然您已從應用程式取得所有使用者的清單，接下來要比對應用程式資料存放區中的使用者與 Microsoft Entra ID 中的使用者。 繼續之前，請先檢閱比對來源和目標系統中的使用者的相關資訊。

擷取 Microsoft Entra ID 中的使用者識別碼

本節說明如何使用 Microsoft Graph PowerShell Cmdlet 與 Microsoft Entra ID 互動。

組織在此情況下第一次使用這些 Cmdlet 時，您必須是全域管理員角色，才能在租用戶中使用 Microsoft Graph PowerShell。 後續的互動可以使用特殊權限較低的角色，例如：

  • 使用者管理員 (如果您預期會建立新的使用者)。
  • 應用程式管理員或 Identity Governance 管理員 (如果您只是管理應用程式角色指派)。

  1. 開啟 PowerShell。

  2. 如果您尚未安裝 Microsoft Graph PowerShell 模組，請使用此命令來安裝 Microsoft.Graph.Users 模組和其他模組：

    Install-Module Microsoft.Graph

    如果已安裝這些模組，請確定是使用最新版本：

    Update-Module microsoft.graph.users,microsoft.graph.identity.governance,microsoft.graph.applications

  3. 連線至 Microsoft Entra ID：

    $msg = Connect-MgGraph -ContextScope Process -Scopes "User.ReadWrite.All,Application.ReadWrite.All,AppRoleAssignment.ReadWrite.All,EntitlementManagement.ReadWrite.All"

  4. 如果這是您第一次使用此命令，您可能需要同意允許 Microsoft Graph 命令行工具具有這些權限。

  5. 將從應用程式的資料存放區取得的使用者清單讀取到 PowerShell 工作階段中。 如果使用者清單位於 CSV 檔案中，您可以使用 PowerShell Cmdlet Import-Csv，並提供上一節中的檔案名稱作為引數。

    例如，如果從 SAP 雲端識別服務取得的檔案名為 Users-exported-from-sap.csv 且位於目前目錄中，請輸入此命令。

    $filename = ".\Users-exported-from-sap.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8

    針對其他範例，如果您正在使用資料庫或目錄，且如果檔案名為 users.csv，並位於現行目錄中，請輸入此命令：

    $filename = ".\users.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8

  6. 選擇 users.csv 檔案的資料行，用以比對 Microsoft Entra ID 中的使用者屬性。

    如果您使用 SAP 雲端識別服務，則預設對應是 SAP SCIM 屬性 userName，且具有 Microsoft Entra ID 屬性 userPrincipalName：

    $db_match_column_name = "userName"
$azuread_match_attr_name = "userPrincipalName"

    如需另一個範例，如果您使用資料庫或目錄，則資料庫中可能有使用者，其中名為 EMail 的資料行值與 Microsoft Entra 屬性中的值相同 userPrincipalName：

    $db_match_column_name = "EMail"
$azuread_match_attr_name = "userPrincipalName"

  7. 擷取 Microsoft Entra ID 中這些使用者的識別碼。

    下列 PowerShell 指令碼使用稍早指定的 $dbusers、$db_match_column_name 和 $azuread_match_attr_name 值。 將會查詢 Microsoft Entra ID 來找出使用者，而該使用者有一個屬性的值符合來源檔案中的每一筆記錄。 如果檔案中有許多使用者從來源 SAP 雲端識別服務、資料庫或目錄取得，此指令碼可能需要幾分鐘的時間才能完成。 如果您在 Microsoft Entra ID 中沒有屬性具有此值，而且需要使用 contains 或其他篩選條件運算式，則必須自訂此指令碼及下面步驟 11 中的指令碼來使用不同的篩選條件運算式。

    $dbu_not_queried_list = @()
$dbu_not_matched_list = @()
$dbu_match_ambiguous_list = @()
$dbu_query_failed_list = @()
$azuread_match_id_list = @()
$azuread_not_enabled_list = @()
$dbu_values = @()
$dbu_duplicate_list = @()

foreach ($dbu in $dbusers) { 
   if ($null -ne $dbu.$db_match_column_name -and $dbu.$db_match_column_name.Length -gt 0) { 
      $val = $dbu.$db_match_column_name
      $escval = $val -replace "'","''"
      if ($dbu_values -contains $escval) { $dbu_duplicate_list += $dbu; continue } else { $dbu_values += $escval }
      $filter = $azuread_match_attr_name + " eq '" + $escval + "'"
      try {
         $ul = @(Get-MgUser -Filter $filter -All -Property Id,accountEnabled -ErrorAction Stop)
         if ($ul.length -eq 0) { $dbu_not_matched_list += $dbu; } elseif ($ul.length -gt 1) {$dbu_match_ambiguous_list += $dbu } else {
            $id = $ul[0].id; 
            $azuread_match_id_list += $id;
            if ($ul[0].accountEnabled -eq $false) {$azuread_not_enabled_list += $id }
         } 
      } catch { $dbu_query_failed_list += $dbu } 
    } else { $dbu_not_queried_list += $dbu }
}

  8. 檢視先前查詢的結果。 檢視 SAP 雲端識別服務、資料庫或目錄中是否有任何使用者因為錯誤或遺漏相符項目而無法位於 Microsoft Entra ID 中。

    下列 PowerShell 指令碼顯示找不到的記錄計數：

    $dbu_not_queried_count = $dbu_not_queried_list.Count
if ($dbu_not_queried_count -ne 0) {
  Write-Error "Unable to query for $dbu_not_queried_count records as rows lacked values for $db_match_column_name."
}
$dbu_duplicate_count = $dbu_duplicate_list.Count
if ($dbu_duplicate_count -ne 0) {
  Write-Error "Unable to locate Microsoft Entra ID users for $dbu_duplicate_count rows as multiple rows have the same value"
}
$dbu_not_matched_count = $dbu_not_matched_list.Count
if ($dbu_not_matched_count -ne 0) {
  Write-Error "Unable to locate $dbu_not_matched_count records in Microsoft Entra ID by querying for $db_match_column_name values in $azuread_match_attr_name."
}
$dbu_match_ambiguous_count = $dbu_match_ambiguous_list.Count
if ($dbu_match_ambiguous_count -ne 0) {
  Write-Error "Unable to locate $dbu_match_ambiguous_count records in Microsoft Entra ID as attribute match ambiguous."
}
$dbu_query_failed_count = $dbu_query_failed_list.Count
if ($dbu_query_failed_count -ne 0) {
  Write-Error "Unable to locate $dbu_query_failed_count records in Microsoft Entra ID as queries returned errors."
}
$azuread_not_enabled_count = $azuread_not_enabled_list.Count
if ($azuread_not_enabled_count -ne 0) {
 Write-Error "$azuread_not_enabled_count users in Microsoft Entra ID are blocked from sign-in."
}
if ($dbu_not_queried_count -ne 0 -or $dbu_duplicate_count -ne 0 -or $dbu_not_matched_count -ne 0 -or $dbu_match_ambiguous_count -ne 0 -or $dbu_query_failed_count -ne 0 -or $azuread_not_enabled_count) {
 Write-Output "You will need to resolve those issues before access of all existing users can be reviewed."
}
$azuread_match_count = $azuread_match_id_list.Count
Write-Output "Users corresponding to $azuread_match_count records were located in Microsoft Entra ID."

  9. 指令碼完成時，如果資料來源中有任何記錄不在 Microsoft Entra ID 中，則會指出錯誤。 如果應用程式資料存放區中的使用者記錄並非全部在 Microsoft Entra ID 中也有使用者，則您必須調查哪些記錄不相符及原因。

    例如，Microsoft Entra ID 中可能變更某人的電子郵件地址和 userPrincipalName，但在應用程式的資料來源中未更新其對應的 mail 屬性。 或者，使用者可能已離開組織，但仍留在應用程式的資料來源中。 或者，應用程式的資料來源中可能有廠商或超級管理員帳戶未對應至 Microsoft Entra ID 中的任何特定人員。

  10. 如果無法再 Microsoft Entra ID 中找到使用者，或沒有作用中且無法登入，但您想要在 SAP 雲端識別服務、資料庫或目錄中更新其屬性，您必須更新應用程式、比對規則，或更新或為其建立 Microsoft Entra 使用者。 如需要進行哪些變更的詳細資訊，請參閱管理與 Microsoft Entra ID 中不符合之使用者的對應和使用者帳戶。

    如果您選擇在 Microsoft Entra ID 中建立使用者的選項，您可以使用下列其中一項來大量建立使用者：

    請務必為這些新使用者填入必要的屬性，以供 Microsoft Entra ID 稍後比對應用程式中的現有使用者，以及 Microsoft Entra ID 要求的屬性，包括 userPrincipalName、mailNickname 和 displayName。 userPrincipalName 在目錄中的所有使用者中必須是唯一的。

    例如，您可能有資料庫中的使用者，其中名為 EMail 的資料行中出現的值是您想要作為 Microsoft Entra 使用者主體名稱的值、資料行中的值 Alias 包含 Microsoft Entra ID 郵件暱稱，且資料行中的值 Full name 包含使用者的顯示名稱：

    $db_display_name_column_name = "Full name"
$db_user_principal_name_column_name = "Email"
$db_mail_nickname_column_name = "Alias"

    然後，您可以使用此指令碼，為 SAP 雲端識別服務、資料庫或目錄中，與 Microsoft Entra ID 中使用者不相符的項目建立 Microsoft Entra 使用者。 請注意，您可能需要修改此指令碼，以新增組織所需的其他 Microsoft Entra 屬性，或如果 $azuread_match_attr_name 既不是 mailNickname 也不是 userPrincipalName，才能提供該 Microsoft Entra 屬性。

    $dbu_missing_columns_list = @()
$dbu_creation_failed_list = @()
foreach ($dbu in $dbu_not_matched_list) {
   if (($null -ne $dbu.$db_display_name_column_name -and $dbu.$db_display_name_column_name.Length -gt 0) -and
       ($null -ne $dbu.$db_user_principal_name_column_name -and $dbu.$db_user_principal_name_column_name.Length -gt 0) -and
       ($null -ne $dbu.$db_mail_nickname_column_name -and $dbu.$db_mail_nickname_column_name.Length -gt 0)) {
      $params = @{
         accountEnabled = $false
         displayName = $dbu.$db_display_name_column_name
         mailNickname = $dbu.$db_mail_nickname_column_name
         userPrincipalName = $dbu.$db_user_principal_name_column_name
         passwordProfile = @{
           Password = -join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_})
         }
      }
      try {
        New-MgUser -BodyParameter $params
      } catch { $dbu_creation_failed_list += $dbu; throw }
   } else {
      $dbu_missing_columns_list += $dbu
   }
}

  11. 將任何遺漏的使用者新增至 Microsoft Entra ID 之後，請再次執行步驟 7 的指令碼。 然後執行步驟 8 的指令碼。 確認未回報任何錯誤。

    $dbu_not_queried_list = @()
$dbu_not_matched_list = @()
$dbu_match_ambiguous_list = @()
$dbu_query_failed_list = @()
$azuread_match_id_list = @()
$azuread_not_enabled_list = @()
$dbu_values = @()
$dbu_duplicate_list = @()

foreach ($dbu in $dbusers) { 
   if ($null -ne $dbu.$db_match_column_name -and $dbu.$db_match_column_name.Length -gt 0) { 
      $val = $dbu.$db_match_column_name
      $escval = $val -replace "'","''"
      if ($dbu_values -contains $escval) { $dbu_duplicate_list += $dbu; continue } else { $dbu_values += $escval }
      $filter = $azuread_match_attr_name + " eq '" + $escval + "'"
      try {
         $ul = @(Get-MgUser -Filter $filter -All -Property Id,accountEnabled -ErrorAction Stop)
         if ($ul.length -eq 0) { $dbu_not_matched_list += $dbu; } elseif ($ul.length -gt 1) {$dbu_match_ambiguous_list += $dbu } else {
            $id = $ul[0].id; 
            $azuread_match_id_list += $id;
            if ($ul[0].accountEnabled -eq $false) {$azuread_not_enabled_list += $id }
         } 
      } catch { $dbu_query_failed_list += $dbu } 
    } else { $dbu_not_queried_list += $dbu }
}

$dbu_not_queried_count = $dbu_not_queried_list.Count
if ($dbu_not_queried_count -ne 0) {
  Write-Error "Unable to query for $dbu_not_queried_count records as rows lacked values for $db_match_column_name."
}
$dbu_duplicate_count = $dbu_duplicate_list.Count
if ($dbu_duplicate_count -ne 0) {
  Write-Error "Unable to locate Microsoft Entra ID users for $dbu_duplicate_count rows as multiple rows have the same value"
}
$dbu_not_matched_count = $dbu_not_matched_list.Count
if ($dbu_not_matched_count -ne 0) {
  Write-Error "Unable to locate $dbu_not_matched_count records in Microsoft Entra ID by querying for $db_match_column_name values in $azuread_match_attr_name."
}
$dbu_match_ambiguous_count = $dbu_match_ambiguous_list.Count
if ($dbu_match_ambiguous_count -ne 0) {
  Write-Error "Unable to locate $dbu_match_ambiguous_count records in Microsoft Entra ID as attribute match ambiguous."
}
$dbu_query_failed_count = $dbu_query_failed_list.Count
if ($dbu_query_failed_count -ne 0) {
  Write-Error "Unable to locate $dbu_query_failed_count records in Microsoft Entra ID as queries returned errors."
}
$azuread_not_enabled_count = $azuread_not_enabled_list.Count
if ($azuread_not_enabled_count -ne 0) {
 Write-Warning "$azuread_not_enabled_count users in Microsoft Entra ID are blocked from sign-in."
}
if ($dbu_not_queried_count -ne 0 -or $dbu_duplicate_count -ne 0 -or $dbu_not_matched_count -ne 0 -or $dbu_match_ambiguous_count -ne 0 -or $dbu_query_failed_count -ne 0 -or $azuread_not_enabled_count -ne 0) {
 Write-Output "You will need to resolve those issues before access of all existing users can be reviewed."
}
$azuread_match_count = $azuread_match_id_list.Count
Write-Output "Users corresponding to $azuread_match_count records were located in Microsoft Entra ID."

10. 將使用者指派給應用程式

現在您已有 Microsoft Entra ECMA Connector 主機與 Microsoft Entra ID 進行通訊，屬性對應也已設定完成，接下來您可以設定要佈建的範圍。

重要

如果您已使用混合式身分識別管理員角色登入，則必須先登出，然後使用至少具有應用程式系統管理員角色帳戶登入，才能使用此區段。 混合式身分識別管理員角色沒有將使用者指派給應用程式的權限。

如果 LDAP 目錄中有現有使用者，則您應為這些 Microsoft Entra ID 中的現有使用者建立應用程式角色指派。 若要深入了解如何使用 New-MgServicePrincipalAppRoleAssignedTo 大量建立應用程式角色指派，請參閱在 Microsoft Entra ID 中管理應用程式現有使用者。

否則，如果 LDAP 目錄是空的，請從具有必要屬性且將佈建至應用程式目錄伺服器的 Microsoft Entra ID 中選取測試使用者。

  1. 請確定使用者將選取的全部屬性將對應至目錄伺服器結構描述的必要屬性。
  2. 在 Azure 入口網站中，選取 [企業應用程式]。
  3. 選取 [內部部署 ECMA 應用程式] 應用程式。
  4. 在左側選取 [管理] 之下的 [使用者和群組]。
  5. 選取 [新增使用者/群組]。 顯示新增使用者的螢幕擷取畫面。
  6. 在 [使用者] 底下，選取 [未選取]。 顯示 [未選取] 的螢幕擷取畫面。
  7. 從右側選取使用者，然後選取 [選取] 按鈕。
    顯示 [選取使用者] 的螢幕擷取畫面。
  8. 現在請選取 [指派]。 顯示 [指派使用者] 的螢幕擷取畫面。

測試佈建

現在您已對應您的屬性，初始使用者也指派完成，可以使用其中一個使用者來測試隨需佈建。

  1. 在執行 Microsoft Entra ECMA Connector 主機的伺服器上，選取 [啟動]。

  2. 輸入 [執行]，然後在方塊中輸入 services.msc。

  3. 在 [服務] 清單中，確定 Microsoft Entra Connect 佈建代理程式服務和 Microsoft ECMA2Host 服務都在執行中。 如果沒有，請選取 [啟動]。

  4. 在 Azure 入口網站中，選取 [企業應用程式]。

  5. 選取 [內部部署 ECMA 應用程式] 應用程式。

  6. 選取左側的 [佈建]。

  7. 選取 [隨需佈建]。

  8. 搜尋您的其中一個測試使用者，然後選取 [佈建]。 顯示測試隨選佈建的螢幕擷取畫面。

  9. 幾秒鐘之後，「已成功在目標系統中建立使用者」的訊息即會出現，包含使用者屬性清單。 如果出現錯誤，請參閱針對佈建錯誤進行疑難排解。

開始佈建使用者

測試隨選佈建成功之後，新增其餘的使用者。

  1. 在 Azure 入口網站中，選取應用程式。
  2. 在左側選取 [管理] 之下的 [使用者和群組]。
  3. 確定所有使用者都已指派給應用程式角色。
  4. 變更回佈建組態頁面。
  5. 確定範圍設定為 [僅限指派的使用者和群組]，而且佈建狀態設定為 [開啟]，然後選取 [儲存]。
  6. 等候數分鐘以開始佈建。 最多可能需要 40 分鐘的時間。 佈建作業完成之後，如下一節所述，

針對佈建錯誤進行疑難排解

如果顯示錯誤，請選取 [檢視佈建記錄]。 查看記錄檔中是否有狀態為「失敗」的資料列，然後按一下該資料列。

如果錯誤訊息為 [無法建立使用者]，請檢查與目錄結構描述的需求顯示不符的屬性。

如需詳細資訊，請變更為 [疑難排解與建議] 索引標籤。

如果疑難解答錯誤訊息包含的 objectClass 值為 invalid per syntax，請確定佈建屬性對應至 objectClass 屬性只包含目錄伺服器所識別的物件類別名稱。

如需其他錯誤，請參閱針對內部部署應用程式佈建進行疑難排解。

如果您想要暫停佈建至此應用程式，請在 [佈建組態] 頁面上，將佈建狀態變更為 [關閉]，然後選取 [儲存]。 此動作會使佈建服務在未來停止執行。

檢查使用者是否已成功佈建

等候之後，請檢查目錄伺服器，以確保會佈建使用者。 您對目錄伺服器的查詢將取決於您目錄伺服器所提供的命令。

下列指示說明如何檢查 AD LDS。

  1. 開啟伺服器管理員，然後選取左邊的 AD LDS。
  2. 以滑鼠右鍵按一下您的 AD LDS 執行個體，然後從快顯視窗中選取 [ldp.exe]。 Ldp 工具位置的螢幕擷取畫面。
  3. 在 ldp.exe 的頂端，依序選取 [連線] 和 [連線]。
  4. 輸入下列資訊，然後按一下 [確定]。
    • 伺服器：APP3
    • 連接埠：636
    • 核取 SSL 方塊 顯示檢查使用者之 Ldp 連線的螢幕擷取畫面。
  5. 在頂端的 [連線] 底下，選取 [繫結]。
  6. 保留預設值，然後按一下 [確定]。
  7. 在頂端，選取 [檢視] 和 [樹狀]
  8. 針對 BaseDN，輸入 CN=App,DC=contoso,DC=lab，然後按一下 [確定]。
  9. 展開左側的 DN，然後按一下 [CN=CloudUsers,CN=App,DC=contoso,DC=lab]。 您應該會看到已從 Microsoft Entra ID 佈建的使用者。 顯示使用者 Ldp 繫結的螢幕擷取畫面。

下列指示說明如何檢查 OpenLDAP。

  1. 使用 OpenLDAP 開啟系統上具有命令殼層的終端機視窗。
  2. 輸入命令 ldapsearch -D "cn=admin,dc=contoso,dc=lab" -W -s sub -b dc=contoso,dc=lab -LLL (objectclass=inetOrgPerson)
  3. 檢查產生的 LDIF 是否包含從 Microsoft Entra ID 佈建的使用者。

下一步