Wildfire with ActiveDirectory LDAP hangs the wildfire server

joel_schaubert · March 13, 2006, 10:20pm

First off, thanks to everyone who’'s answering problems here, in less than 4 hours I was able to get wildfire configured to use active directory by looking at answers to other people questions.

Now I have a system where its a very large active directory with lots and lots of users.

I do a tail -f debug.log | grep sAMAccountName to watch my login.

Right after my authentication is done and hits the logs, tons of other authentications start to pour into the logs. This is after I have removed the enableDebug from within the tag.

The wildfire server seems to get so overloaded that /etc/init.d/wildfire stop is not able to stop it. I have to reboot. This was true both with and without the ldap.enableDebug tag. Here are my current ldap/debugging/database setttings.

/code

Thanks,

Joel Schaubert

Message was edited by: bikeracer4700

LG1 · March 13, 2006, 10:26pm

Hi Joel,

would you please edit your post and put the file contents between and ?

LG

joel_schaubert · March 13, 2006, 10:30pm

Done.

Bummer that there’'s no easy way to get the angle brackets and other parts of the xml to come through. Neither pre nor code tags did the trick.

Joel

Win_Myo_Htet · March 13, 2006, 10:41pm

joel,

I think, you have not done it right yet.

lots and lots of code /code

It should be like that.

regards,

wmhtet

LG1 · March 13, 2006, 10:42pm

Well, for me it looks like this using the code tag. I hope that bold[/b], italic[/i] or underline[/u] (left of spell check) are working for you?

/code

joel_schaubert · March 13, 2006, 10:59pm

Oh now that’'s just sweet lookin.

I was trying to use html style angle backets around the word code.

Using squares is much better, thanks.

Patrick_Siu · March 14, 2006, 1:43am

If your config is what you used to start, may I say that your adminDN might contribute to the problem. You are entering the user name, not the distinguished name (which should be of same format[/i] of your baseDN).

joel_schaubert · March 14, 2006, 6:35pm

I wasn’'t able to get the adminDN to work that way. I tried several combinations based on

CN=Schaubert, Joel;OU=OU_MYCOUsers;DC=myco;DC=com

joel_schaubert · March 14, 2006, 8:34pm

After a few hours of adding more Log.debug messages to pin down what is happening, here is what I’'ve learned.

The code call is coming in through

net/SASLAuthentication.java doPlainAuthentication()

auth/AuthFactory.java authenticate()

ldap/LdapAuthProvider.java authenticate()

Now here is where it gets strange.

I can track the code via debug messages as running once through the steps in LdapAuthProvider.authenticate(). So at the end of this routine I added a log message saying its done.

I can see this message in the logs, AND my client gets authenticated and hooks up.

BUT THEN, after a short pause (about 2-3 seconds) the log file takes off again and it seems that LdapManager.findUserDN(username); starts going mad and just checking out one user after another walking through the entire LDAP directory.

Now the code in LdapAuthProvider.authenticate() says something about needing to search all the subtree’'s of the baseDN for the username.

try {

// The username by itself won’'t help us much with LDAP since we

// need a fully qualified dn. We could make the assumption that

// the baseDN would always be the location of user profiles. For

// example if the baseDN was set to “ou=People, o=jivesoftare, o=com”

// then we would be able to directly load users from that node

// of the LDAP tree. However, it’'s a poor assumption that only a

// flat structure will be used. Therefore, we search all subtrees

// of the baseDN for the username. So, if the baseDN is set to

// “o=jivesoftware, o=com” then a search will include the “People”

// node as well all the others under the base.

Log.debug("LdapAuthProvider getting userDN "+userDN);

userDN = manager.findUserDN(username);

Log.debug("LdapAuthProvider authenticating userDN "+userDN);

// See if the user authenticates.

if (!manager.checkAuthentication(userDN, password)) {

throw new UnauthorizedException(“Username and password don’'t match”);

}

catch (Exception e) {

throw new UnauthorizedException(e);

}

// If cache is enabled, add the item to cache.

if (authCache != null) {

authCache.put(username, StringUtils.hash(password));

}

Log.debug("LdapAuthProvider DONE authenticating userDN "+userDN);

}

/code

But what I can’'t understand is the following

why do all these additional user lookups happen AFTER my user is already done being authenticated
why is LdapManager.findUserDN(username) getting called for all these other users in the directory
where are these calls being fired from? I don’'t see any loops in LdapAuthProvider.authenticate() that look like they could be the causes of the extra calls. Could there be possible threading problems with one of the ldap interface libraries?

Here are the logs that come out, you will see my user being authenticated. Then things go crazy and we start walking all users

2006.03.14 10:29:00 Connect Socket[addr=/10.23.80.143,port=45351,localport=5222] 2006.03.14 10:29:00 SASL calling AuthFactory authenticate

2006.03.14 10:29:00 AuthFactory 1 calling authenticate

2006.03.14 10:29:00 LdapAuthProvider getting userDN null

2006.03.14 10:29:00 Trying now, to find a user’'s DN based on their username. sAMAccountName: jschaube, Base DN: OU=OU_mycoUsers;DC=corp;DC=myco;DC=com…2006.03.14 10:29:00 Creating a DirContext in LdapManager.getContext()…

2006.03.14 10:29:00 Created hashtable with context values, attempting to create context…

2006.03.14 10:29:00 … context created successfully, returning.

2006.03.14 10:29:00 Starting LDAP search…

2006.03.14 10:29:01 … search finished 2006.03.14 10:29:01 LdapAuthProvider authenticating userDN CN=Schaubert, Joel,OU=OU_2014ACE,OU=OU_0102Technology,OU=OU_0001myco

2006.03.14 10:29:01 In LdapManager.checkAuthentication(userDN, password), userDN is: CN=Schaubert, Joel,OU=OU_2014ACE,OU=OU_0102Technology,OU=OU_0001myco…

2006.03.14 10:29:01 Created context values, attempting to create context…