LDAP Provisioning and LDAP Auth configuration
mattlane - December 28, 2008 - 20:41
| Project: | LDAP provisioning |
| Version: | 6.x-1.0-alpha2 |
| Component: | User interface |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
I am having trouble using LDAP Auth and LDAP provisioning together; it seems I can only get one to work at a time. when I set the UserName Attribute in my server to 'sAMAccountName', logons work fine. However, provisioning fails. By setting the provisioning module to debug I get
sAMAccountName=newuser,OU=orgunit,DC=domain as the DN. This is wrong, as the correct string should be CN=newuser,OU=orgunit,DC=domain
If I change the UserName attribute in the server to 'CN', provisioning works fine, but authentication fails, of course.
Is there some other attribute I should be changing? Thanks in advance.
#1
UserName Attribute sets which ldap attribute is in the DN. Why do you want to create a new user as a one DN, "CN=newuser,OU=orgunit,DC=domain", but to authenticate as other DN, "sAMAccountName=newuser,OU=orgunit,DC=domain"? Or does it have anything to do with the Active Directory specifics? I'm using openldap and am not very familiar with the AD.
#2
I think it does have to do with AD specifics. If I try and add a user with "sAMAccountName=newuser,OU=orgunit,DC=domain" The AD generates the following error:
Error value: 00002073: NameErr: DSID-03050AAB, problem 2005 (NAMING_VIOLATION), data 0, best match of: 'sAMAccountName=newuser,OU=orgunit,DC=domain'
If I change the UserName attribute to 'CN' it works correctly.
#3
I also have this problem in version 6.x-1.0-beta1. I'm running Microsoft's Active Directory Application Mode (ADAM) as my LDAP server.
The problem is that it seems that typically user objects in ADAM have DNs like CN=Geoffrey Hing,OU=CRL Users,O=CRL,C=US. I'm sure this can be changed, but this is the way the documentation suggests that you set things up. You can then set the uid attribute of the user object with that DN to your Drupal username. As mattlane reported, this works fine for authentication using ldapauth.
The problem occurs when trying to get things working with this schema and LDAP provisioning.
In ldapprov.module:_ldapprov_create_user(), the $name_attr variable is set around line 1841 from the settings that the LDAP Authentication module uses (in my configuration, $_ldapprov_ldap->getOption('user_attr') returns 'uid') :
$basedn = $_ldapprov_ldap->getOption('basedn');
$name_attr = $_ldapprov_ldap->getOption('user_attr') ? $_ldapprov_ldap->getOption('user_attr') : LDAP_DEFAULT_USER_ATTRIBUTE;
if ($ret = $_ldapprov_ldap->search($basedn, '('. $name_attr .'='. $name .')', array($name_attr)) || user_load(array('name' => $name))) {
$i = 1;
while ($ret = $_ldapprov_ldap->search($basedn, '('. $name_attr .'='. $name . $i .')', array($name_attr)) || user_load(array('name' => $name . $i))) {
$i++;
}
$name = $name . $i;
}
Then, around line 1861, the $dn variable is set based on $name_attr and this is the value eventually passed to ldap_add.
$dn = $name_attr .'='. $name .','. $basedn;As a quick test, I was able to get LDAP account creates to work by modifying this line to read:
$dn = 'CN' .'='. "$first_name $last_name" .','. $basedn;AD users may make a similar hack in order to get things up and running, but a more ideal fix would be a separate setting that lets you specify a different "new user" attribute rather than just using the "user attribute" from the ldapauth module.
I hope this helps,
Geoff