配置 Microsoft Entra ID，將使用者帳號布建到 LDAP 目錄，以便進行 Linux 驗證。

發行項
12/14/2024

下列檔是示範如何控管 Linux 系統的存取權的教學課程。 Microsoft Entra 會將使用者配置到由該 Linux 系統信任的內部部署 LDAP 目錄中。這可讓使用者登入依賴該 LDAP 目錄進行用戶驗證的 Linux 系統。當使用者從 Microsoft Entra ID 中移除時，就無法再登入 Linux 系統。

註釋

本文所述的案例僅適用於已經依賴名稱服務交換器（NSS）或插入式驗證模組（PAM） LDAP 模組的現有 Linux 系統，以進行使用者識別和驗證。 Azure 或已啟用 Azure Arc 的 Linux 虛擬機器應該改為整合 Microsoft Entra 驗證。您現在可以將 Microsoft Entra ID 作為核心驗證平臺和憑證頒發機構，並使用 Microsoft Entra ID 和 OpenSSH 憑證型驗證來 SSH 連接到 Linux 虛擬機器，如中所述，使用 Microsoft Entra ID 和 OpenSSH。

如需將使用者布建至 LDAP 目錄的其他案例，除了 Linux 驗證之外，請參閱設定 Microsoft Entra ID 將使用者布建到 LDAP 目錄。

將使用者配置至LDAP目錄，用於Linux驗證的必要條件

本文假設LDAP伺服器已存在於內部部署環境中，供一或多個Linux或其他POSIX系統用來進行用戶驗證。

圖表，顯示從 Microsoft Entra ID 到 LDAP 目錄伺服器的內部部署佈建架構。

內部部署必要條件

使用 PAM 或 NSS 模組在目錄伺服器上回復的 Linux 或其他 POSIX 伺服器。
支援 POSIX 架構的 LDAP 目錄伺服器，例如 OpenLDAP，可在其中建立、更新和刪除使用者。如需支援之目錄伺服器的詳細資訊，請參閱一般 LDAP 連接器參考。
至少有 3 GB RAM 的電腦，用來裝載布建代理程式。計算機應該有 Windows Server 2016 或更新版本的 Windows Server。它也應該具備連接到目標目錄伺服器的能力，並對 login.microsoftonline.com、其他 Microsoft 線上服務和 Azure 網域有對外連線能力。例如裝載於 Azure IaaS 或 Proxy 後方的 Windows Server 2016 虛擬機。 .NET Framework 4.7.2 必須安裝在該伺服器上。
選用：雖然不需要，但建議下載 Microsoft Edge for Windows Server 並使用它取代 Internet Explorer。

雲端需求

具有 Microsoft Entra ID P1 或 Premium P2 （或 EMS E3 或 E5）的 Microsoft Entra 承租者。

使用此功能需要Microsoft Entra ID P1 授權。若要尋找您需求的正確授權，請參閱比較 Microsoft Entra ID的一般可用功能。
用於設定布建代理程式的混合式身分識別管理員角色。
在 Azure 入口網站或Microsoft Entra 系統管理中心中設定布建的應用程式管理員或雲端應用程式管理員角色。
目錄伺服器架構需要每個Microsoft Entra 使用者的特定屬性才能布建到LDAP目錄，而且必須已填入這些屬性。特別是，每位用戶都必須有唯一號碼作為其使用者標識碼。在部署布建代理程式並將使用者指派給目錄之前，您必須從使用者的現有屬性產生該數位，或擴充 Microsoft Entra 架構。然後，您可以為設定範圍的使用者填入該屬性。如需如何建立其他目錄延伸模組，請參閱 Graph 擴充性。

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

將連接器部署至現有的目錄伺服器之前，您必須與組織中的目錄伺服器操作員討論如何與其目錄伺服器整合。要收集的資訊包括：

有關如何連線至目錄伺服器的網路資訊。
連接器應該如何向目錄伺服器驗證自己。
目錄伺服器已選取哪些架構來建立使用者模型。
命名內容的基底辨別名稱和目錄階層規則。
如何將目錄伺服器中的使用者與 entra ID Microsoft 中的用戶產生關聯。
當使用者超出 Microsoft Entra ID 的範圍時，會發生什麼事。

