Django登录认证必须通过AuthenticationBackend，python-ldap仅是底层通信工具，无法替代django-auth-ldap；后者提供用户同步、属性映射、session绑定等完整流程，而前者仅用于重置密码、创建账号等反向操作。
python-ldap 不是 Django 官方认证组件，它不参与 authenticate() 流程，也不能直接替代 django-auth-ldap。真正在登录链路里起作用的是认证后端（AuthenticationBackend），而 python-ldap 只负责底层 LDAP 协议通信——它是个“工具库”，不是“认证插件”。
要实现企业级统一认证，必须同时用好两个东西：django-auth-ldap 做标准登录与用户同步，python-ldap 做它做不到的事（比如重置密码、创建账号、组管理、DN 检索等）。只靠一个，90% 的真实场景会卡住。
为什么不能只用 python-ldap 实现登录？
因为 Django 的 authenticate() 函数默认只认 AuthenticationBackend 实例，而 python-ldap 本身不提供任何 backend 类。你写个 ldap_bind() 函数手动连 LDAP 验证密码，它无法自动触发用户创建、属性映射、session 绑定、权限同步这些关键动作。
- 手动调用
ldap.initialize()+simple_bind_s()只能返回 True/False，Django 不知道该把谁写进request.user - 不会自动从 LDAP 拉取
givenName、mail填到 Django User 字段里 - 不会在首次登录时创建本地
User对象，也不会更新last_login - 一旦用户在 LDAP 中被禁用，仅靠
python-ldap手动验证，无法阻止其后续通过 session 继续访问
django-auth-ldap 的配置必须配对 python-ldap
django-auth-ldap 内部完全依赖 python-ldap 发起连接和查询，但它自己不打包这个依赖——你必须显式安装并确保版本兼容。常见坑：
- Django 4.2+ + Python 3.11+ 环境下，
python-ldap2.5.x 编译失败，得降级到 2.4.45 或改用ldap3（但django-auth-ldap不支持ldap3） -
AUTH_LDAP_SERVER_URI写成ldaps://时，若证书不可信，python-ldap默认拒绝连接，需提前调用ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, ldap.OPT_X_TLS_NEVER) -
AUTH_LDAP_USER_SEARCH使用的LDAPSearch对象，其filterstr中的%(user)s是字符串插值，不是 SQL 注入点，但若用户输入含)或*，可能意外截断 filter，建议前端或中间层做基础校验
什么时候必须自己写 python-ldap 代码？
当业务需要反向操作 LDAP（即从 Django 主动写数据回 LDAP），django-auth-ldap 完全无能为力。典型场景：
- 管理员在 Django Admin 里点击「重置密码」，实际要调用
ldap.passwd_s()修改 LDAP 条目 - 用户自助注册流程，需构造 DN 并执行
ldap.add_s()添加新条目 - 同步部门变更：根据 LDAP 中
ou=tech成员，批量更新 Django 内 Group 权限 - 登录时需额外校验用户是否在特定
groupOfNames中，而该 group 不在 base_dn 下，需二次search_s()
这类逻辑必须封装在自定义 service 层，例如：
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
立即学习“Python免费学习笔记（深入）”；
def reset_ldap_password(dn, new_password):
conn = ldap.initialize(settings.AUTH_LDAP_SERVER_URI)
conn.simple_bind_s(settings.AUTH_LDAP_BIND_DN, settings.AUTH_LDAP_BIND_PASSWORD)
conn.passwd_s(dn, None, new_password.encode('utf-8'))
conn.unbind_s()
注意：这里不能复用 django-auth-ldap 的连接池，它不暴露底层 ldap.LDAPObject 实例。
连接复用和异常处理最容易被忽略
python-ldap 的 ldap.initialize() 返回对象不是线程安全的，Django 多线程下直接全局复用一个连接会导致 ldap.INVALID_CREDENTIALS 或静默失败。正确做法是：
- 每次操作都新建连接（开销可控，LDAP 连接轻量）
- 或使用连接池（如
ldap3的ThreadedConnectionPool，但需放弃django-auth-ldap） -
simple_bind_s()必须加超时：conn.set_option(ldap.OPT_TIMEOUT, 10)，否则网络卡死会拖垮整个请求 - 捕获具体异常而非泛用
ldap.LDAPError，比如ldap.INVALID_CREDENTIALS和ldap.NO_SUCH_OBJECT要区分处理，前者是密码错，后者可能是 DN 拼写错误或用户被删
企业环境中，DNS 解析慢、防火墙拦截、LDAP 服务器切主节点都会导致瞬时连接失败，重试逻辑（带指数退避）比单纯 try/except 更实用。
