LDAP 管理
ACP 可以对 LDAP 目录中的用户进行身份验证,并且可以选择性地同步目录组。控制台工作流支持常见的 OpenLDAP 和 Microsoft Active Directory 布局。
只有在以下所有检查都通过后,集成才算完成:
- ACP 创建 LDAP IDP。
- 预期的用户以及(如果启用)组已同步。
- 某个代表性目录用户可以登录,并获得预期的 ACP 角色。
本指南从最短的控制台工作流开始。如果目录管理员尚未提供 Base DN、Filter 或属性映射,请先使用 发现目录设置。
目录
开始之前发现目录设置1. 从正确的网络运行检查2. 查找目录根3. 选择 User 和 Group Base DN4. 检查具有代表性的用户5. 选择 Identity 和 Login 属性6. 逐步构建 User FilterLDAP Filter 语法速查7. 确定 Group Membership 模型选择经过验证的映射添加 LDAP控制台字段参考验证集成同步与生命周期首次登录同步手动同步自动同步更新 Connector协调上游已删除的用户删除 Connector使用 YAML 配置 LDAP严格验证的 OpenLDAP 模板Active Directory 模板完整 LDAP YAML 字段参考按症状排查现场诊断工具外部:Linux 和 macOS LDAP 工具外部:使用ldapsearch 查询 Active Directory高级:ACP 组件日志开始之前
在配置 ACP 之前,请准备好以下值:
- 可从 ACP 集群访问的 LDAP server 主机名和端口。
- 具有目标用户和组读取权限的 Bind DN 和密码。
- User Base DN 和 user Filter。
- 稳定、唯一且非空的用户身份属性。
- 一个或多个登录属性。
- 可选的 group Base DN、group Filter、member attribute、user matching attribute 和 group name attribute。
- 用于最终登录验证的一个代表性用户账户。
工程师笔记本电脑上的查询成功,并不能证明 ACP 可以连接。ACP Connector 创建和同步才是集群侧的检查。如果目录管理员已经提供并验证了所有必需的值,请继续 添加 LDAP。
发现目录设置
当 Base DN、Filter 或属性映射未知时,请使用此工作流。这里引用的命令行工具是外部的、集成前诊断工具,不是 ACP 功能。
1. 从正确的网络运行检查
尽可能从一个诊断主机或 Pod 上运行目录查询,并确保其 DNS、路由、防火墙和证书信任与 ACP 集群等效。笔记本电脑上的查询可以作为有用的初步证据,但 ACP Connector 创建和同步仍然是权威的集群侧检查。
2. 查找目录根
查询目录 Root DSE 并记录 naming root:
- OpenLDAP 和兼容目录通常会发布
namingContexts。 - Active Directory 会发布
defaultNamingContext。
请使用最终 现场诊断工具 部分中的 Root DSE 示例。返回的值(例如 dc=example,dc=com)是定位用户和组分支的起点;它不会自动成为最佳的 User Base DN。
3. 选择 User 和 Group Base DN
将 Base DN 视为 ACP 搜索的下界。例如:
- 如果所有目标用户都位于
ou=People,dc=example,dc=com下,则将其用作 User Base DN。 - 如果目标用户分布在
ou=People之外的多个分支中,则使用它们的最低公共父级。 - 如果组存放在
ou=Groups下,请使用单独的 Group Base DN。
在运行 subtree 查询之前,请使用外部的 base-scope 查询确认绑定账户可以读取候选 Base DN。ACP 表单会在配置的 Base DN 下执行 subtree 搜索,不会暴露 Search Scope 字段。YAML 可以使用 scope: sub 或 scope: one;在当前 Connector runtime 中,未指定的 scope 默认是 sub。
4. 检查具有代表性的用户
在选择映射之前,至少检查三个条目:
- 一个预期要登录的普通用户。
- 位于另一个目标 OU 或目录分支中的用户。
- 一个边界情况,例如禁用用户、没有组的用户,或缺少可选属性的用户。
对于 OpenLDAP,请请求 DN、objectClass、uid、cn 和 mail。对于 Active Directory,请请求 DN、objectClass、sAMAccountName、displayName、mail、userAccountControl 和 memberOf。在缩小 Filter 之前,确认目标用户集合位于候选 Base DN 之下。
5. 选择 Identity 和 Login 属性
不要仅仅因为 cn、displayName 或用户 DN 可读,就把它们用作默认 ACP identity。这些值可能重复,而且用户重命名或移动时可能发生变化。在创建 Connector 之前,请在目录中解决缺失或重复的 identity 值。
6. 逐步构建 User Filter
按以下顺序构建并重新测试 Filter:
- 使用
objectClass选择用户条目。 - 使用
(attribute=*)强制要求 ACP identity 和登录属性存在。 - 当客户目录策略要求时,排除计算机、禁用账户、服务账户或系统账户。
- 仅在广泛结果与预期用户集合匹配之后,再添加业务限制。
在每个条件之后,重新运行外部目录查询,并将计数和代表性条目与预期用户集合进行比较。使用以下 Filter 查找会因建议的 identity 不存在而被跳过的条目:
最后一个表达式是可复制的 Active Directory LDAP Filter,用于排除禁用账户。仅当该排除规则符合客户的目录策略时才使用它。
LDAP Filter 语法速查
请从返回目标条目的最小表达式开始构建 Filter。以下 operator 已在本指南使用的测试目录上进行了验证。
不要在已配置的 user Filter 中放入 <username> 占位符。同步会按原样运行所配置的 Filter。在登录期间,ACP 会将该 Filter 与每个已配置 Login Field 属性的等值查找组合起来。
7. 确定 Group Membership 模型
检查一个已知 group,并将其存储的成员值与代表性用户进行比较:
- 当
member包含完整的用户 DN 时,使用 Group Attrmember和 User AttrDN。 - 当
memberUid包含简短用户 ID 时,使用 Group AttrmemberUid和 User Attruid。
ACP 会为每个用户按 (<Group Attr>=<User Attr value>) 计算 group membership。使用外部目录查询复现该查找,例如 (member=uid=alice,ou=People,dc=example,dc=com) 或 (memberUid=alice)。在验证此映射时,不要只依赖用户的 memberOf 值。
选择经过验证的映射
这些映射是本版本为所列布局提供的起点。Active Directory Filter 会排除计算机对象和禁用账户。只有在客户目录策略要求不同用户集合时才更改该 Filter,并在更改后重新执行外部计数、ACP 同步和登录检查。
当 Active Directory group synchronization 使用 Group Attr member 和 User Attr DN 时,请使用 (&(objectClass=group)(member=*)) 作为 Group Filter。ACP 在创建期间会针对采样的 group 条目验证 member。更宽泛的 (objectClass=group) Filter 可能会采样到不返回 member 属性的空 group,并拒绝一个原本有效的映射。
添加 LDAP
- 转到 Users > IDP。
- 单击 Add LDAP。
- 完成 Basic Info:Name、Display Name 和可选的 Description。
- 完成 LDAP Server Setting:Server Address、Admin Account 和 Admin Password。
- 完成 Search Setting:Filter 和 Base DN。
- 如果需要 group synchronization,请启用 Group Search Setting,并输入 Filter、Base DN、Group Attr 和 User Attr。
- 完成 Field Mapping:User Name Attr、可选的 Group Name Attr、Login Field 和 Username Tip In Login Box。User Name Attr 会成为同步后的 ACP 用户所使用的稳定 identity 值;它不只是一个显示标签。Login Field 决定 ACP 如何搜索登录账户,并支持以逗号分隔的多个候选项。
- 可选地打开 Advanced Settings,启用 Auto Sync,并在 Sync Rules 中输入五段式 cron 表达式。ACP 会按 UTC 评估该规则。
- 单击 Add。
在创建期间,ACP 会验证 server connectivity、bind、Base DN、Filter 和映射属性。当前表单在创建时不会认证普通目录用户,因为它不收集测试用户凭证。提交的 bind password 会在创建后移动到受管理的 Secret 中。
控制台字段参考
使用此表将 ldapsearch 中发现的值转换为当前 ACP 表单,以及后文描述的 YAML 字段(如有需要)。
表单不暴露 scope、TLS 标志、CA 数据或可选的 profile mappings。只有在需要时,才通过 YAML 配置这些字段。
验证集成
- 打开新的 LDAP IDP,并选择 Actions > Sync user。
- 确认同步结果,并将同步后的用户和 group 数量与预期的目录用户集合进行比较。
- 打开一个已同步用户,验证其来源、identity 值和状态是否正确。
- 使用 管理用户角色 或 管理用户组角色 分配一个最小角色。
- 使用一个不带 ACP 登录状态的独立浏览器会话,并使用代表性目录账户登录。
- 确认认证成功,并且可用的 ACP 权限已生效。
整体同步可能会报告成功,但缺少 User Name Attr 的条目会被跳过。某个用户没有匹配的目录 group,并不意味着该用户同步失败。请比较计数并检查代表性条目,而不要只依赖总体结果。
同步与生命周期
首次登录同步
目录用户可以在执行完整手动同步之前先登录。认证成功后,ACP 会同步该单个 LDAP 用户。请使用上面的完整验收路径来验证预期清单、group 映射和授权,而不要把首次登录当作完整集成验收。
手动同步
打开 LDAP IDP 并选择 Actions > Sync user,即可按需同步并协调目录用户集合。请查看结果、计数、被跳过条目的消息,以及代表性用户和 group。
新同步的 LDAP 用户是 active、valid 的,且默认 validity period 为 Permanent,除非管理员之后更改其 validity。
在同步开始前,ACP 会警告:如果某个与现有本地用户同名的 IDP 用户存在,可能会覆盖或重新关联该用户,同时保留现有角色分配。在第一次完整同步之前,请检查建议的 User Name Attr 是否与当前 ACP 用户冲突。不要使用内置本地管理员账户作为集成测试身份。
自动同步
当需要定期协调时,请在 Advanced Settings 下启用 Auto Sync,并提供 Sync Rules。自动同步使用已配置的 Base DN、Filters 和映射;它不会认证目录用户密码。ACP 会按 UTC 评估五段式 cron 表达式。对于验收测试,*/1 * * * * 表示每分钟运行一次;在观察到计划运行之后,请将此临时规则替换掉。
更新 Connector
当 server、搜索边界、Filter、映射或自动同步设置发生变化时,请更新 LDAP IDP。更新后执行一次手动同步,以确认新配置并协调现有源用户和 group。
协调上游已删除的用户
在手动或自动协调之后,从上游目录中删除的用户会在 ACP 中变为 invalid,并且不能再通过该 source 进行认证。
删除 Connector
删除 Connector 而不进行清理时,会保留来自该 source 的用户和 group,并将这些用户标记为 invalid。如果在删除期间选择了 Clean up IDP users and User Groups,ACP 会删除由该 Connector 生成的用户和 group。
使用 YAML 配置 LDAP
以下 v2 Connector 模板仅将 bindPW 作为初始创建输入。请通过 ACP 控制台的 YAML 选项卡提交它们。ACP 会把提交的密码移动到受管理的 Secret 中,而已保存的 YAML 中随后会包含受管理的 clientSecretRef,而不是 bindPW。不要对内联 bindPW 使用 kubectl apply:Kubernetes last-applied annotation 可能会在 Connector metadata 中保留提交的密码。使用前请替换每个示例值。
创建 Connector 时,ACP 会添加 metadata.labels["cpaas.io/idp.version"]: v2。对于不带 rootCAData 的普通 LDAP 连接,ACP 还会持久化 insecureNoSSL: true、insecureSkipVerify: true 和 startTLS: false。模板显式展示这些值,以便提交的 YAML 描述实际生效的连接模式。
ACP 可以从 Filter 中的第一个 objectClass 推断某些用户和 group 属性。对于客户交付,不要依赖这种推断:它无法判断目录实际的 identity 和 membership 模型。请在检查代表性条目后,显式设置 idAttr、nameAttr、username、groupAttr、userAttr 和 group 的 nameAttr。模板还会显式写入 scope: sub,尽管 sub 是运行时默认值。这里的模板不把 clientSecretRef 作为输入字段,因为 ACP 只有在将 bindPW 移动到受管理的 Secret 后才会写入它。
严格验证的 OpenLDAP 模板
在此 ACP 版本中,若 Connector 的 host 以 :636 结尾,即使提交的值为 false 且 rootCAData 包含正确的 CA,系统也会将其存储为 insecureSkipVerify: true。标准端口的 LDAPS 流量虽然已加密,但 ACP 不会验证 LDAP server 证书。
下面的模板适用于在非 636 端口上暴露 LDAPS 的目录。在该端口上,请保持 insecureSkipVerify: false,并通过 rootCAData 提供受信任的 CA。如果需要证书验证,请与目录和网络管理员协调端口,然后完成 Connector 创建、同步和真实登录后再推广。
Active Directory 模板
完整 LDAP YAML 字段参考
以下骨架包含对 v2 LDAP Connector 有用的 ACP 集成字段。可选的 profile mappings 已注释掉,以便在目录不提供这些属性时示例仍然有效。请移除未使用的可选字段,而不是为缺失于过滤后用户中的属性命名。
顶层和 metadata 字段:
连接和传输字段:
userSearch 字段:
emailSuffix 和 v2 同步
在已验证的 v2 行为中,emailSuffix: test.com 会为首次登录 identity 生成 admin@test.com,而手动同步仍会将不带后缀的 nameAttr 作为主标识存储。除非已针对客户的同步和冲突要求测试过此差异,否则请不要设置 emailSuffix。
groupSearch 字段:
如果 ACP 不需要 group synchronization,则完全省略 groupSearch。
仅当目录暂时不可访问、但必须先部署 Connector 时,才使用 cpaas.io/idp.validation: "false"。ACP 仍会检查配置结构,但会跳过 network、TLS、bind、Base DN、Filter 和映射属性检查。因此,即使同步和登录无法工作,Connector 仍可能存在。
admission webhook 会从已存储的 Connector 中移除此注解,并将 skip 标记复制到受管理的 credential Secret。之后,如果在没有该注解的情况下更新 Connector 的 spec,系统会执行正常的 Connector 验证。要在未来的凭证变更中恢复验证,请通过不带该注解的 Connector 更新 credential;不要直接编辑受管理的 Secret。不要使用 cpaas.io/idp.validation: "true";正常验证时省略该注解即可。
在推广之前,请完成一次正常验证的创建或真实的修正更新,然后运行手动同步和代表性登录。仅对 metadata 的更新,并不能证明正常验证已经运行。
请将传输标志作为一组来选择:
上面的 Active Directory 模板使用的是明文 LDAP。明文 LDAP 不会在网络上传输时保护 bind password。仅当客户的网络和安全策略允许时才使用它。当需要 TLS 时,先确定策略是否也要求证书验证:此版本中,标准端口 636 提供加密,但不提供服务器证书验证;而严格验证需要非 636 的 LDAPS 端口和 rootCAData。在推广前,请完成一次 ACP LDAPS 创建、同步和登录测试。
若要在非 636 的 LDAPS 端口上进行严格证书验证,请将 PEM CA 证书编码为不带换行的 Base64,并将输出作为 rootCAData 使用:
若要在 YAML 中配置计划同步,请向 Connector 添加受支持的 metadata:
该示例规则仅适合观察验收测试运行。验证完成后,请将其替换为所需的 UTC 调度。顶层 id 必须等于 metadata.name;当前的计划同步会按该 identity 查找 Connector。
按症状排查
现场诊断工具
本节中的工具是外部的、集成前诊断工具或高级 ACP 证据收集工具。它们不是内置的 ACP 功能。
外部:Linux 和 macOS LDAP 工具
LDAP 命令需要已安装的 OpenLDAP 客户端,例如 ldapsearch 和 ldapwhoami。它们会使用 -W 提示输入 bind password。该选项只能防止密码出现在命令行中,并不会加密网络传输。
下面的私有 CA 环境变量已在 Linux OpenLDAP 客户端上验证。内置的 macOS /usr/bin/ldapsearch 和 /usr/bin/ldapwhoami 则使用 macOS 系统信任存储;请使用 Linux 诊断主机或 Pod,或者在使用这些内置客户端之前先在 macOS Keychain 中配置 CA。
对于每个 ldapwhoami 和 ldapsearch 命令,请使用与被调查 Connector 相同的传输组合:
下面的查询示例使用的是明文 LDAP,因此只与 insecureNoSSL: true 的 Connector 匹配。对于 LDAPS,请在运行每个示例之前将 -H 值替换为匹配的行。如果 LDAP 证书由私有 CA 签名,诊断客户端也必须信任该 CA。在 Linux OpenLDAP 客户端上,请按如下方式为每个 ldapwhoami 或 ldapsearch 命令添加前缀:
如果没有 LDAPTLS_CACERT 设置,已验证的 Linux 客户端会失败并报 unable to get local issuer certificate;添加 CA 文件后,同样的 bind 就会成功。
外部命令:仅测试 TCP 端口可达性
该命令只检查 TCP 端口是否可达,不会验证 TLS、bind 凭证或 LDAP 搜索行为。检查 LDAPS 端口可达性时,请改用端口 636。
外部命令:验证 server、传输和 bind 账户
外部命令:读取目录 Root DSE
外部命令:确认候选 Base DN 可读
外部命令:复现 OpenLDAP 用户 subtree 搜索
外部命令:查找缺少所建议 identity 的 OpenLDAP 条目
外部命令:打印建议的 OpenLDAP identity 的重复值
在评估其他候选 identity 属性时,请替换 uid、Base DN 和 Filter。没有输出意味着返回的条目中没有发现重复值。与其他 ldapsearch 示例一样,请使用与 Connector 匹配的传输组合。
外部命令:复现 groupOfNames membership 查找
外部命令:使用预期的 CA 验证 LDAPS 证书链
只有当输出报告验证成功时,证书检查才算通过,例如 Verify return code: 0 (ok) 或 Verification: OK。
外部:使用 ldapsearch 查询 Active Directory
同一个 OpenLDAP 命令行客户端可以在不需要 Windows 或 RSAT 的情况下检查 Active Directory。请使用具有读取权限的目录账户。
外部命令:检查目标 Active Directory 用户
外部命令:复现 Active Directory group membership 查找
高级:ACP 组件日志
这些部署名称是当前 ACP 组件名称。运行这些命令需要读取集群日志的权限。
高级 ACP 命令:检查 Connector 创建验证
auth-controller2 负责 Connector 创建验证,包括网络连接、TLS、bind、Base DN、Filter 和映射属性。
高级 ACP 命令:检查同步和登录行为
apollo 负责手动和计划同步、被跳过的条目、group 查找以及登录行为。
外部工具成功,并不能证明 ACP 可以访问或使用该目录。请结合 ACP Connector 创建、预期同步结果以及使用目标 ACP 权限进行的真实目录登录,完成完整证据链。