配置 Microsoft Entra ID 以将用户预配到 LDAP 目录中

以下文档提供了配置和教程信息，演示如何将用户从 Microsoft Entra ID 预配到 LDAP 目录中。

本文档介绍将用户从 Microsoft Entra ID 自动预配和取消预配到 LDAP 目录中所需的步骤。本文档说明了如何将用户预配到 AD LDS 作为示例 LDAP 目录，但可以预配到以下部分中提到的任何受支持的 LDAP 目录服务器中。不支持通过此解决方案将用户预配到 Active Directory 域服务。

有关此服务的作用、工作原理和常见问题的重要详细信息，请参阅使用 Microsoft Entra ID 自动预配和取消预配 SaaS 应用程序以及本地应用程序预配体系结构。

将用户预配到 LDAP 目录中的先决条件

本地部署先决条件

使用目录服务器查询用户的应用程序。
可在其中创建、更新和删除用户的 Active Directory 域服务以外的目标目录。例如，Active Directory 轻型服务（AD LDS）。此目录实例不应是也用于将用户预配到 Microsoft Entra ID 的目录，因为两种方案都可能会创建包含 Microsoft Entra Connect 的循环。
具有至少 3 GB RAM 的计算机，用于托管预配代理。计算机应具有 Windows Server 2016 或更高版本的 Windows Server，并与目标目录连接，同时拥有到 login.partner.microsoftonline.cn、其他 Microsoft 在线服务和 Azure 域的出站连接。例如，托管在 Azure IaaS 或代理后面的 Windows Server 2016 虚拟机。
需要安装 .NET Framework 4.7.2。
可选：虽然这不是必需的，但建议下载适用于 Windows Server 的 Microsoft Edge 并将其用于 Internet Explorer。

支持的 LDAP 目录服务器

连接器依赖于各种技术来检测和标识 LDAP 服务器。连接器使用根 DSE、供应商名称/版本，并检查架构以查找某些 LDAP 服务器中已知存在的唯一对象和属性。

