powered by Jive Software

Possible Bug: Users are able to login without password (CVS & LDAP)

Hi,

today I found a strange behavior of Messenger, CVS version from today:

Every LDAP user can log in to Messenger without a password!

  1. Log in with LDAP user and correct password -> success

  2. Log in with LDAP user and no password (empty) -> success !!!

  3. 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:

  1. Sample access control policy:

  2. Allow read access of root DSE

  3. Allow self write access

  4. Allow authenticated users read access

  5. Allow anonymous users to authenticate

  6. 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