配置 Microsoft Entra ID 以将用户预配到用于 Linux 身份验证的 LDAP 目录中
以下文档是演示如何管理对 Linux 系统的访问的教程。 Microsoft Entra 将用户预配到受该 Linux 系统信任的本地 LDAP 目录中。 这样，用户就可以登录到依赖于该 LDAP 目录进行用户身份验证的 Linux 系统。 从 Microsoft Entra ID 中删除用户后，他们将无法再登录到 Linux 系统。
注意
本文中所述的方案仅适用于已依赖名称服务交换机（NSS）或可插入身份验证模块（PAM）LDAP 模块进行用户标识和身份验证的现有 Linux 系统。 Azure 或已启用 Azure Arc 的 Linux VM 应改为与 Microsoft Entra 身份验证集成。 现在，可以使用 Microsoft Entra ID 作为核心身份验证平台和证书颁发机构，通过使用 Microsoft Entra ID 和 OpenSSH 证书认证，通过 SSH 进入 Linux 虚拟机，如 使用 Microsoft Entra ID 和 OpenSSH登录到 Azure 中的 Linux 虚拟机中所述。
有关将用户预配到 LDAP 目录（而不是 Linux 身份验证）的其他方案，请参阅 配置 Microsoft Entra ID 以将用户预配到 LDAP 目录。
将用户预配到用于 Linux 身份验证的 LDAP 目录中的先决条件
本文假定 LDAP 服务器已存在于本地环境中，由一个或多个 Linux 或其他 POSIX 系统用于用户身份验证。
本地先决条件
- 使用 PAM 或 NSS 模块在目录服务器上答复的 Linux 或其他 POSIX 服务器。
- 支持 POSIX 架构（如 OpenLDAP）的 LDAP 目录服务器，可在其中创建、更新和删除用户。 有关支持的目录服务器的详细信息，请参阅 通用 LDAP 连接器参考。
- 至少具有 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。
- 可选：虽然不需要，但建议下载 适用于 Windows Server 的 Microsoft Edge 并将其替代 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 目录，并且必须已填充这些属性。 具体而言，每个用户必须具有唯一号码作为其用户 ID 号。 在部署预配代理并将用户分配到目录之前，需要从用户的现有属性生成该数字，或扩展 Microsoft Entra 架构。 然后，可以为范围内的用户设置该属性。 有关如何创建其他目录扩展，请参阅 Graph 扩展性。
更多建议和限制
以下要点列出了其他建议和限制。
- 不建议将同一代理用于云同步和本地应用预配。 Microsoft建议使用单独的代理进行云同步，另一个代理用于本地应用预配。
- 对于 AD LDS，目前无法使用密码配置用户。 因此，需要禁用 AD LDS 的密码策略，或者将用户预配为禁用状态。
- 对于其他目录服务器，可以设置初始随机密码，但无法将 Microsoft Entra 用户的密码预配到目录服务器。
- 不支持将用户从 LDAP 预配到 Microsoft Entra ID。
- 不支持将组和用户成员配置到目录服务器中。
确定 Microsoft Entra LDAP 连接器如何与目录服务器交互
将连接器部署到现有目录服务器之前，需要与组织中的目录服务器操作员讨论如何与其目录服务器集成。 要收集的信息包括：
- 连接目录服务器所需的网络信息。
- 连接器应如何向目录服务器进行身份验证。
- 目录服务器已选择哪些架构来为用户建模。
- 命名上下文的基础可分辨名称及目录层次规则。
- 如何将目录服务器中的用户与 Microsoft Entra ID 中的用户相关联。
- 当用户在 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 ID 中超出范围时的取消预配行为 | 配置向导中的“取消预配”页 | 从目录服务器中删除用户 |
目录服务器的网络地址是主机名和 TCP 端口号，通常是端口 389 或 636。 除了目录服务器与同一 Windows Server 上的连接器并置，或者你使用的是网络级别安全性，否则从连接器到目录服务器的网络连接需要使用 SSL 或 TLS 进行保护。 连接器支持连接到端口389上的目录服务器，并使用StartTLS在会话中启用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 用户的属性更改预配到目录中，无论是针对目录中已有的用户还是新用户，当 Microsoft Entra ID 中的用户与目录中的用户相互关联时。
如果在 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 管理员提供凭据。 用户必须至少具有混合标识管理员角色。
- 选择 确认 以确认设置。 安装成功后，可以选择 退出，并关闭预配代理包安装程序。
配置本地 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 端口号。 如果目录服务器配置为通过 SSL 进行 LDAP，请使用端口 636。 对于 Start TLS，或者如果使用网络级安全性，请使用端口 389。连接超时值 180 绑定 此属性指定连接器如何向目录服务器进行身份验证。 在使用 Basic设置，或使用SSL或TLS设置且未配置客户端证书的情况下，连接器会发送一个 LDAP 简单绑定，以通过可分辨名称和密码进行身份验证。 指定SSL或TLS设置和客户端证书后，连接器会发送 LDAP SASLEXTERNAL绑定以使用客户端证书进行身份验证。用户名 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复选框。 启用此选项允许在所有对象上使用每个属性。 选择此选项会使架构非常大，因此除非连接目录正在使用此功能，否则建议将选项保持未选中状态。允许手动定位点选择 保持未选中状态。 注意
如果在尝试连接时遇到问题，且无法继续访问“全局”页，请确保目录服务器中的服务帐户已启用。
在“全局”页面上，将配置增量更改日志的可分辨名称（如果需要）和其他 LDAP 功能。 该页已预先填充 LDAP 服务器提供的信息。 查看显示的值，然后选择“下一步”。
财产 描述 受支持的 SASL 机制 顶部部分显示服务器本身提供的信息，包括 SASL 机制列表。 服务器证书详细信息 如果指定了 SSL或TLS，向导将显示目录服务器返回的证书。 确认颁发者、主题和指纹适用于正确的目录服务器。找到强制性功能 连接器还会验证根 DSE 中是否存在强制控制措施。 如果未列出这些控件，则会显示警告。 某些 LDAP 目录不会列出根 DSE 中的所有特性，即便出现警告，连接器仍然可以正常工作。 支持的控件 “支持的控件”复选框控制特定操作的行为 增量导入 更改日志 DN 是增量更改日志使用的命名上下文，例如 cn=changelog。 必须指定此值才能执行增量导入。 如果不需要实现增量导入，则此字段可以为空。 密码属性 如果目录服务器支持不同的密码属性或密码哈希，则可以指定密码更改的目标。 分区名称 在其他分区列表中，可以添加未自动检测到的其他命名空间。 例如，如果多个服务器组成逻辑群集，则应同时导入此设置。 就如同 Active Directory 可以在一个林中有多个域，而所有域都共享一个架构，在此框中输入其他命名空间就可以模拟此状况。 每个命名空间都可以从不同的服务器导入，并在 配置分区和层次结构 页上进行进一步配置。 在“分区”页上保留默认值，然后选择“下一步”。
在“运行配置文件”页面上，确保同时选中“导出”复选框和“完全导入”复选框。 然后选择 下一步。
财产 描述 出口 运行配置文件，将数据导出到 LDAP 目录服务器。 此运行配置文件是必选的。 完整导入 运行配置文件，从前面指定的 LDAP 源导入所有数据。 此运行配置文件是必选的。 增量导入 运行配置，仅从 LDAP 导入自上次完整或增量导入以来的更改。 仅当已确认目录服务器满足必要要求时，才启用此运行配置。 有关详细信息，请参阅 泛型 LDAP 连接器参考。 在“导出”页上，保留默认值不变，然后选择 “下一步”。
在 完全导入 页上，保留默认值不变，然后选择 “下一步”。
在 DeltaImport 页上，如果存在，请保留默认值不变，然后选择 下一步。
在“对象类型”页上，填写文本框，然后选择“下一步”。
财产 描述 目标对象 此值是 LDAP 目录服务器中用户的结构对象类。 使用 inetOrgPerson，并且不在此字段中指定辅助对象类。 如果目录服务器需要辅助对象类，则会在 Azure 门户中使用属性映射来配置它们。锚 此属性的值对于目标目录中的每个对象应是唯一的。 Microsoft Entra 预配服务在初始周期后使用此属性查询 ECMA 连接器主机。 通常使用特定命名，可能选择为 -dn-。 多值属性（如 OpenLDAP 架构中的uid属性）不能用作定位点。查询属性 此属性应与定位点相同。 DN 目标对象的可分辨名称。 保留 -dn-。自动生成 unchecked ECMA 主机可发现目标目录支持的属性。 您可以选择要向Microsoft Entra ID公开哪些属性。 然后，可以在 Azure 门户中配置这些属性进行预配。 在“选择属性”页面上，在下拉列表中添加所有属性，一次添加一个，这些属性是强制属性或希望从 Microsoft Entra ID 预配的属性。
“属性 下拉列表显示目标目录中发现的任何属性，在上一次使用配置向导 ”选择属性“ 页上未选择。请确保取消选中
objectClass属性的Treat as single value复选框；如果设置了userPassword，userPassword属性应该处于不可选或已选中状态。配置以下属性的可见性。
Attribute 视为单个值 _distinguishedName（区别名） -dn- 导出密码 cn Y gidNumber homeDirectory mail Y objectClass sn Y uid Y uidNumber 用户密码 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 主机的服务器主机名。财产 值 租户 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 的属性列表”以重新加载页面。 看到列出的属性后，请从此页面取消以返回到映射列表。 目录中的每个用户必须具有唯一的可分辨名称。 可以使用属性映射指定连接器应如何构造专有名称。 选择“添加新映射”。 使用以下值创建映射，更改表达式中的可分辨名称以匹配目标目录中的组织单位或其他容器。
- 映射类型：表达式
- 表达式：
Join("", "CN=", Word([userPrincipalName], 1, "@"), ",DC=Contoso,DC=lab") - 目标属性：
urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:-dn- - 应用此映射：仅在创建对象期间
如果目录服务器要求在
objectClass属性中提供多个结构对象类值或辅助对象类值，则需要为该属性添加一个映射。 若要为objectClass添加映射，请选择“添加新映射。 使用以下值创建映射，更改表达式中的对象类名称以匹配目标目录架构的名称。- 映射类型：表达式
- 如果要预配到 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。映射类型 源属性 目标属性 直接 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表达式 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恒定 10000urn: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 用于租户。 后续交互可以使用较低特权角色，例如：
- 用户管理员（如果预计会创建新用户）。
- 应用程序管理员或标识治理管理员（如果只是管理应用程序角色分配）。
打开 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 ID 匹配的用户的属性。 这些属性的示例包括员工 ID、帐户名或
uid和电子邮件地址。如果需要，请将包含用户列表的 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 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选择与 Microsoft Entra ID 用户属性匹配的 users.csv 文件的列。
** 如果您使用 SAP Cloud Identity Services，那么默认的映射是 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 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 云标识服务、数据库或目录中是否存在任何用户由于错误或缺少匹配项而无法在 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 Cloud Identity Services、数据库或目录中更新其访问权限或其属性，则需要更新应用程序、匹配规则或更新或为其创建 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 Cloud Identity Services、数据库或目录中但未与 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 ID 中的应用程序
现在，既然 Microsoft Entra ECMA 连接器主机已与 Microsoft Entra ID 建立通信，并且已配置了属性映射，您就可以继续配置哪些人员在预配范围内。
重要
如果您是使用“混合标识管理员”角色登录的，需要登出，然后使用至少具有“应用程序管理员”角色的帐户重新登录以访问此部分。 混合标识管理员角色无权将用户分配到应用程序。
如果 LDAP 目录中存在现有用户，则应为这些现有用户创建应用程序角色分配。 若要详细了解如何使用 New-MgServicePrincipalAppRoleAssignedTo批量创建应用程序角色分配，请参阅 管理Microsoft Entra ID中的应用程序现有用户。
如果不想更新 LDAP 目录中的现有用户，则从具有所需属性的 Microsoft Entra ID 中选择一个测试用户，并将其同步到目录服务器。
- 确保用户将要选择的对象具有所有属性，这些属性将被映射到目录服务器架构的必需属性中。
- 在 Azure 门户中，选择 企业应用程序。
- 选择“本地 ECMA 应用”应用程序。
- 在左边的“管理”下，选择“用户和组”。
- 选择“添加用户/组”。
显示添加用户的
- 在“用户”下，单击“未选择”。
- 从右侧选择用户，然后选择 选择 按钮。
- 单击“分配”。
测试配置
既然已完成属性映射并分配了初始用户，您可以使用其中一个用户测试按需预配功能。
在运行 Microsoft Entra ECMA 连接器主机的服务器上，选择“启动”。
输入 运行 并在框中输入 services.msc。
在 服务 列表中，确保 Microsoft Entra Connect 预配代理 服务和 Microsoft ECMA2Host 服务正在运行。 否则，请选择“启动”。
在 Azure 门户中，选择 企业应用程序。
选择“本地 ECMA 应用”应用程序。
在左侧，选择“预配”。
选择“按需预配”。
搜索一个测试用户，选择“预配”。
几秒钟后，将显示消息 成功在目标系统中创建用户，包含用户属性列表。 如果出现错误，请参阅排查预配错误。
开始预配用户
测试按需预配成功后，添加其余用户。 若要详细了解如何使用 New-MgServicePrincipalAppRoleAssignedTo批量创建应用程序角色分配，请参阅 管理Microsoft Entra ID中的应用程序现有用户。
- 在 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 应用程序。