OpenLDAP
Microsoft Active Directory 轻型目录服务
389 目录服务器
Apache Directory 服务器
IBM Tivoli DS
Isode 目录
NetIQ eDirectory
Novell eDirectory
打开 OpenDJ
打开DS
Oracle（以前为 Sun ONE）Directory Server Enterprise Edition
RadiantOne 虚拟目录服务器 (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 之间的唯一数字作为其用户 ID 号来支持 POSIX 工作负荷，则需要从用户的现有属性生成该数字，或者扩展 Microsoft Entra 架构，并在基于 LDAP 的应用程序范围内的用户填充该属性。请参阅 Graph 扩展性，了解如何创建其他目录扩展。

选择运行配置

创建连接器配置以与目录服务器交互时，首先要将连接器配置为读取目录架构，并将该架构映射到 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 连接器如何与目录服务器交互

将连接器部署到现有目录服务器之前，需要与组织中的目录服务器操作员讨论如何与其目录服务器集成。你将收集的信息包括有关如何连接到目录服务器的网络信息、连接器应如何向目录服务器进行身份验证、目录服务器选择的架构来为用户建模、命名上下文的基本可分辨名称和目录层次结构规则、如何将目录服务器中的用户与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` 和 OpenLDAP `inetOrgPerson`
目录服务器中用于用户的辅助对象类	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。该连接器还支持通过 LDAPS（LDAP over TLS）协议连接到端口 636 上的目录服务器。

需要一个标识账户，该账户应已在目录服务器中配置，以便连接器进行身份验证。此帐户通常使用可分辨名称标识，并具有关联的密码或客户端证书。若要对连接目录中的对象执行导入和导出操作，连接器帐户必须在目录的访问控制模型中具有足够的权限。连接器需要具有写入权限才能导出和读取权限才能导入。权限设置是在目标目录本身的管理体验内执行。

目录架构指定表示目录中实际实体的对象类和属性。连接器支持使用结构对象类（例如 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 目录中创建新用户，而不仅仅是更新或删除现有用户，则还需要确定使用该目录服务器的应用程序如何处理身份验证。建议的方法是，让应用程序使用联合身份验证或 SSO 协议（如 SAML、OAuth 或 OpenID Connect）进行身份验证至 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 更新目录服务器中的对象。此行为取决于将使用目录服务器的应用程序，因为许多目录（如 OpenLDAP）可能没有指示用户帐户被停用的默认方法。

准备 LDAP 目录

如果还没有目录服务器，并且想要试用此功能，则准备 Active Directory 轻型目录服务以便从 Microsoft Entra ID 进行预配，演示如何创建测试 AD LDS 环境。如果已部署另一个目录服务器，可以跳过本文，并继续安装和配置 ECMA 连接器主机。

安装并配置 Microsoft Entra Connect 预配代理

如果已经下载了预配代理并为另一个本地应用程序进行了配置，请继续阅读下一节。

登录到 Azure 门户。
请转到“企业应用程序”并选择“新建应用程序”。
搜索“本地 ECMA 应用”应用程序，为该应用命名，然后选择“创建”以将其添加到租户。
在菜单中导航到应用程序的“预配”页。
选择开始。
在“预配”页上，将模式更改为“自动”。

在“本地连接”下，选择“下载并安装”，然后选择“接受条款并下载”。

离开门户，打开预配代理安装程序，同意服务条款，然后选择“安装”。
等待 Microsoft Entra 预配代理配置向导，然后选择“下一步”。
在“选择扩展”步骤中，选择“本地应用程序预配”，然后选择“下一步”。
预配代理将使用操作系统的 Web 浏览器显示一个弹出窗口，供你向 Microsoft Entra ID 进行身份验证，还可能向组织的标识提供者进行身份验证。如果使用 Internet Explorer 作为 Windows Server 上的浏览器，则可能需要将Microsoft网站添加到浏览器的受信任站点列表中，以允许 JavaScript 正确运行。
当系统要求你进行授权时，请提供 Microsoft Entra 管理员的凭据。用户必须至少具有混合标识管理员角色。
选择“确认”以确认设置。安装成功后，可以选择“退出”，并关闭“预配代理包”安装程序。

配置本地 ECMA 应用

返回到门户，在“本地连接”部分，选择已部署的代理，然后单击“分配代理”。
在使用配置向导完成下一步配置时，请保持此浏览器窗口为打开状态。

配置 Microsoft Entra ECMA 连接器主机证书

在安装预配代理的 Windows Server 上，右键单击“开始”菜单中Microsoft ECMA2Host 配置向导，然后以管理员身份运行。必须以 Windows 管理员身份运行，向导才能创建必要的 Windows 事件日志。
ECMA 连接器主机配置启动后，如果这是首次运行向导，它将要求你创建证书。保留默认端口 8585 并选择“生成证书”以生成证书。自动生成的证书将作为部分受信任根证书进行自签名。 SAN 与主机名匹配。
选择“保存”。

注释

如果选择生成新证书，请记录证书到期日期，以确保计划在证书到期前返回配置向导并重新生成证书。

配置通用 LDAP 连接器

根据你选择的选项，一些向导屏幕可能不会出现，并且信息可能略有不同。对于此示例配置，AD LDS 使用 User 对象类为用户提供服务，OpenLDAP 使用 inetOrgPerson 对象类。请使用以下信息来指导你完成配置。

生成一个机密令牌，用于向连接器验证 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 端口号。如果目录服务器配置为通过 SSL 进行 LDAP，请使用端口 636。对于 `Start TLS`，或者如果使用网络级安全，请使用端口 389。
连接超时值	180
绑定	此属性指定连接器如何向目录服务器进行身份验证。在 `Basic` 设置的情况下，或在 `SSL` 或 `TLS` 设置且未配置客户端证书的情况下，连接器将发送 LDAP 简单绑定，以使用可分辨名称和密码进行身份验证。设置`SSL`或`TLS`并指定客户端证书后，连接器将发送 LDAP SASL `EXTERNAL` 绑定以使用客户端证书进行身份验证。
用户名	ECMA 连接器如何向目录服务器进行身份验证。在此 AD LDS 示例中，示例用户名为 `CN=svcAccount,CN=ServiceAccounts,CN=App,DC=contoso,DC=lab`，在 OpenLDAP 中，示例用户名为 `cn=admin,dc=contoso,dc=lab`
密码	用于 ECMA 连接器向目录服务器进行身份验证的用户密码。
领域/域	仅当选择 `Kerberos` 作为“绑定”选项时，才需要此设置以指定用户的领域或域。
证书	仅当已选择 `SSL` 或 `TLS` 作为“绑定”选项时，才会使用此部分中的设置。
属性别名	属性别名文本框用于架构中定义的具有RFC4522语法的属性。在架构检测期间无法检测这些属性，连接器需要帮助标识这些属性。例如，如果目录服务器未发布`userCertificate;binary`并且要预配该属性，则必须在属性别名框中输入以下字符串，才能将 userCertificate 属性正确标识为二进制属性： `userCertificate;binary` 如果不需要架构中的任何特殊属性，则可以将此属性留空。
包括操作属性	选中`Include operational attributes in schema`复选框以还包括由目录服务器创建的属性。其中包含对象的创建时间和上次更新时间等属性。
包括可扩展属性	`Include extensible attributes in schema`如果在目录服务器中使用可扩展对象（RFC4512/4.3），请选中该复选框。启用此选项允许在所有对象上使用每个属性。选择此选项会使架构变得很大，因此除非连接的目录使用此功能，否则建议不要选择此选项。
允许手动定位点选择	保持未选中状态。

注释

如果在尝试连接时遇到问题，并且无法转到 “全局 ”页，请确保已启用 AD LDS 或其他目录服务器中的服务帐户。

在 “全局”页上，根据需要配置增量更改日志的专有名称和附加的 LDAP 功能。该页面预先填充了 LDAP 服务器提供的信息。查看显示的值，然后选择“ 下一步”。

财产	说明
支持的 SASL 机制	顶部部分显示服务器本身提供的信息，包括 SASL 机制列表。
服务器证书详细信息	如果 `SSL` 指定或 `TLS` 已指定，向导将显示目录服务器返回的证书。确认颁发者、主题和指纹对应于正确的目录服务器。
找到必需的功能	连接器还会验证根 DSE 中是否存在强制控制措施。如果未列出这些控件，会显示警告。某些 LDAP 目录不会列出根 DSE 中的所有功能，即使存在警告，连接器也可能无法正常工作。
支持的控件	支持的控件复选框控制某些操作的行为
增量导入	更改日志 DN 是增量更改日志使用的命名上下文，例如 cn=changelog。必须指定此值才能执行增量导入。
密码属性	如果目录服务器支持不同的密码属性或密码哈希，则可以指定密码更改的目标。
分区名称	在其他分区列表中，可以添加未自动检测到的其他命名空间。例如，如果有多个应同时一起导入的服务器构成了一个逻辑群集，则可以使用此设置。就如同 Active Directory 可以在一个林中有多个域，而所有域都共享一个架构，在此框中输入其他命名空间就可以模拟此状况。每个命名空间都可以从不同的服务器导入，并在 “配置分区和层次结构 ”页上进行进一步配置。

在 “分区 ”页上，保留默认值，然后选择“ 下一步”。

在 “运行配置文件 ”页上，确保选中“ 导出 ”复选框和 “完全导入 ”复选框。然后选择下一步。

财产	说明
Export	运行配置文件，用于将数据导出到 LDAP 目录服务器。此运行配置文件是必选的。
完全导入	运行配置文件，该配置文件将从前面指定的 LDAP 源导入所有数据。此运行配置文件是必选的。
增量导入	运行配置文件，该配置文件仅导入自上次完整导入或增量导入以来的 LDAP 更改。仅当已确认目录服务器满足必要要求时，才启用此运行配置文件。有关详细信息，请参阅通用 LDAP 连接器参考。

在 “导出 ”页上，保留默认值不变，然后单击“ 下一步”。
在 “完全导入 ”页上，保留默认值不变，然后单击“ 下一步”。
在 DeltaImport 页上，如果存在，则保留默认值不变，然后单击“ 下一步”。

填写“对象类型”页的文本框，选择“下一步”。

财产	说明
“目标对象”	此值是 LDAP 目录服务器中用户的结构对象类。例如， `inetOrgPerson` 对应 OpenLDAP，或 `User` 对应 AD LDS。不要在此字段中指定辅助对象类。如果目录服务器需要辅助对象类，则会在 Azure 门户中使用属性映射来配置它们。
锚点	此属性的值对于目标目录中的每个对象应是唯一的。 Microsoft Entra 预配服务将在初始周期后使用此属性查询 ECMA 连接器主机。对于 AD LDS，使用 `ObjectGUID`；有关其他目录服务器，请参阅下表。请注意，可以选择区别名称为`-dn-`。多值属性（如 `uid` OpenLDAP 架构中的属性）不能用作定位点。
查询属性	此属性应与定位点相同，例如，如果 AD LDS 是目录服务器，则为 `objectGUID`，如果是 OpenLDAP，则为 `_distinguishedName`。
DN	目标对象的“distinguishedName”。保留 `-dn-`。
自动生成	不受控制的

下表列出了要使用的 LDAP 服务器和定位点：

目录	锚点
Microsoft AD LDS 和 AD GC	objectGUID。必须使用代理版本 1.1.846.0 或更高版本，才能将 `ObjectGUID` 用作定位点。
389 目录服务器	dn
Apache Directory	dn
IBM Tivoli DS	dn
Isode 目录	dn
Novell/NetIQ eDirectory	GUID
打开 DJ/DS	dn
打开 LDAP	dn
Oracle ODSEE	dn
RadiantOne VDS	dn
Sun One Directory 服务器	dn

ECMA 主机可发现目标目录支持的属性。可以选择要公开给 Microsoft Entra ID 的属性。然后，可在 Azure 门户中配置这些属性以进行预配。在 “选择属性” 页上，从下拉列表中一个一个地添加所有属性，作为必选属性或用于从 Microsoft Entra ID 进行配置。
“属性”下拉列表显示在目标目录中发现的任何属性，但在之前使用配置向导“选择属性”页上未选择该属性。

确保 objectClass 属性的复选框未选中，并且如果正在设置 userPassword，则该 userPassword 属性的复选框应为不可选择或已选中。

如果您使用 OpenLDAP 并使用 inetOrgPerson 架构，请配置以下属性的可见性。

Attribute 视为单个值

cn Y

邮件 Y

对象类

sn Y

用户密码 Y

如果您在使用包含 POSIX 模式的 OpenLDAP，请配置下列属性的可见性。

Attribute 视为单个值

_distinguishedName

-Dn-

export_password (导出密码)

cn Y

gidNumber

主目录

邮件 Y

对象类

sn Y

uid Y

uidNumber

用户密码 Y

添加所有相关属性后，选择“下一步”。
在 “取消预配 ”页上，可以指定在用户离开应用程序范围时是否希望Microsoft Entra ID 从目录中删除用户。如果是，请在“ 禁用流”下选择“ 删除”，然后在“ 删除”流下，选择“ 删除”。如果选择 Set attribute value ，则在上一页上选择的属性将不能在取消预配页面上使用。

Attribute	视为单个值
cn	Y
邮件	Y
对象类
sn	Y
用户密码	Y

Attribute	视为单个值
_distinguishedName
-Dn-
export_password (导出密码)
cn	Y
gidNumber
主目录
邮件	Y
对象类
sn	Y
uid	Y
uidNumber
用户密码	Y

注释

如果您使用设置属性值，请注意仅允许使用布尔值。

选择完成。

确保 ECMA2Host 服务正在运行，并且可以从目录服务器读取

按照以下步骤确认连接器主机已启动，并且已将目录服务器中的任何现有用户读取到连接器主机。

在运行 Microsoft Entra ECMA 连接器主机的服务器上，选择“启动”。
根据需要选择 “运行 ”，然后在框中输入 services.msc 。
在“服务”列表，确保“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 到连接器主机的连接

返回到在门户中配置应用程序预配的 Web 浏览器窗口。

注释

如果窗口已超时，则需要重新选择代理。
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 架构来实现。

如果目录服务器要求用户具有属性（例如 uidNumber OpenLDAP POSIX 架构），并且该属性已不是用户的 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”属性列表 以重新加载页面。看到属性列出后，从此页面取消以返回到映射列表。
目录中的每个用户必须具有唯一的可分辨名称。可以通过属性映射指定连接器应如何构造可分辨名称。选择“ 添加新映射”。使用以下示例中的值创建映射，更改表达式中的可分辨名称以匹配目标目录中的组织单位或其他容器。
- 映射类型：表达式
- 表达式（如果预配到 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-
- 应用此映射：仅在创建对象期间
如果目录服务器要求在 objectClass 属性中提供多个结构对象类值或辅助手段类值，则将映射添加到该属性。对于预配到 AD LDS 的此示例， objectClass 映射不需要，但对于其他目录服务器或其他架构可能是必需的。若要添加 objectClass映射，请选择“ 添加新映射”。使用以下示例中的值创建映射，更改表达式中的对象类名称以匹配目标目录架构的名称。
- 映射类型：表达式
- 表达式，如果配置 inetOrgPerson 架构：Split("inetOrgPerson",",")
- 表达式（如果预配 POSIX 架构）： Split("inetOrgPerson,posixAccount,shadowAccount",",")
- 目标属性： urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:objectClass
- 应用此映射：仅在创建对象期间
如果将进行 AD LDS 预配，并且存在从 userPrincipalName 到 PLACEHOLDER 的映射，请单击该映射并进行编辑。使用以下值更新映射。
- 映射类型：直接
- 源属性： userPrincipalName
- 目标属性： urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPrincipalName
- 匹配优先级：1
- 应用此映射：仅在创建对象期间
如果要预配到 AD LDS 中，请为 isSoftDeleted 添加映射。选择“ 添加新映射”。使用以下值创建映射。
- 映射类型：直接
- 源属性： isSoftDeleted
- 目标属性： urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:msDS-UserAccountDisabled

对于目录服务器下表中的每个映射，请选择“ 添加新映射”，并指定源和目标属性。如果要将现有用户预配到现有目录中，则需要编辑公共属性的映射，以便使用该属性设置匹配对象。在此处了解有关属性映射的详细信息。

对于 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和 homeDirectoryuiduidNumber属性。每个用户都需要一个唯一的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`

如果预配到 AD LDS 以外的目录，请添加一个映射，在 urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPassword 中设置用户的初始随机密码。对于 AD LDS，userPassword 没有映射。
选择“保存”。

确保为应用程序配置用户时，其在 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）都包含输出用户列表的命令。

确定该目录中哪些用户属于应用程序用户。此选项将取决于应用程序的配置。对于某些应用程序，LDAP 目录中存在的任何用户都是有效的用户。其他应用程序可能要求用户具有特定属性或者是该目录中的组成员。
运行从 LDAP 目录中检索该用户子集的命令。确保输出包含将用于与 Microsoft Entra ID 匹配的用户的属性。这些属性的示例包括员工 ID、帐户名称和电子邮件地址。

例如，在 Windows 上使用 AD LDS csvde 程序的此命令将在当前文件系统目录中生成 CSV 文件，其中包含 userPrincipalName 目录中每个人的属性：
```
$out_filename = ".\users.csv"
csvde -f $out_filename -l userPrincipalName,cn -r "(objectclass=person)"
```
如果需要，请将包含用户列表的 CSV 文件传输到安装了 Microsoft Graph PowerShell cmdlet 的系统。
现在，你已获得从应用程序获取的所有用户的列表，会将应用程序数据存储中的这些用户与 Microsoft Entra ID 中的用户匹配。在继续操作之前，请查看有关匹配源系统和目标系统中的用户的信息。

检索 Microsoft Entra ID 中用户的 ID

本部分演示如何使用 Microsoft Graph PowerShell cmdlet 与 Microsoft Entra ID 进行交互。

当您的组织首次在此方案中使用这些 cmdlet 时，您需要具备全局管理员权限，以便在租户中允许使用 Microsoft Graph PowerShell。后续交互可以使用较低特权角色，例如：

用户管理员（如果预计会创建新用户）。
在您仅负责管理应用程序角色分配的情况下，可以是应用程序管理员或标识治理管理员。

打开 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 -Environment China -ClientId 'YOUR_CLIENT_ID' -TenantId 'YOUR_TENANT_ID' -ContextScope Process -Scopes "User.ReadWrite.All,Application.ReadWrite.All,AppRoleAssignment.ReadWrite.All,EntitlementManagement.ReadWrite.All"

如果这是你第一次使用此命令，则可能需要同意允许 Microsoft Graph 命令行工具具有这些权限。
将从应用程序数据存储中获取的用户列表读取到 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
```
选择 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 中的这些用户的 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 }
}

查看以前查询的结果。请查看 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."

脚本完成以后，如果数据源中有任何记录在 Microsoft Entra ID 中无法找到，系统会提示错误。 ** 如果应用程序的数据存储中并非所有用户记录都能在 Microsoft Entra ID 中找到，那么您需要调查哪些记录没有匹配及其原因。

例如，某人在 Microsoft Entra ID 中的电子邮件地址和 userPrincipalName 可能已更改，但在应用程序的数据源中未更新其相应的 mail 属性。或者，用户可能已经离开了组织，但仍处于应用程序的数据源中。或者，应用程序数据源中可能有一个供应商或超级管理员帐户，该帐户与 Microsoft Entra ID 中的任何特定人员都不对应。
如果存在无法在 Microsoft Entra ID 中找到的用户，或有用户未处于活动状态并且能够登录，但你想要审查其权限或在 SAP 云标识服务、数据库或目录中更新其属性，则需要更新应用程序、匹配规则，或为其更新或创建 Microsoft Entra 用户。

如果选择用于在 Microsoft Entra ID 中创建用户的选项，则可以使用以下任一方法批量创建用户：
- CSV 文件，如在 Microsoft Entra 管理中心批量创建用户中所述
- New-MgUser cmdlet
确保使用 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
   }
}
```

将任何缺失的用户添加到 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 ECMA 连接器主机与 Microsoft Entra ID 通信并配置属性映射后，接下来即可继续配置预配对象的范围。

重要

如果您使用了混合标识管理员角色登录，则需要注销并使用至少具有应用程序管理员角色的帐户重新登录以访问此部分。混合标识管理员角色无权将用户分配到应用程序。

如果 LDAP 目录中存在现有用户，则应为 Microsoft Entra ID 中的现有用户创建应用程序角色分配。若要详细了解如何批量使用 New-MgServicePrincipalAppRoleAssignedTo创建应用程序角色分配，请参阅管理Microsoft Entra ID 中的应用程序现有用户。

否则，如果 LDAP 目录为空，则从具有所需属性的 Microsoft Entra ID 中选择一个测试用户，并将其预配到应用的目录服务器。

确保用户将选择的对象具有所有将被映射到目录服务器架构所需属性的属性。
在 Microsoft Azure AD 门户中，选择“企业应用程序”。
选择“本地 ECMA 应用”应用程序。
在左边的“管理”下，选择“用户和组” 。
选择“添加用户/组”。
在用户下，选择未选择。
从右侧选择用户，然后选择 “选择 ”按钮。
现在选择“分配”。

测试资源配置

你的属性已经映射并且已经分配了一个初始用户后，你可以使用一个用户来测试按需供应。

在运行 Microsoft Entra ECMA 连接器主机的服务器上，选择“启动”。
在框中键入“run”，并输入“services.msc”。
在 “服务 ”列表中，确保 Microsoft Entra Connect 预配代理 服务和 Microsoft ECMA2Host 服务都正在运行。否则，请选择开始。
在 Microsoft Azure AD 门户中，选择“企业应用程序”。
选择“本地 ECMA 应用”应用程序。
在左侧，选择“预配”。
选择按需供应。
搜索一个测试用户，选择“预配”。
几秒钟后，将出现消息“已在目标系统中成功创建用户”，其中包含用户属性列表。如果出现错误，请参阅排查预配错误。

开始预配用户

测试按需预配成功后，添加其余用户。

在 Azure 门户中，选择该应用程序。
在左边的“管理”下，选择“用户和组” 。
确保所有用户都分配到应用程序角色。
更改回预配配置页。
确保范围设置为仅分配的用户和组，将预配状态设置为 “打开”，然后选择“ 保存”。
等待几分钟，以便系统开始预配。该过程可能需要用时 40 分钟以上。预配作业完成后，如下一节所述，

排除预配错误

如果显示错误，请选择“查看预配日志”。在日志中查找状态为 “失败”的行，然后单击该行。

如果错误消息 为“无法创建用户”，请检查根据目录架构的要求显示的属性。

有关详细信息，请切换到“故障排除和建议”选项卡。

如果故障排除错误消息包含 objectClass 值为 invalid per syntax，请确保预配属性 objectClass 的映射仅包含目录服务器认可的对象类名称。

有关其他错误，请参阅对本地应用程序预配进行故障排除。

如果要暂停对此应用程序的预配，请在预配配置页上将预配状态更改为 “关闭”，然后选择“ 保存”。此操作将停止预配服务在未来的运行。

检查用户是否已成功预配

等待后，请检查目录服务器以确保预配用户。对目录服务器的查询将取决于目录服务器提供的命令。

以下说明说明了如何检查 AD LDS。

打开服务器管理器，然后选择左侧的 AD LDS。
右键单击 AD LDS 实例，然后从弹出窗口中选择 ldp.exe。
在 ldp.exe 顶部，依次选择“连接”和“连接”。
输入以下信息，然后单击“ 确定”。
- 服务器：APP3
- 端口：636
- 在 SSL 框中打勾
在顶部的“连接”下，选择“绑定” 。
保留默认值，然后单击“ 确定”。
在顶部，选择“视图”和“树”
对于 BaseDN，请输入 CN=App，DC=contoso，DC=lab ，然后单击“ 确定”。
在左侧展开 DN，然后单击 CN=CloudUsers，CN=App，DC=contoso，DC=lab。您应该能看到从 Microsoft Entra ID 预配的用户。

以下说明演示如何检查 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 预配的用户。

后续步骤

Last updated on 2026-03-27