配置 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.microsoftonline.com、其他 Microsoft Online Services 和 Azure 域。 例如，托管在 Azure IaaS 或代理后面的 Windows Server 2016 虚拟机。
- 需要安装 .NET Framework 4.7.2。
- 可选：虽然不一定非要这样做，但我们建议下载 Microsoft Edge for Windows Server 并用它代替 Internet Explorer。
受支持的 LDAP 目录服务器
连接器依赖各种技术来检测和识别 LDAP 服务器。 连接器使用根 DSE（供应商名称和版本），并检查架构，找出已知存在于某些 LDAP 服务器中的唯一对象和属性。
- OpenLDAP
- Microsoft Active Directory 轻型目录服务
- 389 目录服务器
- Apache Directory 服务器
- IBM Tivoli DS
- Isode Directory
- NetIQ eDirectory
- Novell eDirectory
- Open DJ
- Open 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 建议使用单独的代理进行云同步，并使用另一个代理进行本地应用预配。
- 对于 AD LDS，目前无法使用密码预配用户。 因此，需要禁用 AD LDS 的密码策略，或者在禁用状态下预配用户。
- 对于其他目录服务器，可以设置初始随机密码，但无法将 Microsoft Entra 用户的密码预配到目录服务器。
- 不支持将用户从 Microsoft Entra 预配到 Active Directory 域服务。
- 不支持将用户从 LDAP 预配到 Microsoft Entra ID。
- 不支持将组和用户成员资格预配到目录服务器。
选择运行配置文件
为连接器创建配置以与目录服务器交互时，将首先配置连接器以读取目录的架构，将该架构映射到 Microsoft Entra ID 的架构，然后通过运行配置文件配置连接器应持续使用的方法。 你将配置的每个运行配置文件会指定连接器如何生成 LDAP 请求，以从目录服务器导入或导出数据。 在将连接器部署到现有目录服务器之前，需要与组织中的目录服务器操作员讨论将在其目录服务器上执行的操作模式。
配置后，预配服务启动时，它将自动执行在“完整导入”运行配置文件中配置的交互。 在此运行配置文件中，连接器将使用 LDAP 搜索操作从目录中读取用户的所有记录。 此运行配置文件是必需的，以便稍后如果 Microsoft Entra ID 需要为用户执行更改，Microsoft Entra ID 在目录中为该用户更新现有对象，而不是为该用户创建新对象。
每次在 Microsoft Entra ID 进行更改（例如，向应用程序分配新用户或更新现有用户）时，预配服务都将在“导出”运行配置文件中执行 LDAP 交互。 在“导出”运行配置文件中，Microsoft Entra ID 将向目录中的 Add、Modify、Remove 或 Rename 对象发出 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 和 OpenLDAP 分别对应于 CN=svcAccountLDAP,CN=ServiceAccounts,CN=App,DC=contoso,DC=lab 和 cn=admin,dc=contoso,dc=lab |
| 供连接器用来向目录服务器自我验证身份的密码 | 配置向导的“连接”页 | |
| 目录服务器中用户的结构对象类 | 配置向导的“对象类型”页 | AD LDS 和 OpenLDAP 分别对应于 User 和 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 设置为紧跟在 CN=CloudUsers,CN=App,DC=Contoso,DC=lab (AD LDS ) 和 DC=Contoso,DC=lab (OpenLDAP) 之下 |
| 用于关联 Microsoft Entra ID 与目录服务器中用户的属性 | Azure 门户中的“预配”页属性映射 | 对于 AD LDS 未配置，因为此示例适用于最初为空的目录，对于 OpenLDAP 为 mail |
| 当用户在 Microsoft Entra ID 中超出范围时的取消预配行为 | 配置向导中的“取消预配”页 | 从目录服务器中删除用户 |
目录服务器的网络地址是一个主机名和一个 TCP 端口号（通常是端口 389 或 636）。 除非目录服务器与同一 Windows Server 上的连接器位于同一位置，或者你正在使用网络级安全性，否则从连接器到目录服务器的网络连接需要使用 SSL 或 TLS 进行保护。 连接器支持通过端口 389 连接到目录服务器，并使用“启动 TLS”在会话中启用 TLS。 对于 LDAPS（基于 TLS 的 LDAP）通信，连接器还支持通过端口 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 用户预配到数据库中。 如果分配给应用程序的用户在 Microsoft Entra ID 中被删除，则 Microsoft Entra ID 将向目录服务器发送删除操作。 当用户因超出范围而无法使用应用程序时，可以让 Microsoft Entra ID 更新目录服务器中的对象。 此行为取决于将使用目录服务器的应用程序，因为许多目录（例如 OpenLDAP）可能没有指示用户帐户已停用的默认方式。
准备 LDAP 目录
如果还没有目录服务器，并希望试用此功能，则准备 Microsoft Entra ID 轻型目录服务以从 Azure AD 进行预配展示了如何创建测试 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 连接器
根据你选择的选项，一些向导屏幕可能不会出现，并且信息可能略有不同。 考虑到此示例配置的目的，已展示使用 User 对象类 (AD LDS) 和 inetOrgPerson 对象类 (OpenLDAP) 预配用户。 请使用以下信息来指导你完成配置。
生成一个机密令牌，用于向连接器验证 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 SASLEXTERNAL绑定以使用客户端证书进行身份验证。用户名 ECMA 连接器如何向目录服务器验证自己的身份。 在此示例中，示例用户名为 CN=svcAccount,CN=ServiceAccounts,CN=App,DC=contoso,DC=lab(AD LDS) 和cn=admin,dc=contoso,dc=lab(OpenLDAP)密码 ECMA 连接器将向目录服务器验证自己身份的用户的密码。 领域/域 仅当选择 Kerberos作为“绑定”选项时才需要此设置，用以提供用户的领域/域。证书 仅当选择 SSL或TLS作为“绑定”选项时，才会使用本部分中的设置。属性别名 “属性别名”文本框用于以 RFC4522 语法在架构中定义的属性。 在架构检测期间无法检测这些属性，连接器需要帮助识别这些属性。 例如，如果目录服务器未发布 userCertificate;binary而你希望预配该属性，则必须在属性别名框中输入以下字符串以将 userCertificate 属性正确标识为二进制属性：userCertificate;binary。 如果不需要任何架构中不存在的特殊属性，可以将此属性留空。包括操作属性 选中 Include operational attributes in schema复选框以同时包括目录服务器创建的属性。 其中包含对象的创建时间和上次更新时间等属性。包括可扩展属性 如果在目录服务器中使用可扩展对象 (RFC4512/4.3)，请选中 Include extensible attributes in schema复选框。 启用此选项后，可在所有对象上使用每个属性。 选择此选项会使架构变得很大，因此除非连接的目录使用此功能，否则建议不要选择此选项。允许手动定位点选择 保持未选中状态。 注意
如果在尝试连接时遇到问题，并且无法继续访问“全局”页面，请确保在 AD LDS 或其他目录服务器中启用了服务帐户。
在“全局”页面上，将配置增量更改日志的可分辨名称（如果需要）和其他 LDAP 功能。 该页面预先填充了 LDAP 服务器提供的信息。 查看显示的值，然后选择“下一步”。
属性 说明 受支持的 SASL 机制 顶部部分显示服务器本身提供的信息，包括 SASL 机制的列表。 服务器证书详细信息 如果已指定 SSL或TLS，向导将显示目录服务器返回的证书。 请确认颁发者、使用者和指纹适用于正确的目录服务器。找到强制性功能 连接器还会验证根 DSE 中是否存在必需的控件。 如果未列出这些控件，会显示警告。 某些 LDAP 目录不会列出根 DSE 中的所有功能，但即使出现警告，连接器也能正常运行。 支持的控件 “支持的控件”复选框控制特定操作的行为 增量导入 更改日志 DN 是增量更改日志使用的命名上下文，例如 cn=changelog。 必须指定此值才能执行增量导入。 密码属性 如果目录服务器支持其他密码属性或密码哈希，可以指定密码更改的目标。 分区名称 在其他分区列表中，可以添加其他未自动检测到的命名空间。 例如，如果有多个应同时一起导入的服务器构成了一个逻辑群集，则可以使用此设置。 就如同 Active Directory 可以在一个林中有多个域，而所有域都共享一个架构，在此框中输入其他命名空间就可以模拟此状况。 每个命名空间都可以从不同的服务器导入，可在“配置分区和层次结构”页上进一步配置。 在“分区”页上保留默认值，然后选择“下一步” 。
在“运行配置文件”页面上，确保同时选中“导出”复选框和“完全导入”复选框。 然后，选择“下一步”。
属性 说明 导出 将数据导出到 LDAP 目录服务器的运行配置文件。 此运行配置文件是必选的。 完全导入 将从前面指定的 LDAP 源导入所有数据的运行配置文件。 此运行配置文件是必选的。 增量导入 将仅导入自上次完整导入或增量导入后的 LDAP 更改的运行配置文件。 仅当确认目录服务器满足必需的要求时才启用此运行配置文件。 有关详细信息，请参阅常规 LDAP 连接器参考。 在“导出”页面上，保留默认值不变并单击“下一步”。
在“完全导入”页面上，保留默认值不变并单击“下一步”。
在“增量导入”页面上（如果存在）保留默认值不变并单击“下一步”。
填写“对象类型”页的文本框，选择“下一步”。
属性 说明 “目标对象” 该值是 LDAP 目录服务器中用户的结构对象类。 例如， inetOrgPerson（用于 OpenLDAP）或User（用于 AD LDS）。 不要在此字段中指定辅助对象类。 如果目录服务器需要辅助对象类，它们将使用 Azure 门户中的属性映射进行配置。定位点 此属性的值对于目标目录中的每个对象都应是唯一的。 Microsoft Entra 预配服务将在初始周期后使用此属性查询 ECMA 连接器主机。 对于 AD LDS，使用 ObjectGUID，对于其他目录服务器，请参见下表。 请注意，可以将可分辨名称选为-dn-。 多值属性（例如 OpenLDAP 架构中的uid属性）不能用作定位点。查询属性 此属性应与定位点相同，例如，如果 AD LDS 是目录服务器，则为 objectGUID；如果 OpenLDAP，则为_distinguishedName。DN 目标对象的可分辨名称。 保留 -dn-。自动生成 unchecked 下表列出了 LDAP 服务器和正在使用的定位点：
Directory 定位点 Microsoft AD LDS 和 AD GC objectGUID。 必须使用 1.1.846.0 或更高版本的代理才能将 ObjectGUID用作定位点。389 目录服务器 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 服务器 dn ECMA 主机会发现目标目录支持的属性。 可以选择要公开给 Microsoft Entra ID 的属性。 然后，可在 Azure 门户中配置这些属性以进行预配。 在“选择属性”页面上，在下拉列表中添加所有属性，一次添加一个，这些属性是强制属性或希望从 Microsoft Entra ID 预配的属性。
“属性”下拉列表显示在目标目录中发现的任何属性，以及在之前使用配置向导“选择属性”页面时未选择的任何属性。请确保取消选中
objectClass属性的Treat as single value复选框；如果设置了userPassword，userPassword属性应该处于不可选或已选中状态。如果将 OpenLDAP 和 inetOrgPerson 架构配合使用，请配置以下属性的可见性。
Attribute 视为单个值 cn Y mail Y objectClass sn Y userPassword Y 如果将 OpenLDAP 与 POSIX 架构配合使用，请配置以下属性的可见性。
Attribute 视为单个值 _distinguishedName -dn- export_password cn Y gidNumber homeDirectory mail Y objectClass sn Y uid Y uidNumber userPassword Y 添加所有相关属性后，选择“下一步”。
在“取消预配”页上，可以指定是否希望 Microsoft Entra ID 在用户超出应用程序范围时从目录中删除用户。 如果希望设置此操作，请在“禁用流”下选择“删除”，然后在“删除流”下选择“删除”。 如果选中了
Set attribute value，在前一页中选择的属性将无法在“取消预配”页中进行选择。
注意
如果选择设置属性值，请注意仅允许布尔值。
- 选择“完成”。
确保 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 浏览器窗口。
注意
如果窗口已超时，则需要重新选择代理。
- 登录 Azure 门户。
- 转到“企业应用程序”和“本地 ECMA 应用”应用程序 。
- 单击“预配”。
- 如果出现“开始”，则将模式更改为“自动”，在“本地连接”部分，选择刚刚部署的代理并选择“分配代理”，并等待 10 秒钟。 否则，请转到“编辑预配”。
在“管理员凭据”部分中，输入以下 URL。 将
connectorName替换为在 ECMA 主机中指定的连接器的名称，例如LDAP。 如果为 ECMA 主机提供了证书颁发机构提供的证书，请将localhost替换为安装了 ECMA 主机的服务器的主机名。属性 Value 租户 URL https://localhost:8585/ecma2host_connectorName/scim 输入你在创建连接器时定义的“机密令牌”值。
注意
如果你刚刚将代理分配到应用程序，请等待 10 分钟，以便完成注册。 在注册完成之前，连接性测试将无法正常工作。 通过在服务器上重新启动预配代理来强制完成代理注册，可以加快注册过程。 转到你的服务器，在 Windows 搜索栏中搜索“服务”，找到“Microsoft Entra Connect 预配代理服务”，右键单击该服务并重启。
单击“测试连接性”并等待一分钟。
连接测试成功并表明提供的凭据有权启用预配后，选择“保存”。
扩展 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 管理中心的“企业应用程序”下，选择“本地 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：
映射类型 源属性 目标属性 直接 displayNameurn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:displayName对于 OpenLDAP：
映射类型 源属性 目标属性 直接 displayNameurn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:cn直接 surnameurn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:sn直接 userPrincipalNameurn: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:uidNumberExpression Join("/", "/home", ToLower(Word([userPrincipalName], 1, "@"), ))urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:homeDirectory常量 10000urn: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、帐户名称和电子邮件地址。
例如，此命令在使用 AD LDS
csvde计划的 Windows 上将在当前文件系统目录中生成 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 -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选择与 Microsoft Entra ID 用户属性匹配的 users.csv 文件的列。
如果使用 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 中用户不匹配的映射和用户帐户。
如果选择用于在 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 中选择一个具有所需属性并将预配到应用程序的目录服务器的测试用户。
- 确保将要选择的用户具有将映射到目录服务器架构所需特性的所有属性。
- 在 Microsoft Azure AD 门户中，选择“企业应用程序”。
- 选择“本地 ECMA 应用”应用程序。
- 在左边的“管理”下，选择“用户和组” 。
- 选择“添加用户/组”。
- 在“用户”下，单击“未选择”。
- 在屏幕右侧选择一个用户，并选择“选择”按钮。
- 单击“分配”。
Test provisioning
属性已映射完毕并且已分配初始用户，接下来可通过一个用户测试按需预配。
在运行 Microsoft Entra ECMA 连接器主机的服务器上，选择“启动”。
在框中键入“run”，并输入“services.msc”。
在“服务”列表中，确保“Microsoft Entra Connect 预配代理”服务和“Microsoft ECMA2Host”服务都在运行。 否则，请选择“启动”。
在 Microsoft Azure AD 门户中，选择“企业应用程序”。
选择“本地 ECMA 应用”应用程序。
在左侧，选择“预配”。
选择“按需预配”。
搜索一个测试用户，选择“预配”。
几秒钟后，将出现消息“已在目标系统中成功创建用户”，其中包含用户属性列表。 如果出现错误，请参阅排查预配错误。
开始预配用户
按需预配测试成功后，添加剩余用户。
- 在 Azure 门户中，选择应用程序。
- 在左边的“管理”下，选择“用户和组” 。
- 确保所有用户都已分配给应用程序角色。
- 更改回预配配置页。
- 确保将范围设置为“仅限已分配的用户和组”，将预配状态设置为“开启”，并单击“保存”。
- 等待几分钟，以便系统开始预配。 该过程可能需要用时 40 分钟以上。 如下一部分所述完成预配作业后，
排除预配错误
如果显示错误，请选择“查看预配日志”。 在日志中查找状态为 Failure 的行，然后单击该行。
如果错误消息是“无法创建用户”，则根据目录架构的要求检查显示的属性。
有关详细信息，请切换到“故障排除和建议”选项卡。
如果故障排除错误消息中显示 objectClass 值为 invalid per syntax，请确保映射到 objectClass 属性的预配属性仅包含目录服务器识别的对象类的名称。
对于其他错误，请参阅排查本地应用程序预配问题。
如果要暂停对此应用程序的预配，可以在预配配置页上将预配状态更改为“关闭”，然后选择“保存”。 此操作将停止预配服务的运行。
检查用户是否已成功预配
等待一段时间后，检查目录服务器以确保正在预配用户。 对目录服务器执行的查询将取决于目录服务器提供的命令。
下面的说明演示了如何检查 AD LDS。
- 打开服务器管理器并选择左侧的 AD LDS。
- 右键单击你的 AD LDS 实例，然后从弹出框中选择“ldp.exe”。
- 在 ldp.exe 顶部，依次选择“连接”和“连接” 。
- 输入以下信息并单击“确定”。
- 服务器：APP3
- 端口：636
- 选中“SSL”框
- 在顶部的“连接”下，选择“绑定” 。
- 保留默认值并单击“确定”。
- 在顶部，依次选择“视图”和“树”
- 对于“基 DN”，请输入“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 预配的用户。