通过

配置 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 VM,如 使用 Microsoft Entra ID 和 OpenSSH 登录到 Azure 中的 Linux 虚拟机中所述。

有关将用户预配到 LDAP 目录(而不是 Linux 身份验证)的其他方案,请参阅 配置 Microsoft Entra ID 以将用户预配到 LDAP 目录中

将用户预配到用于 Linux 身份验证的 LDAP 目录中的先决条件

本文假定 LDAP 服务器已存在于本地环境中,由一个或多个 Linux 或其他 POSIX 系统用于用户身份验证。

此图显示了从 Microsoft Entra ID 到 LDAP 目录服务器的本地预配的体系结构。

本地部署先决条件

  • 使用 PAM 或 NSS 模块在目录服务器上答复的 Linux 或其他 POSIX 服务器。
  • 支持 POSIX 架构(如 OpenLDAP)的 LDAP 目录服务器,可在其中创建、更新和删除用户。 有关支持的目录服务器的详细信息,请参阅 通用 LDAP 连接器参考
  • 具有至少 3 GB RAM 的计算机,用于托管预配代理。 计算机应具有 Windows Server 2016 或更高版本的 Windows Server。 它还应连接到目标目录服务器,并建立到 login.partner.microsoftonline.cn、 其他Microsoft Online ServicesAzure 域的出站连接。 例如,托管在 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 门户 配置 页属性映射 posixAccountshadowAccount
要在新用户上填充的属性 配置向导“选择属性”页和 Azure 门户“预配”页的属性映射 cngidNumberhomeDirectorymailobjectClasssnuiduidNumberuserPassword
目录服务器所需的命名层次结构 Azure 门户 配置 页属性映射 将新创建用户的 DN 设置为位于 DC=Contoso,DC=lab 之下
用于在 Microsoft Entra ID 与目录服务器之间关联用户的属性 Azure 门户 配置 页属性映射 mail
当用户不再在 Microsoft Entra ID 范围内时的取消授权行为 配置向导 取消预配 从目录服务器中删除用户

目录服务器的网络地址是主机名和 TCP 端口号,通常是端口 389 或 636。 除了目录服务器与同一 Windows Server 上的连接器并置,或者你使用的是网络级别安全性,否则从连接器到目录服务器的网络连接需要使用 SSL 或 TLS 进行保护。 连接器支持连接到端口 389 上的目录服务器,并使用“启动 TLS”在会话中启用 TLS。 该连接器还支持通过 LDAPS(LDAP over TLS)协议连接到端口 636 上的目录服务器。

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

