Can you please give an explanation of the full meaning?? That way we can learn because online it refers to invalid credentials, providing the user is good, then the password is what left over See this example where I intentionally put the wrong password
root@nm03-lab-roc1:~/openldap_config_tree/2.1_replication# ldapsearch -Z -LLL -H ldap://servert:389 -D "uid=user,ou=employees,dc=metrocast,dc=net" -W -b "ou=employees,dc=metrocast,dc=net" "(mail=* ugonzalezhorta@breezeline.com)" cn Enter LDAP Password: ldap_bind: Invalid credentials (49)
Ulises Gonzalez Horta
Lead Linux Engineer
C: 786 450 2970/ 240 727 6267
E: ugonzalezhorta@breezeline.com jsutherland1@breezeline.com
On Fri, Jan 3, 2025 at 2:16 PM Quanah Gibson-Mount quanah@fast-mail.org wrote:
--On Friday, January 3, 2025 8:49 AM -0500 Ulises Gonzalez Horta ugonzalezhorta@breezeline.com wrote:
Yeah, the error message was misleading here, error 49 is wrong password, but I knew for sure the password was right. Maybe a log entry as the one you suggested will help you fast pinpoint the issue
That's not what result code 49 means.
--Quanah
On Fri, Jan 03, 2025 at 02:21:58PM -0500, Ulises Gonzalez Horta wrote:
Can you please give an explanation of the full meaning?? That way we can learn because online it refers to invalid credentials, providing the user is good, then the password is what left over See this example where I intentionally put the wrong password
Hi Ulises, all it means is that for whatever reason, the credentials (combination of user and password in your case) is not accepted by the server.
Since confirming whether a user exists to a random passer-by (=anonymous session) is generally considered a very bad idea, the server is unwilling to disclose a reason for the failure. As you found out there might be a lot of things that end up influencing the ability to bind as a user: the user might not exist, there might be no useable password in the DB, ACLs might prevent this too if they deny auth access to the user or its password, the way you replicate the DB does not match up with what you expected...
If in doubt, especially when you suspect a misconfiguration, it is up to the administrator to investigate.
There might be reasons when more information actually gets returned, it should always be something the admin explicitly configured - e.g. password expiry information through the ppolicy overlay.
Regards,
Thank you for the explanation. I was very good, Happy new year
Ulises Gonzalez Horta
Lead Linux Engineer
C: 786 450 2970/ 240 727 6267
E: ugonzalezhorta@breezeline.com jsutherland1@breezeline.com
On Tue, Jan 7, 2025 at 10:29 AM Ondřej Kuzník ondra@mistotebe.net wrote:
On Fri, Jan 03, 2025 at 02:21:58PM -0500, Ulises Gonzalez Horta wrote:
Can you please give an explanation of the full meaning?? That way we can learn because online it refers to invalid credentials, providing the user is good, then the password is what left over See this example where I intentionally put the wrong password
Hi Ulises, all it means is that for whatever reason, the credentials (combination of user and password in your case) is not accepted by the server.
Since confirming whether a user exists to a random passer-by (=anonymous session) is generally considered a very bad idea, the server is unwilling to disclose a reason for the failure. As you found out there might be a lot of things that end up influencing the ability to bind as a user: the user might not exist, there might be no useable password in the DB, ACLs might prevent this too if they deny auth access to the user or its password, the way you replicate the DB does not match up with what you expected...
If in doubt, especially when you suspect a misconfiguration, it is up to the administrator to investigate.
There might be reasons when more information actually gets returned, it should always be something the admin explicitly configured - e.g. password expiry information through the ppolicy overlay.
Regards,
-- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
openldap-technical@openldap.org