Cody Schaefer
8d49fb9248
"Authentication failed." and no more. I had carried the generic-message reasoning across from /api/auth/login, where one indistinguishable failure is correct because an unauthenticated caller must not be able to enumerate accounts. That reasoning does not transfer to a local CLI: the operator IS the account holder, there is nobody to leak to, and withholding AD's own sub-code just makes the failure undiagnosable. It cost a round trip to find that out. Now prints the reason, the AD error-49 sub-code, the exact bind string attempted, the server, and the password length - enough to tell apart a wrong password (52e), a locked account (775), an expired one (532), and the case that looks like a bad password but is not: 525, no such user, which means the BIND NAME is wrong rather than the credential. That last one matters here. The bind is <sAMAccountName>@LDAP_DOMAIN, and LDAP_DOMAIN defaults to the AD DNS name (prime.local). If an estate's UPN suffix is the mail domain instead, that string is not a valid bind name and AD answers 525 - which reads as "bad password" to anyone not looking at sub-codes. The hint says so, and says to set LDAP_DOMAIN to the UPN suffix. The password is never echoed or logged; only its length, which distinguishes "getpass read nothing" from "getpass read the wrong thing". /api/auth/login is untouched. Its generic 401 is still correct. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>