部署此連接器可能需要更改目錄伺服器的設定，以及 Microsoft Entra ID 的設定。對於在生產環境中整合Microsoft Entra ID 與第三方目錄伺服器的部署，我們建議客戶與其目錄伺服器廠商合作，或部署夥伴以取得協助、指引和支援此整合。本文使用下列 OpenLDAP 範例值。

組態設定	設定值的位置	範例值
目錄伺服器的主機名	設定精靈連線能力頁面	`APP3`
目錄伺服器的埠號碼	設定精靈連線頁面	636.針對透過SSL或 TLS 的LDAP（LDAPS），請使用埠 636。針對 `Start TLS`，請使用埠 389。
用來讓連接器在目錄伺服器中進行自我識別的帳戶	設定精靈連線能力頁面	`cn=admin,dc=contoso,dc=lab`
連接器向目錄伺服器驗證本身的密碼	設定精靈連線能力頁面
目錄伺服器中用戶的結構物件類別	組態精靈物件類型頁面	`inetOrgPerson`
目錄伺服器中用戶的輔助物件類別	Azure 入口網站佈建頁面屬性對應	`posixAccount` 和`shadowAccount`
在新使用者上填入的屬性	設定精靈的「選取屬性」頁面以及 Azure 入口網站的「布建」頁面的屬性對應	`cn`、`gidNumber`、`homeDirectory`、`mail`、`objectClass`、`sn`、`uid`、`uidNumber`、`userPassword`
目錄伺服器所需的命名階層	Azure 入口網站設定頁面屬性對應	將新建立使用者的 DN 設定為緊接在 `DC=Contoso,DC=lab` 之下
屬性，可讓使用者跨Microsoft Entra ID 和目錄伺服器相互關聯	Azure 入口網站佈署頁面屬性對應	`mail`
當使用者在 Microsoft Entra 識別碼中超出範圍時的解除配置行為	設定精靈取消布建頁面	從目錄伺服器刪除使用者

目錄伺服器的網路位址是主機名和 TCP 連接埠號碼，通常是埠 389 或 636。除了目錄伺服器與相同 Windows Server 上的連接器共置，或是您使用的是網路層級安全性，否則從連接器到目錄伺服器的網路連線必須使用 SSL 或 TLS 來保護。連接器支援透過埠 389 連接到目錄伺服器，並使用 Start TLS 在會話中啟用 TLS。連接器也支援在埠 636 上連線到 LDAPS - LDAP over TLS 的目錄伺服器。

您必須擁有已識別的帳戶，以便讓連接器能夠在已設定的目錄伺服器上進行驗證。此帳戶通常會以辨別名稱來識別，且具有相關聯的密碼或客戶端憑證。若要對連線目錄中的物件執行匯入和匯出作業，連接器帳戶必須在目錄的訪問控制模型中具有足夠的許可權。連接器必須具有寫入許可權才能匯出，並讀取許可權才能匯入。許可權設定是在目標目錄本身的管理體驗內執行。

目錄架構會指定物件類別和屬性，這些物件類別和屬性代表目錄中的實際實體。連接器支援以結構物件類別來表示的使用者，例如 inetOrgPerson，並且可以選擇性地加上額外的輔助物件類別。若要讓連接器能夠將使用者布建到目錄伺服器，在 Azure 入口網站設定期間，您必須定義 Microsoft Entra 架構中所有必要屬性的對應關係。這包括結構物件類別的強制屬性、該結構物件類別的任何超級類別，以及任何輔助物件類別的強制屬性。

您可能也會設定對應至這些類別的一些可選屬性。具有 POSIX 架構以支援 Linux 驗證的 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目錄中建立新使用者，而不只是更新或刪除現有的使用者，則您也必須決定使用該目錄伺服器處理驗證的Linux系統。有些系統可以從目錄中查詢使用者的 SSH 公鑰或憑證，這對於已經擁有這些憑證的使用者來說可能是合適的。不過，如果您的應用程式依賴目錄伺服器不支援新式驗證通訊協定或更強的認證，則您必須在目錄中建立新用戶時設定應用程式特定密碼，因為 Microsoft Entra ID 不支援布建使用者的 Microsoft Entra 密碼。

最後，您需要討論並達成共識關於去配置行為。當連接器配置完成，且 Microsoft Entra ID 已將 Microsoft Entra ID 中的使用者連結至目錄中的使用者時，無論是針對已存在的目錄使用者或新使用者，Microsoft Entra ID 都可以將屬性變更從 Microsoft Entra 使用者布建到目錄中。

