Hi there,

I'm having a strange issue where the module is correctly identifying users that try to log in but fails to create the accounts in Drupal.

The only error available is, "Failed to find or create [user] on logon," where user is the DN for the person attempting to log in.

Any assistance with this would be greatly appreciated.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

DenimTiger’s picture

Version: 7.x-2.0-beta4 » 7.x-2.x-dev
johnbarclay’s picture

Title: Unable to create user accounts on logon » LDAP User: Unable to create user accounts on logon
Bob_Vdl’s picture

FileSize
268.59 KB

I'm having the same issue. While I can add the user by using the "Test LDAP User Configuration" menu, I cannot get the account created when users try to log on.

I'm able to go through all the user attributes by testing user or user DN at the server test screen. However, I'm not able to retrieve group info by using the group DN.

DenimTiger’s picture

Running through logs after updating to the 7.2 dev version released April 10th reveals the following when a user attempts login:

1) Beginning authentification....

2) Existing Drupal User Account not found. Continuing on to attempt ldap authentication

3) Trying server [servername] where bind_method = 1

4) Success at connecting to [servername]

5) ldap_search() call: base_dn: OU=[group],DC=[local],DC=org, filter = (samaccountname=[name]), attributes: , attrsonly = 0, sizelimit = 0, timelimit = 0, deref = , scope = 3

6) Authentication result id=0 auth_result=6 (unknown error: 6)

7) ldap_search() call: base_dn: OU=[group],DC=local,DC=org, filter = (samaccountname=[name]), attributes: usercertificate,dn,mail,,cn,samaccountname, attrsonly = 0, sizelimit = 0, timelimit = 0, deref = , scope = 3

8) failed to find associated ldap entry for username in provision.

9) Failed to find or create [name] on logon.

10) Login attempt failed for [name].

Hopefully this helps in narrowing down the issue.

Bob_Vdl’s picture

Any progress on this issue? I'm currently moving my Drupal installation from my test environment to a production server, and I'm experiencing the same problem. Looking at the detailed log shows the exact same problem as DenimTiger is having. If there is any way I can help by providing some kind of additional log file, let me know.

Is there a way to batch create all the LDAP users as Drupal users? This could be a workaround until a fix for this issue is found.

Bob_Vdl’s picture

On my configuration, the issue was caused by using cn for the AccountName attribute. Simply removing the value and letting it default to the AuthName attribute solved the issue.

I have no idea why I put cn as a 'unique account name'. I guess I saw accountname and figured it had to be the user's full name.

I'm not sure why it caused an error, since no user with the same accountname already existed.

Hopefully this solves DenimTiger's issue as well.

haydeniv’s picture

Status: Active » Fixed

You are correct. If he removes cn from AccountName attribute that should fix his problem. I have a working active directory setup and I leave that value blank. Marking this as fixed. Bob_Vdl can reopen if still having issues.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

beardedgeek’s picture

Issue summary: View changes

I'm experiencing the exact same issue and removing a value from AccountName did fix the issue for me, however this solution isn't ideal for out setup.

We use multiple domain controllers acrross multiple networks to authenticate and login. If we leave this field blank as the solution above suggests, it creates users in drupal where their username is the same as their AD login name.

Users on different domains can and will have the same username, so user1 from network1 logs in, then user1 from network2 logs in and is the same person in drupal.

I need the AccountName to be set as the users 'mail' field in AD, as this will always be unique, but this causes the error. What's the point in having this field, if we can't put anything in it or use it?

beardedgeek’s picture

Status: Closed (fixed) » Needs review
oenie’s picture

Status: Needs review » Active

I'm reopening this issue, due the following:

When setting up your drupal configuration with different Authname and AccountName attributes this still doesn't work.
Which means whenever you want to use a different Drupal username than the login you want to use for your application.

I think the problem is in the following piece of code (ldap/ldap_authentication/ldap_authentication.php.inc, around line 458) :

// don't pass in ldap user to provisionDrupalAccount, because want to requery with correct attributes needed
// this may be a case where efficiency dictates querying for all attributes
$drupal_account = $auth_conf->ldapUser->provisionDrupalAccount(NULL, $user_edit, NULL, TRUE);

By not including an LDAP object, the ldap module is checking for an LDAP user, but is incorrectly using the Accountname value in the Drupal LDAP server configuration and then checking that with the Authname attribute in the LDAP server.

Of course this will never yield a valid LDAP object, because we are using two different values for the attributes.

The problem is solved when you add in the LDAP object, since then it will use the correct object that got returned while checking your login credentials ( Authname Attribute ).