目录架构指定表示目录中实际实体的对象类和属性。 连接器支持使用结构对象类(例如 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 中的用户通常不存在该可分辨名称。 相反,组织可能在其目录服务器架构中具有不同的属性,例如 mailemployeeId,这些属性也存在于其使用 Microsoft Entra ID 的用户中。 然后,当连接器将新用户预配到目录服务器时,连接器可以检查是否已经存在具有该属性特定值的用户。如果该用户不存在,则只在目录服务器中创建一个新用户。

如果你的方案涉及在 LDAP 目录中创建新用户,而不仅仅是更新或删除现有用户,则还需要确定使用该目录服务器处理身份验证的 Linux 系统的方式。 某些系统可以从目录中查询用户的 SSH 公钥或证书,这在用户已经持有这类凭据时可能是合适的。 但是,如果依赖于目录服务器的应用程序不支持新式身份验证协议或更强凭据,则需要在目录中创建新用户时设置特定于应用程序的密码,因为 Microsoft Entra ID 不支持预配用户的 Microsoft Entra 密码。

最后,需要就取消预配行为达成一致。 配置连接器后,Microsoft Entra ID 可以在 Microsoft Entra ID 用户与目录中的用户之间建立链接,无论是对于目录中已有的用户还是新用户,Microsoft Entra ID 都可以将属性更改从 Entra 用户预配到目录中。

如果在 Microsoft Entra ID 中删除了分配给应用程序的用户,Microsoft Entra ID 会将删除操作发送到目录服务器。 如果用户超出使用应用程序的范围,你可能还希望Microsoft Entra ID 更新目录服务器中的对象。 此行为取决于将使用目录服务器的应用程序,因为许多目录(如 OpenLDAP)可能没有默认的方式来指示用户帐户被停用。

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

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

选择“自动”选项的屏幕截图。

  1. 在“本地连接”下,选择“下载并安装”,然后选择“接受条款并下载”

代理下载位置的屏幕截图。

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

配置本地 ECMA 应用

  1. 返回到门户,在“本地连接”部分,选择已部署的代理,然后单击“分配代理”。

    显示如何选择并分配代理的屏幕截图。

  2. 在使用配置向导完成下一步配置时,请保持此浏览器窗口为打开状态。

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

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

注释

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

配置通用 LDAP 连接器

根据你选择的选项,一些向导屏幕可能不会出现,并且信息可能略有不同。 请使用以下信息来指导你完成配置。

  1. 生成用于向连接器进行身份验证Microsoft Entra ID 的机密令牌。 它至少应为 12 个字符,并且对于每个应用程序都是唯一的。 如果还没有机密生成器,可以使用 PowerShell 命令来生成示例随机字符串。

    -join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_})
    
  2. 如果尚未执行此操作,请从“开始”菜单启动Microsoft ECMA2Host 配置向导。

  3. 选择“新建连接器”。 显示选择“新建连接器”的屏幕截图。

  4. 在“属性”页的文本框中填入图片下表格中的数值,选择“下一步”。 显示输入属性的屏幕截图。

    财产 价值
    名称 为连接器选择的名称,它在环境中的所有连接器中应是唯一的。 例如,LDAP
    自动同步计时器(分钟) 120
    机密令牌 在此处输入机密令牌。 它应至少为 12 个字符。
    扩展 DLL 对于通用 LDAP 连接器,请选择 Microsoft.IAM.Connector.GenericLdap.dll
  5. “连接 ”页上,将配置 ECMA 连接器主机与目录服务器通信的方式,并设置一些配置选项。 在文本框中填写图片下方的表中指定的值,然后选择“下一步”。 选择 “下一步”时,连接器会查询目录服务器的配置。 显示“连接”页的屏幕截图。

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

    注释

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

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

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

  8. “运行配置文件 ”页上,确保选中“ 导出 ”复选框和 “完全导入 ”复选框。 然后选择下一步 显示“运行配置文件”页的屏幕截图。

    财产 说明
    Export 运行配置文件,将数据导出到 LDAP 目录服务器。 此运行配置文件是必选的。
    完全导入 运行配置文件,从前面指定的 LDAP 源导入所有数据。 此运行配置文件是必选的。
    增量导入 运行仅从 LDAP 导入自上次完整导入或增量导入以来的更改的配置文件。 仅当已确认目录服务器满足必要要求时,才启用此运行配置文件。 有关详细信息,请参阅 通用 LDAP 连接器参考
  9. “导出 ”页上,保留默认值不变,然后选择“ 下一步”。

  10. “完全导入 ”页上,保留默认值不变,然后选择“ 下一步”。

  11. DeltaImport 页上,如果存在,则保留默认值不变,然后选择“ 下一步”。

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

    财产 说明
    “目标对象” 此值是 LDAP 目录服务器中用户的结构对象类。 使用此 inetOrgPerson字段,但不在此字段中指定辅助对象类。 如果目录服务器需要辅助对象类,则会在 Azure 门户中使用属性映射来配置它们。
    锚点 此属性的值对于目标目录中的每个对象应是唯一的。 Microsoft Entra 预配服务在初始周期后使用此属性查询 ECMA 连接器主机。 通常使用专有名称,可指定为 -dn-。 多值属性(如 uid OpenLDAP 架构中的属性)不能用作定位点。
    查询属性 此属性应与定位点相同。
    DN 目标对象的“distinguishedName”。 保留 -dn-
    自动生成 不受控制的
  13. ECMA 主机可发现目标目录支持的属性。 可以选择要公开给 Microsoft Entra ID 的属性。 然后,可在 Azure 门户中配置这些属性以进行预配。 在 “选择属性” 页上,从下拉列表中一个一个地添加所有属性,作为必选属性或用于从 Microsoft Entra ID 进行配置。 显示“选择属性”页的屏幕截图。
    “属性”下拉列表显示在目标目录中发现的任何属性,但在之前使用配置向导“选择属性”页上选择该属性。

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

    配置以下属性的可见性。

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

    添加所有相关属性后,选择“下一步”。

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

注释

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

  1. 选择完成

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

