Go LDAP 空密码绑定为什么需要显式区分认证意图

Go LDAP 里的空密码不是“密码校验失败但仍然可以继续”的另一种写法，而是可能代表完全不同的认证意图。当前 github.com/go-ldap/ldap/v3 将普通 Bind 与未认证绑定分开：前者拒绝空密码，后者明确表示连接不携带可验证的用户凭据。

官方地址：https://pkg.go.dev/github.com/go-ldap/ldap/v3

因此，用户登录、匿名/未认证探测和测试兼容性不能共用一个“用户名 + 密码”函数。先在业务层决定认证意图，再选择 LDAP API，才不会把未认证连接误当成已登录连接。

先把空密码的三种语义分开

Conn.Bind(username, password) 用于用户名和非空口令的普通绑定。库文档明确说明它不允许 unauthenticated bind，也就是空密码场景；空密码直接传给它会在客户端被拒绝，而不是交给服务器判断“这个用户有没有空密码”。

如果业务确实要建立未认证绑定，应调用 UnauthenticatedBind(username)。这里的用户名通常只用于追踪或日志，服务器一般不会用它验证身份。它能建立一个 LDAP 会话，不等价于“登录了这个 username”。

需要更底层控制时，也可以构造 SimpleBindRequest，再显式设置 AllowEmptyPassword = true。这个字段的存在就是为了让调用者把“允许空密码”写成一个可见的选择，而不是让空字符串悄悄改变认证语义。

用认证意图把错误调用挡在边界上

不要让登录函数接收空密码后再“试一下”。更稳妥的做法是把认证意图建模为枚举：用户登录必须有口令，未认证探测只能走单独的分支。下面的代码展示这个边界，地址和账号是示意值，不能直接当作真实目录配置。

package main

import (
    "errors"
    "fmt"

    ldap "github.com/go-ldap/ldap/v3"
)

type bindIntent uint8

const (
    passwordAuth bindIntent = iota
    unauthenticatedProbe
)

func bindWithIntent(conn *ldap.Conn, intent bindIntent, username, password string) error {
    switch intent {
    case passwordAuth:
        // 登录意图不接受空密码，避免把输入错误变成另一种认证状态。
        if password == "" {
            return errors.New("拒绝使用空密码执行用户登录")
        }
        // Bind 由 LDAP 服务器按用户名和口令建立已认证会话。
        return conn.Bind(username, password)
    case unauthenticatedProbe:
        // 该用户名只用于追踪；不要把返回成功解释为用户已通过认证。
        return conn.UnauthenticatedBind(username)
    default:
        // 未知意图必须失败，避免未来新增枚举后静默降级。
        return fmt.Errorf("未知绑定意图: %d", intent)
    }
}

func main() {
    // 示例地址仅用于说明连接入口；生产环境应使用 TLS 和实际配置。
    conn, err := ldap.DialURL("ldaps://directory.example.com:636")
    if err != nil {
        panic(err)
    }
    defer conn.Close() // 连接只在当前示例生命周期内使用。

    if err := bindWithIntent(conn, passwordAuth, "uid=alice,ou=people,dc=example,dc=com", "secret"); err != nil {
        panic(err)
    }
}

这个封装的关键不是枚举本身，而是让调用点必须回答“我要登录，还是只建立未认证会话”。对于登录表单，空密码应在业务层返回输入错误；对于目录连通性探测，则应把探测结果和用户认证结果分开记录。

需要显式允许空密码时，保留这个选择的可见性

有些目录服务或兼容性测试确实需要发送空口令的 Simple Bind。此时不要把 Bind 替换成一段隐藏的特殊判断，而是显式设置请求字段，并在代码旁边说明它不代表用户认证：

func unauthenticatedSimpleBind(conn *ldap.Conn, traceName string) error {
    // 空密码是未认证意图，名称只作追踪，不应被当成已校验的账号。
    req := ldap.NewSimpleBindRequest(traceName, "", nil)
    req.AllowEmptyPassword = true

    // SimpleBind 返回响应对象；这里只关心请求是否被服务器接受。
    _, err := conn.SimpleBind(req)
    return err
}

这个分支要有清晰的调用名和权限边界。若后续代码需要读取受保护属性，不能因为 Simple Bind 返回成功就继续假定已经取得某个用户的授权身份；应使用真实凭据重新绑定，或直接关闭这条仅用于探测的连接。

用四个问题排查空密码错误

可以把规则压缩成一句话：空密码不是一种凭据值，而是需要被业务明确命名的认证意图。普通登录走 Bind，未认证会话走 UnauthenticatedBind，只有兼容性或协议级场景才在 Simple Bind 请求上显式打开空密码。

常见问题

空密码账号能不能用 Bind 登录？

不能把它当成普通登录路径。当前库的 Bind 明确不允许空密码；如果业务是用户认证，应要求真实口令并处理输入错误。

UnauthenticatedBind 的 username 会被服务器验证吗？

通常不会。它主要用于追踪或日志，不能作为已认证用户 DN，也不能推断该用户存在。

设置 AllowEmptyPassword 就等于匿名访问吗？

不应这样推断。它只是允许客户端发送空密码的请求，最终会话权限仍取决于 LDAP 协议语义、服务器策略和目录 ACL。