efa-project.org

Hi there. I've been using EFA for a small office for awhile and I've had great success with integrating it with a small MS Active Directory domain. I recently updated it (today, 5/3/2016) from 3.0.0.8 to 3.0.1.0.

After some tweaking I was able to get 3.0.1.0 installed and it carried over my changes perfectly to /var/www/html/mailscanner/conf.php (and I checked /var/www/html/mailscanner/functions.php to be safe) but AD users are just given a 'Bad Username or Password' when attempting to log in. Checking the security logs on the domain controller shows no attempt to authenticate to the domain for these attempts, which leads me to believe the authentication attempt isn't making it off of the EFA server. I double checked that php-ldap was still installed, and it is (php-ldap-5.3.3-46.el6_7.1.x86_64).

I've been looking on the EFA server for where authentication failures would be logged but haven't been able to find any references to the accounts under /var/log. Where could I look on EFA to see if authentication attempts are being made? I've looked through /var/log/messages (and even ran a realtime tail -f while attempting to authenticate), /var/log/httpd, etc... pretty much everything under /var/log. Am I missing something? 3.0.0.8 was working just fine, and the EFA server isn't externally accessible so I'm considering restoring from backup.

Perhaps you could provide a bit more information?

How do you think you are integrating with Active Directory?

I had the same issue going from 3.0.0.9 to 3.0.1.0
Initially I changed define('USE_LDAP', '1'); to define('USE_LDAP', '0');
Logged in as admin but still couldn't login as a user so I changed the user's password in EFA and could then login.
Then again changed define('USE_LDAP', '0'); to define('USE_LDAP', '1');
Initially I could not login as the user but then I restarted the MailScanner service (may be a red herring)
I can now login again but I am not convinced that the LDAP integration is working as another user could not login until I manually reset their password in EFA.

pdwalker wrote:Perhaps you could provide a bit more information?

How do you think you are integrating with Active Directory?

I'm using the information in the release notes to authenticate users to Active Directory (via LDAP). It's been working for several months on 3.0.0.8.

I've restored from backup to 3.0.0.8 and all is now as it should be. Just a heads up for anyone planning to update to 3.0.1.0.

colin wrote:I had the same issue going from 3.0.0.9 to 3.0.1.0
Initially I changed define('USE_LDAP', '1'); to define('USE_LDAP', '0');
Logged in as admin but still couldn't login as a user so I changed the user's password in EFA and could then login.
Then again changed define('USE_LDAP', '0'); to define('USE_LDAP', '1');
Initially I could not login as the user but then I restarted the MailScanner service (may be a red herring)
I can now login again but I am not convinced that the LDAP integration is working as another user could not login until I manually reset their password in EFA.

This sounds like the same issue I ran into. I did quite a bit of troubleshooting using multiple accounts in different scenarios, such as creating a new user in AD (on first successful log in to EFA the user normally is created in EFA) and attempting to log in with users that already had existing accounts. I never saw any authentication attempts to the AD domain controller, so I suspect something is funny with LDAP on EFA after the upgrade. I didn't tinker with the USE_LDAP flag myself, nice job thinking to troubleshoot using it

I've since restored 3.0.0.8 from backup and everything is back to normal. My plan is to try it again in a couple of weeks and see if it's resolved.

I'm going to leave this here for future reference (I had checked this earlier as well for those wondering):

How to integrate E.F.A with Active Directory on 3.0.0.9
viewtopic.php?t=1484

Please make sure that the following is changed

shawniverson wrote:Please make sure that the following is changed

Code: Select all

define('USE_LDAP',         '1');

Code: Select all

define('USE_LDAP',         true);

Do you mean that '1' should be changed to true without the single quotes?
I tried that and it didn't appear to make a difference. Also tried it with the single quotes.

Are there any logs on EFA that show LDAP authentication attempts?

OK a bit of progress. I changed the code to:
define('USE_LDAP', true);

And a packet capture shows that it is communicating but the return is:

LDAPMessage searchResDone(2) success [0 results]

If I create a new user in Active Directory and assign a mailbox, it fails to login using that user and no user is created in EFA.

Hope this helps.

Disappointingly no reply. This is a show stopper for me.

I can't upgrade any of my customers until this is fixed. Any pointers?

Do you have LDAP_AD_COMPATIBILITY enabled?

Also, I don't understand where you are having MailWatch auto create users. This is not a feature present in EFA. Do you have some kind of helper script doing this task?

Yes that is enabled. Maybe the user gets created at first login and as I cant login (Bad Username or Password), it doesn't get created. Either way I get that message (Bad Username or Password) when I attempt to login.

Packet capture is showing that it is communicating with AD. So I guess it is EFA receiving/interpreting the info that is not working.

Are there any logs that I can look at on the EFA server?

I have always had to create users first before logging in...

Have you tried logging in as an admin and creating a user to match one in AD?

Yes it works if I create the user but how is that AD integration?

The LDAP integration is only for password lookups. The user has to exist for it to work. MailWatch currently doesn't do this, but it would make for a great feature request. I know several users have created a script to populate the users in MailWatch from LDAP, and it is likely lurking in this forum.

OK. Not sure how to test if this is working then. If I change the password in EFA for a user, when I login to EFA it will only work if I use that password and not the one in AD. I would have thought that it should lookup AD at login and use that mechanism to authenticate the user. I am sure something is wrong.

Yeah you shouldn't have to mess with the local password in MailWatch with LDAP enabled.

Here's my setup...
Example User...

Username: someuser@example.com
Name: someuser@example.com

Login...

someuser (without domain)
somepassword

Yeah that looks pretty close to my configuration, the only difference being that I do not have the line:
define('LDAP_SSL', true);
and my port number is 389
If I change to you config I get:
Could not search
So I know it is working as far as looking up AD is concerned.
I tried logging in with both someuser@example.com (which is how I used to login before the update) and someuser but neither work.
The only other difference I had was with the Name being someuser and not someuser@example.com. The Username was always someuser@example.com. I have changed the name to someuser@example.com but still no joy.

Are you on 3.0.1.1 or 3.0.1.0?

I was on 3.0.1.0 when it first went wrong. I updated to 3.0.1.1 as soon as it released,

Which email field are you using in AD? "mail" or "proxyaddress" ?

Mail

I see why the full username@domain is failing....there's a bug in functions.php...I am working through it right now.

However, you should still be able to authenticate using just the SamAccountName. This has me very puzzled.

Please try this and report back.