按照以下步骤确认连接器主机已启动,并已识别目录服务器中的任何现有用户。

  1. 在运行 Microsoft Entra ECMA 连接器主机的服务器上,选择“启动”。
  2. 根据需要选择 “运行 ”,然后在框中输入 services.msc
  3. 在“服务”列表,确保“Microsoft ECMA2Host”存在且正在运行。 如果未运行,请选择启动 显示服务正在运行的屏幕截图。
  4. 如果最近启动了该服务,并且目录服务器中有许多用户对象,请等待几分钟,使连接器与目录服务器建立连接。
  5. 在运行 Microsoft Entra ECMA 连接器主机的服务器上,启动 PowerShell。
  6. 更改为安装了 ECMA 主机的文件夹,例如 C:\Program Files\Microsoft ECMA2Host
  7. 更改为子目录 Troubleshooting
  8. 按所示在该目录中运行脚本 TestECMA2HostConnection.ps1 ,并提供连接器名称和 ObjectTypePathcache作为参数。 如果连接器主机未侦听 TCP 端口 8585,则可能还需要提供 -Port 参数。 出现提示时,键入为该连接器配置的机密令牌。
    PS C:\Program Files\Microsoft ECMA2Host\Troubleshooting> $cout = .\TestECMA2HostConnection.ps1 -ConnectorName LDAP -ObjectTypePath cache; $cout.length -gt 9
    Supply values for the following parameters:
    SecretToken: ************
    
  9. 如果脚本显示错误或警告消息,请检查服务正在运行,连接器名称和机密令牌与配置向导中配置的这些值匹配。
  10. 如果脚本显示输出 False,则连接器未看到现有用户的源目录服务器中的任何条目。 如果这是一个新的目录服务器安装,则此行为是预期的,你可以在下一部分继续。
  11. 但是,如果目录服务器已包含一个或多个用户,但显示 False脚本,则此状态表示连接器无法从目录服务器读取。 如果尝试预配,则Microsoft Entra ID 可能无法将该源目录中的用户与 Microsoft Entra ID 中的用户正确匹配。 等待几分钟,连接器主机完成从现有目录服务器读取对象,然后重新运行脚本。 如果输出继续 False,请检查连接器的配置以及目录服务器中的权限是否允许连接器读取现有用户。

测试从 Microsoft Entra ID 到连接器主机的连接

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

    注释

    如果窗口已超时,则需要重新选择代理。

    1. 登录到 Azure 门户。
    2. 转到“企业应用程序”和“本地 ECMA 应用”应用程序 。
    3. 选择“预配”
    4. 如果出现 “开始” ,请将模式更改为 “自动”,在“ 本地连接 ”部分中,选择刚刚部署的代理,然后选择“ 分配代理”,然后等待 10 分钟。 否则,请转到“编辑预配”。
  2. 在“管理员凭据”部分中,输入以下 URL。 将 connectorName 部分替换为 ECMA 主机上的连接器名称,例如 LDAP。 如果您为 ECMA 主机提供了来自证书颁发机构的证书,请将 localhost 替换为安装了 ECMA 主机的服务器的主机名。

    财产 价值
    租户 URL https://localhost:8585/ecma2host_connectorName/scim
  3. 输入你在创建连接器时定义的“机密令牌”值。

    注释

    如果你刚刚将代理分配到应用程序,请等待 10 分钟,以便完成注册。 在注册完成之前,连接性测试将无法正常工作。 通过在服务器上重新启动预配代理来强制完成代理注册,可以加快注册过程。 转到服务器,在 Windows 搜索栏中搜索 服务 ,标识 Microsoft Entra Connect 预配代理 服务,右键单击该服务,然后重启。

  4. 单击“测试连接性”并等待一分钟。

  5. 连接测试成功并显示提供的凭据有权启用供应后,请选择“保存”。
    显示测试代理的屏幕截图。

扩展 Microsoft Entra 架构

如果你的目录服务器需要不属于用户默认 Microsoft Entra 架构的附加属性,则在预配时,你可以配置为提供这些属性的值来自常量、由其他 Microsoft Entra 属性转换而来的表达式,或通过扩展 Microsoft Entra 架构来实现。