So something like this:

$drupal_account = $auth_conf->ldapUser->provisionDrupalAccount(NULL, $user_edit, $ldap_user, TRUE);

The comment on why not to pass in the LDAP user is pretty vague to me. Anyone that can shed a light on that ?

beardedgeek’s picture

I've just made the change you suggested, and it's now working. Is this a proposed fix? I'll do some more testing tomorrow, but looks good so far!

oenie’s picture

I've just made the change you suggested, and it's not working

I suppose you mean that it IS working ?

It could be a fix, but not until someone can shed a light on my question as to why exactly the LDAP user is omitted in the current code. If we would introduce this fix, there might be other problems that rearise.

There's nothing keeping us from using a temporary patch to our own systems while we wait till someone can answer the question in comment #11

JurriaanRoelofs’s picture

For me the fix suggested in #11 also solved the problem of new account creation failing. Some minimal testing showed no side effects to old accounts, I'll be monitoring the logs in the coming week to see if all is well.

johnbarclay’s picture

Title: LDAP User: Unable to create user accounts on logon » LDAP User: Account creation issue with different Authname and AccountName
Category: Support request » Bug report
Status: Active » Reviewed & tested by the community

Thanks. This seems reasonable. I'll commit #11 this next time I do commits.

oenie’s picture

johnbarclay, I would like to underline the last paragraph in post #1962232-11: LDAP User: Account creation issue with different Authname and AccountName
Although my code change seems to work, I'm 'ignoring' the comments above the line mentioned:

// don't pass in ldap user to provisionDrupalAccount, because want to requery with correct attributes needed
// this may be a case where efficiency dictates querying for all attributes

I did a git blame, turns out to be some code inserted while you did some refactoring (commit 048aa742).
Was/is your comment relevant ? Just to make sure ...

If I would provide a patch with the change, i'm assuming the comment should be removed , because it's no longer true and thus irrelevant.

Your thought ?

haydeniv’s picture

cdmo’s picture

I had the same problem, fix suggested by @oenie in #11 solved the problem. I'm using 7.x-2.0-beta8, so this change hasn't been committed yet to the more stable branch, fwiw.

Thanks!

dgtlmoon’s picture

Status: Reviewed & tested by the community » Needs review

What do you think about what's here in the comments? you're passing the LDAP user across but the comments say don't

     // don't pass in ldap user to provisionDrupalAccount, because want to requery with correct attributes needed
     // this may be a case where efficiency dictates querying for all attributes
-    $drupal_account = $auth_conf->ldapUser->provisionDrupalAccount(NULL, $user_edit, NULL, TRUE);
+    $drupal_account = $auth_conf->ldapUser->provisionDrupalAccount(NULL, $user_edit, $ldap_user, TRUE);
oenie’s picture

This is basically what I mentioned in comment #11 and the main reason why I didn't attach a patch. The committer didn't answer my question though... I'll try to get in touch with him and see if I can get a reply and maybe get this patch committed

dgtlmoon’s picture

I have commit access if you can build a patch

oenie’s picture

hi @dgtlmoon,

The patch listed in #17 is the one i would have submitted, but committing it doesn't solve the problem about why the comment was inserted.
I would love to hear @johnbarclay 's take on what it actually means.
We're not really seeing side-effects but we never know if there might be a specific reason that might break with this approach.

mayank_kanungo’s picture

I have the same problem "Failed to find or create [user] on logon.", and solution proposed in #11 is working for me.

Thanks Oenie :)

Csaba Mezei’s picture

Solution in #11 worked fine together with patches from #1430800: LDAP Authorization: Need ability to select multiple Servers in single Authorization consumer configuration
Thanks Oenie

kugel’s picture

Solution in #11 worked fine with 7.x-2.0-beta11. Why not merge it? Are there any side-effects?

grahl’s picture

Status: Needs review » Needs work
grahl’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 17: 1962232-17-different-authname-and-accountname.patch, failed testing.

oenie’s picture

@kugel : The problem, as stated in a few comments before, is that we change code that might have side effects that we don't know of.
Apparently @johnbarclay mentioned a vague reason in a comment before the block of code.
Never had any response on whether is it still relevant or not.
If not, please commit :)

grahl’s picture

Status: Needs work » Needs review

  • grahl committed 8be7060 on 7.x-2.x authored by haydeniv
    Issue #1962232 by haydeniv, oenie: LDAP User: Account creation issue...
grahl’s picture

Status: Needs review » Fixed

No one reported problems, committing.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.