后端认证鉴权【免费下载链接】lldapLight LDAP implementation项目地址https://gitcode.com/gh_mirrors/ll/lldap点击查看免费下载导读Organizr 是一个用于集中管理自托管服务入口与 SSO 的仪表盘工具而 LLDAPLight LDAP implementation是一个轻量级 LDAP 身份目录服务。本指南基于仓库中的官方示例配置 example_configs/Organizr.md完整讲解如何在 Organizr 的System Settings Main Authentication面板中填写 LDAP 连接参数使 Organizr 能够通过 LLDAP 完成用户绑定与登录认证。读完本文你将掌握六个关键字段的精确取值方法、DN 前缀/后缀的拼接原理以及这些配置在 LLDAP 源码中的对应实现从而一次性配置成功。Organizr 认证配置概览Organizr 通过 LDAP 协议与目录服务器交互它使用一个服务账号bind user绑定到目录然后根据用户登录时输入的用户名拼出目标用户的 DN再以该用户身份执行二次绑定以校验密码。LLDAP 暴露的标准 LDAP 端口与目录结构oupeople用户树、ougroups组树恰好满足这一模型。以下是 example_configs/Organizr.md 给出的全部配置项在 Organizr 管理界面进入System Settings Main Authentication后逐项填写配置项示例值说明Host Addressldap://localhost:3890LLDAP 服务的地址与端口需替换localhost:3890为实际 LLDAP 主机与端口Host Base DNcn%s,oupeople,dcexample,dccom用户搜索的 DN 模板%s为登录用户名占位符Account prefixcn用户名前缀与 Base DN 模板中的cn%s对应Account Suffix,oupeople,dcexample,dccom用户名后缀与 Base DN 模板中的oupeople,dc...部分对应Bind Usernamecnadmin,oupeople,dcexample,dccom服务账号 DN即 LLDAP 管理员账号Bind Password你的 LDAP 配置中的密码LLDAP 管理员的 LDAP 绑定密码LDAP Backend TypeOpenLDAPOrganizr 需要选择 LDAP 后端类型选择 OpenLDAP注意文档最后强调——以上所有出现dcexample,dccom的地方都要替换为你在 LLDAP 中实际配置的域。字段逐一拆解与底层原理Host Address指向 LLDAP 的 LDAP 监听端点LLDAP 默认在3890端口提供 LDAP 协议服务。从 server/src/configuration.rs 可以看到#[builder(default r#String::from(::)#)] pub ldap_host: String, #[builder(default 3890)] pub ldap_port: u16,即默认ldap_port 3890ldap_host ::同时监听 IPv6通常也兼容 IPv4。因此若 LLDAP 与 Organizr 部署在同一台主机Host Address 填ldap://localhost:3890若 Organizr 在其他主机或容器中需要把localhost替换为 LLDAP 所在机器的 IP/主机名并确保 LLDAP 的ldap_host监听在对外可达的地址如 Docker 部署时配置为0.0.0.0参见 lldap_config.docker_template.toml。Host Base DN / Account prefix / Account Suffix用户 DN 的拼接方式Organizr 的认证流程等价于拿到用户输入的用户名后拼接出完整 DN再发起 LDAP Bind。Account prefix 用户名 Account Suffix必须与Host Base DN中的%s展开结果完全一致cn前缀username,oupeople,dcexample,dccom后缀拼接结果 cnusername,oupeople,dcexample,dccom 将%s替换为用户名后的 Host Base DN这套 DN 结构与 LLDAP 的用户目录布局精确对应。在 crates/ldap/src/core/user.rs 中LLDAP 构造用户搜索结果的 DN 为LdapSearchResultEntry { dn: format!(uid{},oupeople,{}, user.user_id.as_str(), base_dn_str), ... }用户条目位于oupeople之下RDN 属性为uid。而 crates/ldap/src/core/utils.rs 中的字段映射表表明LLDAP 同时接受uid、user_id、id作为用户主标识并把cn/displayname映射为显示名uid | user_id | id UserFieldType::PrimaryField(UserColumn::UserId), cn | displayname | display_name UserFieldType::PrimaryField(UserColumn::DisplayName),这说明文档中使用cn%s作为登录名属性在实际使用时需要注意cn在 LLDAP 中对应的是显示名display name而真正不可变的用户标识是uid。如果 Organizr 登录的用户名与 LLDAP 用户的显示名一致cn前缀可以正常工作否则更稳妥的做法是采用uid前缀与对应的uid%s,oupeople,dcexample,dccom模板使其与 LLDAP 的用户主键语义一致。Bind Username / Bind Password服务账号绑定Bind 字段用于 Organizr 先以管理权限绑定 LLDAP从而能够执行目录搜索。LLDAP 的管理员账号默认即cnadmin,oupeople,dcexample,dccom。这与 lldap_config.docker_template.toml 的说明完全吻合对于 LDAP 接口此处值为admin时将创建 LDAP 用户cnadmin,oupeople,dcexample,dccom基于上面的 base DN。对应在 server/src/configuration.rs 中#[builder(default r#UserId::new(admin)#)] pub ldap_user_dn: UserId,Bind Password 就是该管理员账号的 LDAP 绑定密码即 LLDAP 配置中的ldap_user_pass初始化管理员时设定。绑定请求在 LLDAP 侧的处理逻辑位于 crates/ldap/src/password.rsLLDAP 解析 Bind 请求中的 DN通过get_user_id_from_distinguished_name提取用户 ID再以简单密码LdapBindCred::Simple调用login_handler.bind(...)校验。密码错误会返回InvalidCredentials且 LLDAP 不允许匿名绑定、不支持 SASL 绑定。LDAP Backend Type选择 OpenLDAPOrganizr 的 LDAP 后端类型下拉框中选择OpenLDAP。这一选项影响 Organizr 对 LDAP 协议细节的处理方式例如是否按 RFC 4511 规范解析响应、属性大小写约定等。由于 LLDAP 使用标准 LDAPv3 协议见 crates/ldap/src/lib.rs 中基于ldap3_proto的实现选择 OpenLDAP 即可与其兼容。该配置组合也已经被列入仓库的官方已验证客户端清单见 example_configs/README.md。分步配置流程第一步确认 LLDAP 侧的目录参数在配置 Organizr 前先明确你的 LLDAP 实例的实际参数确认ldap_base_dn默认dcexample,dccom可在 lldap_config.docker_template.toml 或启动命令行中查看确认 LDAP 监听端口默认3890确认管理员 DNcnadmin,oupeople,dcexample,dccom管理员用户名非admin时替换cnadmin部分准备管理员密码。第二步在 Organizr 填写配置进入 OrganizrSystem Settings Main Authentication按第一节表格填写并全局替换dcexample,dccom。以域dclldap,dcexample,dccom、LLDAP 部署在192.168.1.10:3890为例Host Address: ldap://192.168.1.10:3890 Host Base DN: cn%s,oupeople,dclldap,dcexample,dccom Account prefix: cn Account Suffix: ,oupeople,dclldap,dcexample,dccom Bind Username: cnadmin,oupeople,dclldap,dcexample,dccom Bind Password: LLDAP 管理员密码 LDAP Backend Type: OpenLDAP第三步验证登录保存后在 Organizr 使用 LLDAP 中已存在的用户登录。若失败按以下顺序排查Host Address 不可达检查 LLDAP 进程监听地址与端口容器部署时确认ldap_host为0.0.0.0Bind 失败检查 Bind Username 中的dc后缀是否与ldap_base_dn完全一致密码是否正确LLDAP 会以InvalidCredentials拒绝错误密码见 crates/ldap/src/password.rs用户无法匹配确认登录所用用户名是 LLDAP 中的用户 IDuid还是显示名cn并据此选择前缀uid或cn大小写问题LLDAP 内部将 DN 转为小写后解析crates/ldap/src/core/utils.rs建议用户名统一使用小写。与 LLDAP 目录模型的对应关系整个配置之所以能成立是因为 Organizr 假设的 LDAP 目录布局与 LLDAP 的内置结构完全同构Organizr 概念LLDAP 目录元素源码依据用户 DN 后缀oupeople,...用户子树DN 形如uidid,oupeople,base_dncrates/ldap/src/core/user.rs服务账号cnadmin,...管理员用户默认adminserver/src/configuration.rs%s用户名占位uid/cn等可检索字段crates/ldap/src/core/utils.rs密码校验LDAP Bind简单绑定拒绝匿名与 SASLcrates/ldap/src/password.rs从 crates/ldap/src/core/utils.rs 的 DN 解析逻辑可以看到LLDAP 只接受cnname,ougroups,base或uidid,oupeople,base两种子树形态oupeople之外的用户 DN 都会返回UnexpectedFormat。这也是为什么 Organizr 的 Account Suffix 必须落在oupeople之下。常见问题Q1Organizr 提示无法连接到 LDAP 服务器确认 Host Address 的协议头为ldap://不是ldaps://除非你启用了 LLDAP 的 LDAPS 选项并配置了证书见 server/src/configuration.rs 中的LdapsOptions并检查端口号是否与 LLDAP 的ldap_port一致。Q2Bind 成功但登录提示用户不存在多为 DN 模板与 LLDAP 用户 ID 不匹配。请先在 LLDAP 管理界面确认目标用户的用户名uid再决定前缀用uid还是cn。Q3dcexample,dccom需要修改吗需要。文档明确指出把配置中出现的所有dcexample,dccom替换为你的 LLDAP 实际ldap_base_dn。若你的 base DN 是dcexample,dccom之外的任何值Host Base DN、Account Suffix、Bind Username 三处都必须同步替换否则 DN 不在 LLDAP 的 base 子树内绑定与搜索都会失败LLDAP 通过is_subtree校验子树归属见 crates/ldap/src/core/utils.rs。Q4管理员密码记不清了管理员密码在 LLDAP 初始化时通过ldap_user_pass设定见 lldap_config.docker_template.toml密码仅用于首次创建管理员后续修改可通过 LLDAP 的 Web 管理界面完成。小结Organizr 与 LLDAP 的对接本质上是标准 LDAPv3 简单绑定流程的配置工作只要 Host Address、DN 拼接三件套Base DN / prefix / suffix与 LLDAP 的oupeople目录结构及ldap_base_dn对齐并用管理员账号完成服务绑定即可让 Organizr 复用 LLDAP 的用户体系实现统一登录。本文所有示例均来自 example_configs/Organizr.md并结合 server/src/configuration.rs、crates/ldap/src/core/user.rs、crates/ldap/src/core/utils.rs 与 crates/ldap/src/password.rs 的源码实现进行了印证可作为你排查与复用的直接参考。赞分享后端认证鉴权【免费下载链接】lldapLight LDAP implementation项目地址https://gitcode.com/gh_mirrors/ll/lldap点击查看免费下载相关推荐Google Auth Library for Go 版本演进全解析cloud.google.com/go/auth 从 v0.1.0 到 v0.18.2 的凭证体系演进与关键变更Google Auth Library for Go 版本演进全解析cloud.google.com/go/auth 从 v0.1.0 到 v0.18.2 的后端认证鉴权用 tchMaterial-parser 把智慧教育平台的电子课本 PDF 批量存到本地用 tchMaterial parser 把智慧教育平台的电子课本 PDF 批量存到本地 tchMaterial parser 是一个面向国家中小学智慧教育平台后端认证鉴权Hive 项目 SerpAPI 工具实战指南用 MCP 工具打通 Google Scholar 与 Google Patents 学术检索Hive 项目 SerpAPI 工具实战指南用 MCP 工具打通 Google Scholar 与 Google Patents 学术检索 导读 本文围绕 H后端认证鉴权上一篇Karmada 驱逐队列限流机制全解析Eviction Queue Rate Limiting 的设计与实现下一篇mac-mouse-fix 内置 ReactiveSwift 7.1.1 API 契约全解析Event、Signal、SignalProducer 与 Property 的语义规范与最佳实践创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考