如果目录服务器要求用户具有属性(例如 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 用户属性将通过连接器发送到目录服务器,作为该新对象的一部分。

  1. 在Microsoft Entra 管理中心的 Enterprise 应用程序下,选择 本地 ECMA 应用 应用程序,然后选择 “预配 ”页。

  2. 选择 “编辑预配”。

  3. 展开“映射”,然后选择“预配 Microsoft Entra 用户”。 如果这是你第一次为此应用程序配置属性映射,则只有一个映射作为占位符存在。

  4. 若要确认目录服务器的架构在 Microsoft Entra ID 中可用,请选择“ 显示高级选项 ”复选框,然后选择 “编辑 ScimOnPremises”属性列表。 确保列出配置向导中选择的所有属性。 否则,请等待几分钟来刷新架构,然后在导航行中选择 “属性映射 ”,然后再次 选择“编辑 ScimOnPremises”属性列表 以重新加载页面。 看到属性列出后,从此页面取消以返回到映射列表。

  5. 目录中的每个用户必须具有唯一的可分辨名称。 可以通过属性映射指定连接器应如何构造可分辨名称。 选择“ 添加新映射”。 使用以下值创建映射,更改表达式中的可分辨名称以匹配目标目录中的组织单位或其他容器。

    • 映射类型:表达式
    • 表达式:Join("", "CN=", Word([userPrincipalName], 1, "@"), ",DC=Contoso,DC=lab")
    • 目标属性: urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:-dn-
    • 应用此映射:仅在创建对象期间
  6. 如果目录服务器要求在 objectClass 属性中提供多个结构对象类值或辅助手段类值,则将映射添加到该属性。 若要添加 objectClass映射,请选择“ 添加新映射”。 使用以下值创建映射,更改表达式中的对象类名称以匹配目标目录架构的名称。

    • 映射类型:表达式
    • 表达式(如果预配 POSIX 架构): Split("inetOrgPerson,posixAccount,shadowAccount",",")
    • 目标属性: urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:objectClass
    • 应用此映射:仅在创建对象期间
  7. 对于目录服务器下表中的每个映射,请选择“ 添加新映射”,并指定源和目标属性。 如果要将现有用户预配到现有目录中,则需要编辑共有属性的映射,以便设置此属性为匹配对象使用的属性在此处了解有关属性映射的详细信息。

    对于具有 POSIX 架构的 OpenLDAP,还需要提供gidNumberhomeDirectoryuiduidNumber属性。 每个用户都需要一个唯一的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
  8. 添加一个映射, urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPassword 用于为用户设置初始随机密码。

  9. 选择“保存”

确保被预配到目录的用户已经具备所需的属性。

如果 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 cmdlet 自动检查用户具有所有必需的属性。

例如,假设预配需要用户具有三个属性 DisplayNamesurname 并且 extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty。 此第三个属性用于包含uidNumber。 可以使用 Get-MgUser cmdlet 检索每个用户,并检查是否存在所需的属性。 请注意,Graph v1.0 Get-MgUser cmdlet 默认情况下不会返回任何用户的目录扩展属性,除非在请求中指定属性作为要返回的属性之一。

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

组织首次将这些命令行小程序用于此方案时,您需要拥有全局管理员角色,以便允许在您的租户中使用 Microsoft Graph PowerShell。 后续交互可以使用一个较低特权的角色,例如:

  • 用户管理员(如果预计会创建新用户)。
  • 在您仅负责管理应用程序角色分配的情况下,可以是应用程序管理员或 标识治理管理员
  1. 打开 PowerShell。

  2. 如果没有已安装 Microsoft Graph PowerShell 模块 ,请使用以下命令安装 Microsoft.Graph.Users 模块和其他模块:

    Install-Module Microsoft.Graph
    

    如果已安装模块,请确保使用的是最新版本:

    Update-Module microsoft.graph.users,microsoft.graph.identity.governance,microsoft.graph.applications
    
  3. 连接到 Microsoft Entra ID:

    $msg = Connect-MgGraph -Environment China -ClientId 'YOUR_CLIENT_ID' -TenantId 'YOUR_TENANT_ID' -ContextScope Process -Scopes "User.Read.All,Application.ReadWrite.All,AppRoleAssignment.ReadWrite.All,EntitlementManagement.ReadWrite.All"
    
  4. 构造用户列表和要检查的属性。

    $userPrincipalNames = (
     "alice@contoso.com",
     "bob@contoso.com",
     "carol@contoso.com" )
    
    $requiredBaseAttributes = ("DisplayName","surname")
    $requiredExtensionAttributes = ("extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty")
    
  5. 查询每个用户的目录。

    $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 目录收集现有用户

  1. 确定该目录中哪些用户属于具有 Linux 身份验证的用户的范围。 此选项将取决于 Linux 系统的配置。 对于某些配置,LDAP 目录中存在的任何用户都是有效的用户。 其他配置可能要求用户具有特定属性或成为该目录中组的成员。

  2. 运行一个命令,用于从 LDAP 目录中检索该用户子集到 CSV 文件中。 确保输出包含用于与 Microsoft Entra ID 匹配的用户的属性。 这些属性的示例包括员工 ID、帐户名或 uid电子邮件地址。

  3. 如果需要,请将包含用户列表的 CSV 文件传输到安装了 Microsoft Graph PowerShell cmdlet 的系统。

  4. 现在,你已获得目录中所有用户的列表,你将将目录中的这些用户与Microsoft Entra ID 中的用户匹配。 在继续操作之前,请查看有关匹配源系统和目标系统中的用户的信息。

检索 Microsoft Entra ID 中用户的 ID

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

当您的组织首次将这些 cmdlet 用于此方案时,需要您以全局管理员角色身份登录,以便在贵组织的租户中使用 Microsoft Graph PowerShell。 后续交互可以使用较低特权角色,例如:

  • 用户管理员(如果预计会创建新用户)。
  • 在您仅负责管理应用程序角色分配的情况下,可以是应用程序管理员或 标识治理管理员
  1. 打开 PowerShell。

  2. 如果没有已安装 Microsoft Graph PowerShell 模块 ,请使用以下命令安装 Microsoft.Graph.Users 模块和其他模块:

    Install-Module Microsoft.Graph
    

    如果已安装模块,请确保使用的是最新版本:

    Update-Module microsoft.graph.users,microsoft.graph.identity.governance,microsoft.graph.applications
    
  3. 连接到 Microsoft Entra ID:

    $msg = Connect-MgGraph -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"
    
  4. 如果这是你第一次使用此命令,则可能需要同意允许 Microsoft Graph 命令行工具具有这些权限。

  5. 将从应用程序数据存储中获取的用户列表读取到 PowerShell 会话中。 如果用户列表位于 CSV 文件中,则可以使用 PowerShell cmdlet Import-Csv,并将上一部分中的文件的名称作为参数提供。

    例如,如果将从 SAP 云标识服务获取的文件命名为 Users-exported-from-sap.csv 并位于当前目录中,则输入此命令。

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

    另举一例,如果使用了数据库或目录,并将该文件命名为 users.csv 且位于当前目录中,则输入以下命令:

    $filename = ".\users.csv"
    $dbusers = Import-Csv -Path $filename -Encoding UTF8
    
  6. 选择 users.csv 文件中与 Microsoft Entra ID 用户属性匹配的列。

    如果使用 SAP 云标识服务,则默认映射是 SAP SCIM 属性 userName 与 Microsoft Entra ID 属性 userPrincipalName

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

    另举一例,如果使用了数据库或目录,则在你拥有用户的数据库中,名为 EMail 的列中的值将与 Microsoft Entra 属性 userPrincipalName 中的值相同:

    $db_match_column_name = "EMail"
    $azuread_match_attr_name = "userPrincipalName"
    
  7. 检索 Microsoft Entra ID 中的这些用户的 ID。

    以下 PowerShell 脚本使用前面指定的 $dbusers$db_match_column_name$azuread_match_attr_name 值。 它会查询 Microsoft Entra ID 以查找属性具有源文件中每个记录的匹配值的用户。 如果从源 SAP 云标识服务、数据库或目录获取的文件中存在许多用户,则可能需要几分钟时间才能完成此脚本。 如果在 Microsoft Entra ID 中没有具有该值的属性,并且需要使用 contains 或其他筛选表达式,则需要在下面的步骤 11 中自定义此脚本和该内容,以使用其他筛选表达式。

    $dbu_not_queried_list = @()
    $dbu_not_matched_list = @()
    $dbu_match_ambiguous_list = @()
    $dbu_query_failed_list = @()
    $azuread_match_id_list = @()
    $azuread_not_enabled_list = @()
    $dbu_values = @()
    $dbu_duplicate_list = @()
    
    foreach ($dbu in $dbusers) { 
       if ($null -ne $dbu.$db_match_column_name -and $dbu.$db_match_column_name.Length -gt 0) { 
          $val = $dbu.$db_match_column_name
          $escval = $val -replace "'","''"
          if ($dbu_values -contains $escval) { $dbu_duplicate_list += $dbu; continue } else { $dbu_values += $escval }
          $filter = $azuread_match_attr_name + " eq '" + $escval + "'"
          try {
             $ul = @(Get-MgUser -Filter $filter -All -Property Id,accountEnabled -ErrorAction Stop)
             if ($ul.length -eq 0) { $dbu_not_matched_list += $dbu; } elseif ($ul.length -gt 1) {$dbu_match_ambiguous_list += $dbu } else {
                $id = $ul[0].id; 
                $azuread_match_id_list += $id;
                if ($ul[0].accountEnabled -eq $false) {$azuread_not_enabled_list += $id }
             } 
          } catch { $dbu_query_failed_list += $dbu } 
        } else { $dbu_not_queried_list += $dbu }
    }
    
    
  8. 查看以前查询的结果。 请查看 SAP 云标识服务、数据库或目录中是否存在任何用户由于错误或缺少匹配项而无法在 Microsoft Entra ID 中找到。

    以下 PowerShell 脚本将显示未找到的记录计数:

    $dbu_not_queried_count = $dbu_not_queried_list.Count
    if ($dbu_not_queried_count -ne 0) {
      Write-Error "Unable to query for $dbu_not_queried_count records as rows lacked values for $db_match_column_name."
    }
    $dbu_duplicate_count = $dbu_duplicate_list.Count
    if ($dbu_duplicate_count -ne 0) {
      Write-Error "Unable to locate Microsoft Entra ID users for $dbu_duplicate_count rows as multiple rows have the same value"
    }
    $dbu_not_matched_count = $dbu_not_matched_list.Count
    if ($dbu_not_matched_count -ne 0) {
      Write-Error "Unable to locate $dbu_not_matched_count records in Microsoft Entra ID by querying for $db_match_column_name values in $azuread_match_attr_name."
    }
    $dbu_match_ambiguous_count = $dbu_match_ambiguous_list.Count
    if ($dbu_match_ambiguous_count -ne 0) {
      Write-Error "Unable to locate $dbu_match_ambiguous_count records in Microsoft Entra ID as attribute match ambiguous."
    }
    $dbu_query_failed_count = $dbu_query_failed_list.Count
    if ($dbu_query_failed_count -ne 0) {
      Write-Error "Unable to locate $dbu_query_failed_count records in Microsoft Entra ID as queries returned errors."
    }
    $azuread_not_enabled_count = $azuread_not_enabled_list.Count
    if ($azuread_not_enabled_count -ne 0) {
     Write-Error "$azuread_not_enabled_count users in Microsoft Entra ID are blocked from sign-in."
    }
    if ($dbu_not_queried_count -ne 0 -or $dbu_duplicate_count -ne 0 -or $dbu_not_matched_count -ne 0 -or $dbu_match_ambiguous_count -ne 0 -or $dbu_query_failed_count -ne 0 -or $azuread_not_enabled_count) {
     Write-Output "You will need to resolve those issues before access of all existing users can be reviewed."
    }
    $azuread_match_count = $azuread_match_id_list.Count
    Write-Output "Users corresponding to $azuread_match_count records were located in Microsoft Entra ID." 
    
  9. 脚本完成以后,如果数据源中有任何记录在 Microsoft Entra ID 中无法找到,系统会提示错误。 如果无法在 Microsoft Entra ID 中找到应用程序数据存储中的所有用户记录,您需要调查哪些记录未匹配,以及为什么没有匹配。

    例如,某人在 Microsoft Entra ID 中的电子邮件地址和 userPrincipalName 可能已更改,但在应用程序的数据源中未更新其相应的 mail 属性。 或者,用户可能已经离开了组织,但仍处于应用程序的数据源中。 或者,应用程序数据源中可能有一个供应商或超级管理员帐户,该帐户与 Microsoft Entra ID 中的任何特定人员都不对应。

  10. 如果存在无法在 Microsoft Entra ID 中找到的用户,或有用户未处于活动状态并且能够登录,但你想要审查其权限或在 SAP 云标识服务、数据库或目录中更新其属性,则需要更新应用程序、匹配规则,或为其更新或创建 Microsoft Entra 用户。

    如果选择用于在 Microsoft Entra ID 中创建用户的选项,则可以使用以下任一方法批量创建用户:

    确保使用 Microsoft Entra ID 所需的属性填充这些新用户,以便稍后将其与应用程序中的现有用户以及 Microsoft Entra ID 所需的属性(包括 userPrincipalNamemailNicknamedisplayName)匹配。 userPrincipalName 对于目录中的所有用户必须是唯一的。

    例如,数据库中可能有用户,其中,EMail 列中的值是要用作 Microsoft Entra 用户主体名称的值,Alias 列中的值包含 Microsoft Entra ID 邮件别名,Full name 列中的值包含用户的显示名称:

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

    然后,可以使用此脚本为 SAP 云标识服务、数据库或目录中与 Microsoft Entra ID 用户不匹配的用户创建 Microsoft Entra 用户。 请注意,可能需要修改此脚本以添加组织中所需的其他 Microsoft Entra 属性,或者如果 $azuread_match_attr_name 既不是 mailNickname 也不是 userPrincipalName,则提供该 Microsoft Entra 属性。

    $dbu_missing_columns_list = @()
    $dbu_creation_failed_list = @()
    foreach ($dbu in $dbu_not_matched_list) {
       if (($null -ne $dbu.$db_display_name_column_name -and $dbu.$db_display_name_column_name.Length -gt 0) -and
           ($null -ne $dbu.$db_user_principal_name_column_name -and $dbu.$db_user_principal_name_column_name.Length -gt 0) -and
           ($null -ne $dbu.$db_mail_nickname_column_name -and $dbu.$db_mail_nickname_column_name.Length -gt 0)) {
          $params = @{
             accountEnabled = $false
             displayName = $dbu.$db_display_name_column_name
             mailNickname = $dbu.$db_mail_nickname_column_name
             userPrincipalName = $dbu.$db_user_principal_name_column_name
             passwordProfile = @{
               Password = -join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_})
             }
          }
          try {
            New-MgUser -BodyParameter $params
          } catch { $dbu_creation_failed_list += $dbu; throw }
       } else {
          $dbu_missing_columns_list += $dbu
       }
    }
    
  11. 将任何缺失的用户添加到 Microsoft Entra ID 后,再次运行步骤 7 中的脚本。 然后运行步骤 8 中的脚本。 检查是否未报告任何错误。

    $dbu_not_queried_list = @()
    $dbu_not_matched_list = @()
    $dbu_match_ambiguous_list = @()
    $dbu_query_failed_list = @()
    $azuread_match_id_list = @()
    $azuread_not_enabled_list = @()
    $dbu_values = @()
    $dbu_duplicate_list = @()
    
    foreach ($dbu in $dbusers) { 
       if ($null -ne $dbu.$db_match_column_name -and $dbu.$db_match_column_name.Length -gt 0) { 
          $val = $dbu.$db_match_column_name
          $escval = $val -replace "'","''"
          if ($dbu_values -contains $escval) { $dbu_duplicate_list += $dbu; continue } else { $dbu_values += $escval }
          $filter = $azuread_match_attr_name + " eq '" + $escval + "'"
          try {
             $ul = @(Get-MgUser -Filter $filter -All -Property Id,accountEnabled -ErrorAction Stop)
             if ($ul.length -eq 0) { $dbu_not_matched_list += $dbu; } elseif ($ul.length -gt 1) {$dbu_match_ambiguous_list += $dbu } else {
                $id = $ul[0].id; 
                $azuread_match_id_list += $id;
                if ($ul[0].accountEnabled -eq $false) {$azuread_not_enabled_list += $id }
             } 
          } catch { $dbu_query_failed_list += $dbu } 
        } else { $dbu_not_queried_list += $dbu }
    }
    
    $dbu_not_queried_count = $dbu_not_queried_list.Count
    if ($dbu_not_queried_count -ne 0) {
      Write-Error "Unable to query for $dbu_not_queried_count records as rows lacked values for $db_match_column_name."
    }
    $dbu_duplicate_count = $dbu_duplicate_list.Count
    if ($dbu_duplicate_count -ne 0) {
      Write-Error "Unable to locate Microsoft Entra ID users for $dbu_duplicate_count rows as multiple rows have the same value"
    }
    $dbu_not_matched_count = $dbu_not_matched_list.Count
    if ($dbu_not_matched_count -ne 0) {
      Write-Error "Unable to locate $dbu_not_matched_count records in Microsoft Entra ID by querying for $db_match_column_name values in $azuread_match_attr_name."
    }
    $dbu_match_ambiguous_count = $dbu_match_ambiguous_list.Count
    if ($dbu_match_ambiguous_count -ne 0) {
      Write-Error "Unable to locate $dbu_match_ambiguous_count records in Microsoft Entra ID as attribute match ambiguous."
    }
    $dbu_query_failed_count = $dbu_query_failed_list.Count
    if ($dbu_query_failed_count -ne 0) {
      Write-Error "Unable to locate $dbu_query_failed_count records in Microsoft Entra ID as queries returned errors."
    }
    $azuread_not_enabled_count = $azuread_not_enabled_list.Count
    if ($azuread_not_enabled_count -ne 0) {
     Write-Warning "$azuread_not_enabled_count users in Microsoft Entra ID are blocked from sign-in."
    }
    if ($dbu_not_queried_count -ne 0 -or $dbu_duplicate_count -ne 0 -or $dbu_not_matched_count -ne 0 -or $dbu_match_ambiguous_count -ne 0 -or $dbu_query_failed_count -ne 0 -or $azuread_not_enabled_count -ne 0) {
     Write-Output "You will need to resolve those issues before access of all existing users can be reviewed."
    }
    $azuread_match_count = $azuread_match_id_list.Count
    Write-Output "Users corresponding to $azuread_match_count records were located in Microsoft Entra ID." 
    

