When we create a user for Microsoft Active Directory, the user creation works very well but the user is not able to log into the system. Can anyone guide me to resolve this?

CommentFileSizeAuthor
#1 user login failure.JPG80.94 KBdeven_
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

deven_’s picture

FileSize
80.94 KB

Screen shot of the above problem is attached here.

wottam’s picture

Same thing happening here, unfortunately. The account is disabled by default and the password returned by the module does not match the one in the server.

deven_’s picture

Well, from my trials, I have found how to make user enabled. Follow the steps below:

Create a custom field of textfield type in user profile with Title: Account Enable with a field name of profile_accountcontrol. While creating the field, select "Visible in user registration form."

Then after that, in LDAP Integration Data module, map it to userAccountControl ldap attribute.

When you create a new user, give a value of 544 in the Account Enable text-box... this will make the user enabled.

But still, the password problem remains. The user can not log into the system. I have found that the password which drupal sends to Active Directory is the same but still, when user tries to log in, the login is rejected.

But, if I go to Active Directory and reset user password, then the user is able to log in.

Can anyone help?

bryan kennedy’s picture

Issue tags: +password, +user login

I am pretty sure the problem here is that LDAP Provisioning expects the password to be in the userPassword attribute, which is correct for most LDAP systems, while Active Directory needs the password to live in unicodePwd, while userPassword is an alias.

I'm looking into the module code to see if there is an easy patch. There are several issues with LDAPProvisioning and Active Directory. Unfortunately I think it all boils down to the fact that this module isn't ready for production use with Active Directory just yet. It's really smooth with an OpenLDAP, but needs some more refinement for the "special" bits in Active Directory.

bryan kennedy’s picture

Status: Active » Needs review
Issue tags: +unicode

I don't have a patch yet, but do have a fix if you are in a pinch. The passwords aren't working because they need to be stored as unicode in Active Directory.

If you are writing to Active Directory your LDIF attribute for the password should look something like this:
unicodePwd: !pass
instead of
userPassword: !pass

But, if you set it up that way, the account creation will likely fail, b/c AD will reject entires into unicodePwd that aren't unicode. So, I just hacked up the ldap_prov module to change the password to unicode before passing it to the ldap_auth module's account creation class. Here's my bit of hackery, starting around 1854 in ldap_provisioning.module

$pass_ldap = $_ldapprov_ldap->getOption('encrypted') ? '{md5}'. base64_encode(pack('H*', md5($pass))) : $pass;
/**
 * CUSTOM
 * Converting the password to unicode so that it will properly write to the Active Directory
 * unicodePwd field.
 */
$pass_ldap = "\"" . $pass_ldap . "\"";
$len = strlen($pass_ldap);
$new_pass_ldap = "";

for($i=0;$i<$len;$i++) {
  $new_pass_ldap .= "{$pass_ldap{$i}}\000";
}
...
$ldap_vars['!pass'] = $new_pass_ldap;

...with a little help from my friends.

So now, I guess the question is how do we make this conditional for use in the module.

In other words, what is the best way to denote that your LDAP connection is to an AD system? Should it be part of LDAP provisioning or part of LDAP authentication?

Thoughts?

deven_’s picture

adldap (http://adldap.sourceforge.net) is a product written in PHP which allows to create users in Active Directory, change their password... etc. It requires SSL connection to Active Directory. Please read at http://adldap.sourceforge.net/wiki/doku.php?id=ldap_over_ssl about the same.