如果已分配給應用程式的這個使用者在 Microsoft Entra ID 中被刪除，那麼 Microsoft Entra ID 會從目錄伺服器執行刪除操作。當使用者超出能夠使用應用程式的範圍時，您可能也想要Microsoft Entra ID 更新目錄伺服器中的物件。此行為取決於將使用目錄伺服器的應用程式，因為許多目錄，例如 OpenLDAP，可能沒有預設的方式來指出使用者帳戶已停用。

安裝和設定 Microsoft Entra Connect 布建代理程式

登入 Azure 入口網站。
移至 [企業應用程式]，然後選取 [[新增應用程式]。
搜尋 內部部署 ECMA 應用程式 應用程式、提供應用程式名稱，然後選取 [建立]，將它新增至租使用者。
從功能表中，導航至應用程式的 [配置] 頁面。
選擇 [開始使用]。
在 [布建] 頁面上，將模式變更為自動。

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

離開入口後執行佈建代理程式，接著同意服務條款，然後選取 [安裝]。
等候 Microsoft Entra 布建代理程式設定精靈，然後選取 [下一步]。
在 [選取擴充功能] 步驟中，選取 [內部部署應用程式布建]，然後選取 [下一步]。
佈建代理程式會用操作系統的網頁瀏覽器來顯示彈出視窗，讓您可以驗證 Microsoft Entra ID，並且可能還會要求您驗證您的組織識別提供者。如果您使用 Internet Explorer 做為 Windows Server 上的瀏覽器，您可能需要將Microsoft網站新增至瀏覽器的信任網站清單，以允許 JavaScript 正確執行。
當系統提示您授權時，請提供Microsoft Entra 系統管理員的認證。用戶必須至少有混合式識別管理員角色。
選取 [確認以確認設定。安裝成功之後，您可以選取 [Exit]，並關閉 [布建代理程式套件] 安裝程式。

設定內部部署ECMA應用程式

回到入口網站的 [內部部署連線] 區段上，選取您部署的代理程式，然後選取 [指派代理程式]。
當您使用設定精靈完成下一個步驟的設定時，請保持此瀏覽器窗口開啟。

設定 Microsoft Entra ECMA 連接器主機憑證

在安裝布建代理程式的 Windows Server 上，從 [開始] 功能表中，以滑鼠右鍵單擊 [Microsoft ECMA2Host 設定精靈]，然後以系統管理員身分執行。精靈必須以 Windows 系統管理員身分執行，才能建立必要的 Windows 事件記錄檔。
ECMA 連接器主機組態啟動之後，如果這是您第一次執行精靈，它會要求您建立憑證。保留預設埠 8585，然後選取 [產生憑證 來產生憑證。自動產生的憑證會自我簽署為受信任根目錄的一部分。 SAN 符合主機名稱。
選取 [儲存]。

注意

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

設定一般LDAP連接器

視您選取的選項而定，某些精靈畫面可能無法使用，而且資訊可能稍有不同。使用下列資訊來指引您進行設定。

產生一個將用來驗證 Microsoft Entra ID 與連接器之間身份驗證的秘密令牌。每個應用程式至少應為 12 個字元且是唯一的。如果您還沒有秘密產生器，您可以使用 PowerShell 命令，例如下列命令來產生範例隨機字串。
```
-join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_})
```
如果您尚未這麼做，請從 [開始] 功能表啟動 [Microsoft ECMA2Host 設定精靈]。
選擇[[新增連線器]。

在 [屬性] 頁面上，按照影像後面的表格中指定的值填入方塊，然後選取 [下一步]。

財產	價值
名字	您為連接器選擇的名稱必須在環境中的所有連接器中唯一。例如，`LDAP`。
自動同步定時器（分鐘）	120
秘密令牌	在這裡輸入您的秘密令牌。至少應為 12 個字元。
擴展 DLL	針對通用的LDAP連接器，選取 [Microsoft.IAM.Connector.GenericLdap.dll]。

在 [連線能力] 頁面上，您將設定 ECMA 連接器主機如何與目錄伺服器通訊，並設置一些組態選項。在方框中填入在圖片後方表格中指定的值，然後選擇 [下一步]。當您選取 [下一步]時，連接器會查詢目錄伺服器以取得其設定資訊。

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

注意

如果您在嘗試連線時遇到問題，且無法進入 [Global] 頁面，請確定目錄伺服器中的服務帳戶已啟用。

在 [Global] 頁面上，您可以根據需要設定異動記錄的識別名稱，以及其他 LDAP 功能。頁面會預先填入LDAP伺服器提供的資訊。查看顯示的值，然後選擇 下一步。

財產	描述
支援的SASL機制	頂端區段會顯示伺服器本身提供的資訊，包括SASL機制清單。
伺服器證書詳細數據	如果指定了 `SSL` 或 `TLS`，精靈會顯示目錄伺服器所傳回的憑證。確認簽發者、主體和指紋適用於正確的目錄伺服器。
必備功能已找到	連接器也會驗證根 DSE 中是否存在強制控制件。如果未列出這些控制件，則會顯示警告。有些LDAP目錄不會列出根 DSE 中的所有功能，即使有警告，連接器仍可能運作，而不會發生問題。
支援的控制件	支援的控件複選框可控制特定作業的行為
Delta 匯入	變更記錄 DN 是增量變更日誌所使用的命名上下文，例如 cn=changelog。必須指定這個值，才能執行差異匯入。如果您不需要實作差異匯入，則此字段可以是空白的。
密碼屬性	如果目錄伺服器支援不同的密碼屬性或密碼哈希，您可以指定密碼變更的目的地。
分區名稱	在其他分割區清單中，可以新增未自動偵測到的其他命名空間。例如，如果數部伺服器組成邏輯叢集，應該同時匯入，則可以使用此設定。就像 Active Directory 在一個樹系中可以有多個網域，但所有網域共用一個架構，同樣可以藉由在此方塊中輸入其他命名空間來模擬。每個命名空間都可以從不同的伺服器匯入，並在設定分割區和階層頁面上進一步設定。

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

在 [執行配置檔] 頁面上，確定已選取 [匯出] 複選框和 [完整匯入] 複選框。然後選擇[下一步] 。

財產	描述
出口	執行設定檔，將數據匯出至LDAP目錄伺服器。此運行配置檔是必要的。
完整匯入	執行配置檔，從先前指定的LDAP來源匯入所有數據。此執行配置檔是必要的。
增量匯入	執行設定檔，其只匯入自上次完整或差異匯入以來的LDAP變更。只有在您確認目錄伺服器符合必要需求時，才啟用此執行配置檔。如需詳細資訊，請參閱一般 LDAP 連接器參考。

在 [匯出] 頁面上，保留預設值不變，然後選擇 [下一步]。
在 [完整匯入] 頁面上，保留預設值，然後選取 [下一步]。
在 [DeltaImport] 頁面上，如果存在，請將預設值維持不變，然後選取 [下一步]。

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

財產	描述
目標物件	此值是LDAP目錄伺服器中用戶的結構物件類別。使用 `inetOrgPerson`，而且在此欄位中未指定輔助物件類別。如果目錄伺服器需要輔助物件類別，則會使用 Azure 入口網站中的屬性對應來設定它們。
錨	此屬性的值對於目標目錄中的每個物件而言都應該是唯一的。 Microsoft Entra 布建服務會在初始循環之後使用此屬性來查詢 ECMA 連接器主機。通常使用具名識別符，可能會選擇為 `-dn-`。多重值屬性，例如 OpenLDAP 架構中的 `uid` 屬性，不能當做錨點使用。
查詢屬性	此屬性應該與 Anchor 相同。
DN	目標物件的 distinguishedName。保留 `-dn-`。
自動產生	未受控

ECMA 主機會探索目標目錄所支援的屬性。您可以選擇要公開給Microsoft Entra 識別碼的其中一個屬性。然後，您可以在 Azure 入口網站中設定這些屬性以進行布建。在 [選取屬性] 頁面上，將下拉式清單中的所有屬性逐一新增，作為必要屬性或是您希望從 Microsoft Entra ID 布建的屬性。
[屬性] 下拉式清單會顯示在目標目錄中探索到的任何屬性，在先前使用組態精靈 [選取屬性] 頁面上未 選擇。

請確保 Treat as single value 複選框在 objectClass 屬性中處於未選取狀態，如果正在設定 userPassword，則在 userPassword 屬性中應為無法選取或已核取。

設定下列屬性的可見性。

屬性	將視為單一值
_distinguishedName
-dn-
匯出密碼
中國	Y
gidNumber
主目錄
郵件	Y
objectClass
錫	Y
使用者識別碼	Y
uidNumber
使用者密碼	Y

新增所有相關屬性之後，請選擇 [下一步]。

在 [取消布建] 頁面上，您可以指定您是否希望讓 Microsoft Entra ID 在使用者離開應用程式範圍時將他們從目錄中移除。如果是，請在 [停用流程] 底下，選取 [刪除]，然後在 [刪除流程] 下，選取 [刪除]。如果已選擇 Set attribute value，則在取消布建頁面上將無法選擇在上一個頁面中所選的屬性。

注意

如果您使用 Set 屬性值 請注意只允許布爾值。

請選擇完成。

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

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

在執行 Microsoft Entra ECMA 連接器主機的伺服器上，選取開始。
視需要選取 [執行]，然後在方塊中輸入 services.msc。
在 [Services] 清單中，確定 Microsoft ECMA2Host 存在且正在執行中。如果尚未執行，請選擇「開始」。
如果您最近啟動服務，並在目錄伺服器中有許多用戶物件，請等候幾分鐘，讓連接器與目錄伺服器建立連線。
在執行 Microsoft Entra ECMA 連接器主機的伺服器上，啟動 PowerShell。
變更為已安裝 ECMA 主機的資料夾，例如 C:\Program Files\Microsoft ECMA2Host。
變更為子目錄 Troubleshooting。
如所示，在該目錄中執行腳本 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: ************
```
如果文稿顯示錯誤或警告訊息，請檢查服務是否正在執行，且連接器名稱和秘密令牌符合您在組態精靈中設定的值。
如果腳本顯示輸出 False，則表示連接器尚未在來源目錄伺服器中看到現有使用者的任何條目。如果這是新的目錄伺服器安裝，則此行為是預期的，您可以在下一節繼續進行。
不過，如果目錄伺服器已經包含一或多個使用者，但腳本會顯示 False，則此狀態表示連接器無法從目錄伺服器讀取。如果您嘗試配置，則 Microsoft Entra ID 可能無法正確比對該來源目錄中的使用者與 Microsoft Entra ID 中的使用者。等候數分鐘，連接器主機完成從現有目錄伺服器讀取對象，然後重新執行腳本。如果輸出繼續為 False，請檢查您的連接器的配置，並確認目錄伺服器中的許可權設定是否允許連接器讀取現有使用者。

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

返回您在門戶網站中設定應用程式的網頁瀏覽器視窗。

注意

如果視窗逾時，您需要重新選取代理。
1. 登入 Azure 入口網站。
2. 移至 企業應用程式 和 本地部署 ECMA 應用程式。
3. 在布建上選取。
4. 如果 出現 [開始使用]，請將模式切換為自動，在 內部部署連線 區段，選取您剛才部署的代理程式，接著選取 指派代理程式，然後等候 10 分鐘。否則，請移至 [編輯配置]。
在 [系統管理員認證] 區段底下，輸入下列 URL。將 connectorName 部分取代為 ECMA 主機上的連接器名稱，例如 LDAP。如果您提供了來自憑證頒發機構的 ECMA 主機憑證，請將 localhost 替換為安裝 ECMA 主機的伺服器上的主機名稱。

財產價值

租戶 URL https://localhost:8585/ecma2host_connectorName/scim
輸入您在建立連接器時所定義的 秘密令牌 值。

備註

如果您剛將代理程式指派給應用程式，請等候 10 分鐘以完成註冊。在註冊完成之前，連線測試將無法運作。透過重新啟動伺服器上的布建代理程式，強制完成代理註冊，可以加速註冊程序。前往您的伺服器，在 Windows 搜尋列中搜尋服務，識別 Microsoft Entra Connect 布建代理程式 服務，右鍵單擊該服務，然後重新啟動。
選取 [測試連線]，然後等候一分鐘。
在連線測試成功且確認提供的認證已獲授權以啟用布建之後，請選取 [儲存]。

財產	價值
租戶 URL	https://localhost:8585/ecma2host_connectorName/scim

擴充 Microsoft Entra 架構

如果您的目錄伺服器需要不屬於 Microsoft Entra 預設使用者架構的其他屬性，那麼在進行配置時，您可以設定從常數中提供這些屬性的值，或從其他 Microsoft Entra 屬性轉換的表達式來提供，或通過擴充 Microsoft Entra 架構來提供。

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

如果您的使用者源自 Active Directory 網域服務，並在該目錄中具有屬性，您可以使用 Microsoft Entra Connect 或 Microsoft Entra Connect 雲端同步處理。這會將屬性設定為從Active Directory 網域服務同步處理至Microsoft Entra ID，使其可供布建至其他系統。

如果您的使用者來自 Microsoft Entra ID，您必須定義目錄延伸模組，以儲存每個使用者的新屬性。然後，更新計劃布建Microsoft Entra 使用者，為每位使用者提供這些屬性的值。

設置屬性映射

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

在 Microsoft Entra 系統管理中心的 Enterprise 應用程式下，選取 [內部部署 ECMA 應用程式]，然後選取 [配置] 頁面。
選取 編輯配置。
展開 [對應]，然後選取 [布建 Microsoft Entra 使用者]。如果這是您第一次設定此應用程式的屬性對應，則只有一個對應呈現為佔位元。
若要確認目錄伺服器的架構可在 Microsoft Entra ID 中使用，請選取 [顯示進階選項] 複選框，然後選取 [編輯 ScimOnPremises的 [編輯屬性] 列表。確定已列出組態精靈中選取的所有屬性。如果沒有，請等候數分鐘以讓架構重新整理，然後在導覽列中選取[屬性對應]，接著再次選取[編輯 ScimOnPremises 的屬性清單]以重新載入頁面。一旦您看到列出的屬性，然後從此頁面取消以返回對應清單。
目錄中的每個用戶都必須有唯一的辨別名稱。您可以使用屬性對應來指定連接器應該如何建構辨別名稱。選取 新增對應。使用下列值來建立對應，變更表達式中的辨別名稱，以符合目標目錄中組織單位或其他容器的名稱。
- 對應類型：expression
- 表達式：Join("", "CN=", Word([userPrincipalName], 1, "@"), ",DC=Contoso,DC=lab")
- 目標屬性：urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:-dn-
- 套用這個對應：僅在物件創建時
如果目錄伺服器需要提供多個結構化物件類別值或輔助物件類別值到 objectClass 屬性，則將一個對應新增到該屬性中。若要新增 objectClass的對應，請選擇 新增對應。使用下列值來建立對應，變更表達式中的物件類別名稱以符合目標目錄架構的名稱。
- 對應類型：expression
- 表達式，如果配置 POSIX 架構：Split("inetOrgPerson,posixAccount,shadowAccount",",")
- 目標屬性：urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:objectClass
- 套用此映射：僅在物件創建時

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

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

對應類型	來源屬性	目標屬性
直接	`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`
表達	`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`

將對應新增至 urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPassword，以設定使用者的初始隨機密碼。
選取儲存。

確保預備布建至目錄的使用者具有必要的屬性

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

如果您打算在 LDAP 目錄中建立新的使用者，則必須確保這些使用者在 Microsoft Entra 中的表示具備目標目錄用戶架構所需的來源屬性。每個使用者都需要唯一的 uid 和唯一的 uidNumber。

如果您的使用者源自 Active Directory 網域服務，並在該目錄中具有該屬性，那麼您可以使用 Microsoft Entra Connect 或 Microsoft Entra Connect 雲端同步來設定，該屬性應被從 Active Directory 網域服務同步至 Microsoft Entra ID，以便將其提供給其他系統進行配置。

如果您的使用者源自 Microsoft Entra ID，則針對您需要儲存在使用者上的每個新屬性，您將定義目錄延伸模組。然後，更新預定配置的 Microsoft Entra 使用者，賦予每位使用者這些屬性的值。

透過PowerShell確認使用者

在 Microsoft Entra ID 中用戶更新完成後，您可以使用 Microsoft Graph PowerShell Cmdlets 自動檢查使用者是否具備所有必要屬性。

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

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

貴組織首次針對此情境使用這些 cmdlet 時，您需要具備全域管理員角色，以便在租使用者中啟用 Microsoft Graph PowerShell。後續的互動可以使用權限較低的角色，例如：

如果您預期要建立新的使用者，請用系統管理員的身份操作。
如果您只是管理應用程式角色指派，應用程式管理員或 Identity Governance Administrator。

開啟 PowerShell。
如果您尚未安裝 Microsoft Graph PowerShell 模組，請使用此命令安裝 Microsoft.Graph.Users 模組和其他模組：
```
Install-Module Microsoft.Graph
```
如果您已安裝模組，請確定您使用的是最新版本：
```
Update-Module microsoft.graph.users,microsoft.graph.identity.governance,microsoft.graph.applications
```

連線到 Microsoft Entra ID:

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

建構要檢查的使用者清單和屬性。

$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目錄收集現有用戶

識別該目錄中哪些用戶屬於具有 Linux 驗證的用戶範圍。此選項將取決於您的 Linux 系統設定。對於某些設定，存在於LDAP目錄中的任何使用者都是有效的使用者。其他組態可能需要用戶擁有特定屬性，或是該目錄中群組的成員。
執行命令，從您的LDAP目錄擷取該使用者子集到 CSV 檔案。請確定輸出包含用來比對Microsoft Entra識別碼的用戶屬性。這些屬性的範例包括員工標識碼、帳戶名稱或 uid和電子郵件位址。
如有需要，請將包含使用者清單的 CSV 檔案傳送至已安裝 Microsoft Graph PowerShell Cmdlet 的系統。
既然您已取得目錄中的所有使用者清單，您將會比對目錄中的使用者與 Microsoft Entra ID 中的使用者。繼續之前，請先檢閱來源和目標系統中比對使用者的相關信息，。

擷取 Microsoft Entra 識別碼中的用戶標識碼

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

貴組織第一次針對此案例使用這些 Cmdlet 時，您必須具備全域管理員角色，才能在租使用者中使用 Microsoft Graph PowerShell。後續的互動可以使用較低權限的角色，例如：

如果您預期要創建新的使用者，可以考慮成為使用者管理員。
應用程式管理員或 Identity Governance Administrator，如果您只是管理應用程式角色指派。

開啟 PowerShell。
如果您尚未安裝 Microsoft Graph PowerShell 模組，請使用此命令安裝 Microsoft.Graph.Users 模組和其他模組：
```
Install-Module Microsoft.Graph
```
如果您已安裝模組，請確定您使用的是最新版本：
```
Update-Module microsoft.graph.users,microsoft.graph.identity.governance,microsoft.graph.applications
```

連線到 Microsoft Entra ID

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

如果這是您第一次使用此命令，您可能需要同意允許 Microsoft Graph 命令行工具具有這些許可權。
將應用程式資料存放區取得的使用者清單讀取至 PowerShell 會話中。如果使用者清單位於 CSV 檔案中，您可以請使用 PowerShell Cmdlet Import-Csv，並提供上一節中提到的檔名作為參數。

例如，如果從 SAP Cloud Identity Services 取得的檔案名為 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
```
選擇 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"
```

在 Microsoft Entra ID 系統中擷取這些使用者的識別碼。

下列 PowerShell 腳本會使用稍早指定的 $dbusers、$db_match_column_name和 $azuread_match_attr_name 值。它將查詢 Microsoft Entra ID，以找到擁有與來源檔案中每個記錄相符之屬性的使用者。如果檔案中有許多使用者從來源 SAP Cloud Identity Services、資料庫或目錄取得，此腳本可能需要幾分鐘的時間才能完成。如果在 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 }
}

檢視先前查詢的結果。查看 SAP Cloud Identity Services、資料庫或目錄中是否有任何使用者因為錯誤或缺少匹配項而無法找到於 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."

當腳本完成時，如果數據源中的任何記錄未找到於 Microsoft Entra ID，將會顯示錯誤。如果無法將應用程式資料存放區中的所有使用者記錄對應到 Microsoft Entra ID 中的使用者，您需要調查哪些記錄不匹配以及原因。

例如，某人的電子郵件地址和用戶主名稱 (userPrincipalName) 可能已在 Microsoft Entra ID 中變更，但應用程式的數據源中的相應 mail 屬性卻未更新。或者，使用者可能已經離開組織，但仍位於應用程式的數據源中。或者，應用程式數據源中可能有一個廠商或超級系統管理員帳戶，而該帳戶不會對應至Microsoft Entra ID 中的任何特定人員。
如果有使用者無法在 Microsoft Entra ID 中找到，或不是活跃状态而無法登入，但您希望審核他們的存取權限或在 SAP Cloud Identity Services、資料庫或目錄中更新其屬性，那麼您需要更新應用程式、匹配規則，或為他們更新或建立 Microsoft Entra 使用者。如需有關在未與 Microsoft Entra ID使用者相符的應用程式中進行哪些變更的詳細資訊，請參閱管理對應和使用者帳戶。

如果您選擇在 Microsoft Entra ID 中建立使用者的選項，您可以使用下列其中一項來大量建立使用者：
- CSV 檔案，如在 Microsoft Entra 系統管理中心中大量建立使用者中所述
- New-MgUser 命令工具
請確定這些新使用者已填入Microsoft Entra ID 所需的屬性，以便稍後將它們與應用程式中的現有使用者相符，以及 Microsoft Entra 識別碼所需的屬性，包括 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"
```
然後，您可以使用此腳本為未在 Microsoft Entra ID 中匹配的 SAP Cloud Identity Services、資料庫或目錄中的使用者在 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
   }
}
```

將任何遺漏的使用者加入至 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."

在 Microsoft Entra ID 中將使用者指派給應用程式

既然您已經讓 Microsoft Entra ECMA 連接器主機與 Microsoft Entra ID 進行通信，而且已經設定屬性對應，接下來您可以設定提供和管理的範圍內的使用者。

重要

如果您使用混合式身分識別系統管理員角色登入，您必須使用至少具有本節應用程式管理員角色的帳戶進行註銷和登入。混合式身分識別系統管理員角色沒有將使用者指派給應用程式的許可權。

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

如果您還不想更新 LDAP 目錄中的現有使用者，請從具有必要屬性且將布建至目錄伺服器的 Microsoft Entra 識別符中選取測試使用者。

確定用戶選取的所有屬性都會對應至目錄伺服器架構的必要屬性。
在 Azure 入口網站中，選取 [企業應用程式]。
選取 內部部署 ECMA 應用程式 應用程式。
在左側 [管理] 底下，選取 [[使用者和群組]。
選擇 新增使用者/群組。
在 使用者下，選取 未選取。
從右側選取使用者，然後選取 [選取] 按鈕。
現在選擇 [指派]。

測試配置

現在您的屬性已對應，並且已分配一個初始使用者，您可以使用其中一位使用者進行即時布建測試。

在執行 Microsoft Entra ECMA 連接器主機的伺服器上，選取 [開始 ]。
輸入執行，然後在方塊中輸入 services.msc。
在 [Services] 清單中，確定 Microsoft Entra Connect 布建代理程式 服務和 Microsoft ECMA2Host 服務都正在執行。如果沒有，請選擇開始。
在 Azure 入口網站中，選取 [企業應用程式]。
選取 內部部署 ECMA 應用程式 應用程式。
在左側，選取 [布建 ]。
選取 按需配置。
搜尋其中一個測試用戶，然後選取 Provision。
幾秒鐘後，訊息 「已成功在目標系統中建立使用者」 會出現，並顯示使用者屬性清單。如果出現錯誤，請參閱疑難解答布建錯誤。

開始配置使用者

測試隨選布建成功之後，請新增其餘的使用者。若要深入瞭解如何使用 New-MgServicePrincipalAppRoleAssignedTo大量建立應用程式角色指派，請參閱在 entra ID Microsoft中控管應用程式的現有使用者。

在 Azure 入口網站中，選取應用程式。
在左側 [管理] 底下，選取 [使用者和群組]。
確定所有使用者都被指派到應用程式角色之中。
返回設置組態頁面。
請確保範圍僅設定為已指派的使用者和群組，將布建狀態設為開啟，然後選擇儲存。
等候數分鐘才能開始布建。最多可能需要 40 分鐘的時間。布建作業完成之後，如下一節所述。

針對配置錯誤進行疑難解答

如果顯示錯誤，請選擇「檢視佈建記錄」。查看記錄檔中是否有狀態失敗的數據列，然後選取該數據列。

如果錯誤訊息 無法建立使用者，請檢查根據目錄架構需求顯示的屬性。

如需詳細資訊，請查閱[疑難解答 & 建議] 索引標籤。

如果疑難排解錯誤訊息中包含 objectClass 值為 invalid per syntax，請確保配置屬性映射到 objectClass 屬性時，只包含目錄伺服器能識別的物件類別名稱。

如需排除其他錯誤，請參閱內部部署應用程式佈建問題的疑難解答。

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

檢查使用者是否已成功配置

等待之後，請檢查目錄伺服器，以確保使用者已被配置。您對目錄伺服器的查詢將取決於您目錄伺服器所提供的命令。

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

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

後續步驟

如需了解布建服務的功能、運作方式和常見問題的更多資訊，請參閱使用 Microsoft Entra ID 將使用者布建和取消布建至 SaaS 應用程式和內部部署應用程式布建架構。

共用方式為