将用户分配到 Microsoft Entra ID 的应用程序中

现在,由于 Microsoft Entra ECMA 连接器主机已经能够与 Microsoft Entra ID 进行通信,而且属性映射也已配置完毕,您可以继续设置哪些人员在预配范围内。

重要

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

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

如果暂时不想更新 LDAP 目录中的现有用户,请从 Microsoft Entra ID 中选择一个具有所需属性的测试用户,并将其配置到目录服务器。

  1. 确保用户选择的所有属性都将映射到目录服务器架构的必需属性。
  2. 在 Microsoft Azure AD 门户中,选择“企业应用程序”。
  3. 选择“本地 ECMA 应用”应用程序。
  4. 在左边的“管理”下,选择“用户和组” 。
  5. 选择“添加用户/组”。 显示添加用户的屏幕截图。
  6. 用户下,选择未选择 显示“未选择”界面的屏幕截图。
  7. 从右侧选择用户,然后选择 “选择 ”按钮。
    显示“选择用户”的屏幕截图。
  8. 现在选择“分配” 显示“分配用户”的屏幕截图。

测试资源配置

现在,您的属性已映射并已分配初始用户,可以通过其中一个用户测试按需预配。

  1. 在运行 Microsoft Entra ECMA 连接器主机的服务器上,选择“启动”。

  2. 在框中键入“run”,并输入“services.msc”。

  3. “服务 ”列表中,确保 Microsoft Entra Connect 预配代理 服务和 Microsoft ECMA2Host 服务都正在运行。 否则,请选择开始

  4. 在 Microsoft Azure AD 门户中,选择“企业应用程序”。

  5. 选择“本地 ECMA 应用”应用程序。

  6. 在左侧,选择“预配”。

  7. 选择按需供应

  8. 搜索一个测试用户,选择“预配” 显示测试按需预配的屏幕截图。

  9. 几秒钟后,将出现消息“已在目标系统中成功创建用户”,其中包含用户属性列表。 如果出现错误,请参阅 排查预配错误

开始预配用户

测试按需预配成功后,添加其余用户。 若要详细了解如何批量使用 New-MgServicePrincipalAppRoleAssignedTo创建应用程序角色分配,请参阅 管理Microsoft Entra ID 中的应用程序现有用户

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

排除预配错误

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

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

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

如果故障排除错误消息中包含表示 objectClass 值的 invalid per syntax,请确保预配属性映射到 objectClass 属性时,仅包含目录服务器识别的对象类名称。

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

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

检查用户是否已成功预配

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

以下说明演示如何在 Linux 上检查 OpenLDAP。

  1. 在安装了 OpenLDAP 的系统上,打开带命令行的终端窗口。
  2. 键入命令 ldapsearch -D "cn=admin,dc=contoso,dc=lab" -W -s sub -b dc=contoso,dc=lab -LLL (objectclass=inetOrgPerson)
  3. 检查生成的 LDIF 是否包含从 Microsoft Entra ID 预配的用户。

后续步骤