Hi,
today I found a strange behavior of Messenger, CVS version from today:
Every LDAP user can log in to Messenger without a password!
Log in with LDAP user and correct password -> success
Log in with LDAP user and no password (empty) -> success !!!
Log in with LDAP user and wrong password -> Error message about wrong password
Can somebody please approve this behavior?
Regards,
Frank
I did some more tests:
CVS installation with mySQL DB and LDAP -> wrong behavior
CVS installation with embedded DB, without LDAP -> right behavior
CVS installation with embedded DB and LDAP -> wrong behavior
stable release with embedded DB, without LDAP -> right behavior
stable release with embedded DB and LDAP -> wrong behavior
So it seems that Messenger has wrong behavior only with LDAP, not matter of DB location or version (stable/CVS).
Frank,
I’‘ve filed JM-189 to look into this issue. We’'ll get it resolved before the 2.1.2 release.
Thanks,
Matt
Thanks Matt,
tell me if I can help you (testing?) in any way.
Regards,
Frank
Definitely not seeing any of the above.
I just downloaded and compiled the latest CVS head.
I’'m running with a postgres db using ldap.
Tried it using ssl and non-ssl connection to the ldap server (on localhost), both working the way they should.
Wrong or no password gets rejected every time.
I copied the code out of LdapManager and pasted it into a simple main class to do a stand alone test and got an exception every time I should have.
I’‘m using Openldap 2.2.6. Maybe it’‘s the ldap server being used? Is it possible it’'s not causing the naming classes to throw an exception?
Perhaps try a command line ldapsearch with the same simple bind credentials and base dn and see if the ldap server lets you in - if so it’'s an ldap server configuration issue.
Rob
Hi areobe,
we’‘re using SUN’‘s (Netscape) iPlanet Directory Server and yes, maybe it’'s an issue with this server or our configuration.
Can you explain a bit more precisely how to test with the cli and ldapsearch?
Regards,
Frank
Hi Frank,
sure, from either a linux box or on the server itself your should have a utility called ldapsearch. With linux it typically comes in the openldap or openldap-client package.
The openldap search client is used like the following, sun’‘s may have different option flags, but it’'s functionality should be equivilent:
ldapsearch -x -H “ldap://127.0.0.1” -b “dc=yourdomain,dc=com” -s “sub” -D “uid=jiveuser,ou=users,dc=yourdomain,dc=com” -W “(&(uid=someuser)(objectclass=posixaccount))”
-x is a simple bind
-H host uri, you can replace it with ldaps://127.0.0.1 to use ssl if your server is configured to use it.
-b is your base dn
-s scope
-D is your bind dn
-W prompts for a password
Leave off the -W to try a bind without a password
If I specify a bind dn without a password I get:
ldap_bind: Server is unwilling to perform (53)
additional info: unauthenticated bind (DN with no password) disallowed
wrong password:
ldap_bind: Invalid credentials (49)
man ldapsearch
ldapsearch -h for options
Hope this helps,
Rob
Hi Rob,
is it correct that you use the user jiveuser to get information from LDAP? Our LDAP is configured for anonymous access so everybody can do a ldapsearch uid=user and get’'s the information for this user.
If I add a -W to the ldapsearch uid=user it asks me for a password but no matter what I enter LDAP accepts it (I think it’'s because of the anonymous access).
Maybe I have that issue with Messenger accepting every user without correct password because our LDAP is configured for anonymous access … let’'s see what Matt finds out.
Regards,
Frank
OK, looks like the issue is the way your ldap server is configured for authentication.
Our ldap server is also configured for anonymous access to lookup and read certain attributes. In the messenger conf I don’'t specify an adminDN which in turns binds the lookups to the anonymous user. The jiveuser was an example to query the ldap server.
When you login to Messenger the server has to do an ldap search based on the username the XMPP client provides to match a single dn to bind to to validate authentication.
If you’‘re not getting an error if you’'re specifying a bind dn and the ldap server is accepting any password, something is seriously screwy with your ldap server.
You can have anonymous and simple binds confgured at the same time, it’'s very common to do so e.g. anonymous read access to email and address attributes, but not userPassword.
I was going say it’‘s probably an acl issue with your ldap server, but I think it’'s deeper than that. Take a look at how the server authenticates users. does it use Pam?
I’‘m not familiar at all with the Sun directory server, so I can’'t provide any more help there.
You could always export your directory into an ldif file and import that into OpenLdap at least to compare behaviors.
Regards,
Rob
I succesfully configured the jive messenger to authenticate against Active Directory.
Then I saw this bug and, obviously, went and tried to reproduce it. Here´s what I found in my setup:
If i do not use an adminDN username/passwd in the jive-messenger.xml, i can not login to the server, with or without the correct password and blank password as well.
if I specify an adminDN username/passwd in the jive-messenger.xml, then i can login to the jive-messenger, both with a correct password or blank password. If i type anything as my password then i am not able to login.
It seems that the jive messenger only checks the user passwd against the ldap server if i type something.
btw, i´m using version 2005-02-27 from the nightly builds.
best regards
Fabio
I’‘m pretty sure that AD isn’‘t configured out of the box with anonymous binds which explains why you wouldn’‘t be able to log on to the server at all. Messenger wouldn’‘t be able to look up the user’'s dn.
The second issue might be the way AD handles binds without a password. Not being familiar with the workings of AD, but with my experience with windows networking and domains in general, windows behavior could demote a bind without a password to guest access.
In similar fashion to the above posts, try the ldapwhoami utility when passing your bind credentials (or lack thereof). See if you get bound as the user you are attempting to bind as or get mapped to the guest account or similar.
Rob
Rob,
I copied the code out of LdapManager and pasted it
into a simple main class to do a stand alone test and
got an exception every time I should have.
could you send me this file(s) so that I can test my environment with that class? I tried to copy the content from LdapManager as you did but I get some errors and I’'m not that Java experienced to solve them myself.
My E-Mail Adress: fbn@thelogic.org
Or maybe Matt will allow you to upload files to the forum
Regards,
Frank
I’‘m not able to reproduce this behavior. I’'ve tried against JM 2.1.1 and the CVS nightly from 2005-03-04. It works as it should when authenticating against our Active Directory instance.
Sounds like a problem with your LDAP server.
I’‘m not able to reproduce this behavior. I’'ve tried
against JM 2.1.1 and the CVS nightly from 2005-03-04.
It works as it should when authenticating against
t our Active Directory instance.
Sounds like a problem with your LDAP server.
Which client are you using? in my setup i tried Exodus and Psi and both don’'t allow empty passwords. But pandion does.
I was testing with BuddySpace. I can’'t even get Pandion to login at all even though other clients work.
Here you go, just a quick and dirty cut and paste to test a simple bind non-ssl:
pass your user dn and password on the command line. Use empty quotes for an empty password.
import java.util.*;
import javax.naming.*;
import javax.naming.directory.*;
import java.net.*;
public class TestBind {
final static String host = “”;
final static String port = “389”;
public static void main(String[] args) {
DirContext ctx = null;
String baseDN = “”;
String userDN = args[0];
String password = args[1];
try {
// See if the user authenticates.
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, “com.sun.jndi.ldap.LdapCtxFactory”);
env.put(Context.PROVIDER_URL, getProviderURL(baseDN));
//if (sslEnabled) {
// env.put(“java.naming.ldap.factory.socket”, “org.jivesoftware.util.SimpleSSLSocketFactory”);
// env.put(Context.SECURITY_PROTOCOL, “ssl”);
//}
env.put(Context.SECURITY_AUTHENTICATION, “simple”);
System.out.println("Binding as: " +userDN + “,” + baseDN);
env.put(Context.SECURITY_PRINCIPAL, userDN + “,” + baseDN);
env.put(Context.SECURITY_CREDENTIALS, password);
ctx = new InitialDirContext(env);
System.out.println("… context created successfully, returning.");
System.exit(0);
}
catch (NamingException ne) {
System.err.println("No bind: " + ne.getMessage());
}
}
private static String getProviderURL(String baseDN) {
String ldapURL = “”;
try {
// Create a correctly-encoded ldap URL for the PROVIDER_URL
ldapURL = “ldap://” + host + “:” + port + “/” +
URLEncoder.encode(baseDN, “UTF-8”);
// The java.net.URLEncoder class encodes spaces as +, but they need to be %20
ldapURL = ldapURL.replaceAll("
+", “%20”);
}
catch (java.io.UnsupportedEncodingException e) {
// UTF-8 is not supported, fall back to using raw baseDN
ldapURL = “ldap://” + host + “:” + port + “/” + baseDN;
}
System.out.println("ldapURL = " + ldapURL);
return ldapURL;
}
}
Hi Areobe,
I’‘ve tested our LDAP environment with your application and that’'s the result:
java TestBind uid=dettcx21,ou=people,ou=tettnang,c=de wrongPassword
ldapURL = ldap://dettldap.tt.de.ifm:389/o%3Difm
Binding as: uid=dettcx21,ou=people,ou=tettnang,c=de,o=ifm
No bind: LDAP: error code 49 - Invalid Credentials
-> good
java TestBind uid=dettcx21,ou=people,ou=tettnang,c=de rightPassword
ldapURL = ldap://dettldap.tt.de.ifm:389/o%3Difm
Binding as: uid=dettcx21,ou=people,ou=tettnang,c=de,o=ifm
… context created successfully, returning.
-> good
java TestBind uid=dettcx21,ou=people,ou=tettnang,c=de “”
ldapURL = ldap://dettldap.tt.de.ifm:389/o%3Difm
Binding as: uid=dettcx21,ou=people,ou=tettnang,c=de,o=ifm
… context created successfully, returning.
-> bad
I don’‘t know much about LDAP and how authentication with LDAP works, is it correct that Messenger gets the requested user’'s password back from LDAP or is LDAP just responding with something like true/false oder authenticated/not authenticated ?
Regards,
Frank
Hi fbn,
Messenger performs a bind operation on the ldap server to verify authentication.
This means it’'s up to your ldap server to authenticate correctly using the supplied credentials.
As the test shows, your ldap server is clearly allowing binds with a dn, but no password. Bad.
Check your ldap server’'s security, acls and bind options.
Try the ldapwhoami command and try the bind with blank password. It may authorize you as a guest user. If ldapwhoami returns with a different dn than the one you requested to bind as, then that’'s the issue. If that is the case, it may be necessary for Messenger to perform the same verification.
Regards,
Rob
Hey Rob,
now I have my own little LDAP server with OpenLDAP (our productive server is SUN/Netscape iPlanet) and did the same tests.
First, with anonymous authentication disabled everything is fine (“Unwilling to allow anonymous bind with on-empty DN”), but if I enable it I get the same situation as described bevore (access with empty password).
This is the configuration section of OpenLDAP:
Sample access control policy:
Allow read access of root DSE
Allow self write access
Allow authenticated users read access
Allow anonymous users to authenticate
Directives needed to implement policy:
access to dn.base="" by * read
access to *
by self write
by users read
by anonymous auth
If these lines are enabled users will get authenticated with an empty password.
Disabling anonymous access on our productive environment is impossible because many other services would not be able to work with LDAP anymore.
I don’'t understand why Messenger performs a bind operation on the ldap server to verify authentication instead of checking that the password provided by the user is the same in the directory …
Maybe the easiest way would be to check if the password is empty and if so don’'t let the user log in to Messenger. What about that idea?
Regards,
Frank
PS: I’'ve tried to check with ldapwhoami if the server authorizes me as a guest but I always get some error messages from it.
I don’'t understand why Messenger performs a bind
operation on the ldap server to verify authentication
instead of checking that the password provided by the
user is the same in the directory …
It’'s not possible to check to see if the password values are the same in a generic way.
Maybe the easiest way would be to check if the
password is empty and if so don’'t let the user log in
to Messenger. What about that idea?
Yeah, that might be the best default behavior. I don’'t think that many people actually have blank passwords so it should be fine.
-Matt