Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#17 | 1962232-17-different-authname-and-accountname.patch | 897 bytes | haydeniv |
#3 | User_Creation_Config.png | 268.59 KB | Bob_Vdl |
Comments
Comment #1
DenimTiger CreditAttribution: DenimTiger commentedComment #2
johnbarclay CreditAttribution: johnbarclay commentedComment #3
Bob_Vdl CreditAttribution: Bob_Vdl commentedI'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.
Comment #4
DenimTiger CreditAttribution: DenimTiger commentedRunning 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.
Comment #5
Bob_Vdl CreditAttribution: Bob_Vdl commentedAny 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.
Comment #6
Bob_Vdl CreditAttribution: Bob_Vdl commentedOn 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.
Comment #7
haydeniv CreditAttribution: haydeniv commentedYou 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.
Comment #9
beardedgeek CreditAttribution: beardedgeek commentedI'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?
Comment #10
beardedgeek CreditAttribution: beardedgeek commentedComment #11
oenie CreditAttribution: oenie commentedI'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) :
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:
The comment on why not to pass in the LDAP user is pretty vague to me. Anyone that can shed a light on that ?
Comment #12
beardedgeek CreditAttribution: beardedgeek commentedI'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!
Comment #13
oenie CreditAttribution: oenie commentedI 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
Comment #14
JurriaanRoelofs CreditAttribution: JurriaanRoelofs commentedFor 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.
Comment #15
johnbarclay CreditAttribution: johnbarclay commentedThanks. This seems reasonable. I'll commit #11 this next time I do commits.
Comment #16
oenie CreditAttribution: oenie commentedjohnbarclay, 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 ?
Comment #17
haydeniv CreditAttribution: haydeniv commentedand a patch.
Comment #18
cdmo CreditAttribution: cdmo commentedI 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!
Comment #19
dgtlmoon CreditAttribution: dgtlmoon commentedWhat do you think about what's here in the comments? you're passing the LDAP user across but the comments say don't
Comment #20
oenie CreditAttribution: oenie commentedThis 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
Comment #21
dgtlmoon CreditAttribution: dgtlmoon commentedI have commit access if you can build a patch
Comment #22
oenie CreditAttribution: oenie commentedhi @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.
Comment #23
mayank_kanungo CreditAttribution: mayank_kanungo as a volunteer commentedI have the same problem "Failed to find or create [user] on logon.", and solution proposed in #11 is working for me.
Thanks Oenie :)
Comment #24
Csaba Mezei CreditAttribution: Csaba Mezei commentedSolution in #11 worked fine together with patches from #1430800: LDAP Authorization: Need ability to select multiple Servers in single Authorization consumer configuration
Thanks Oenie
Comment #25
kugel CreditAttribution: kugel commentedSolution in #11 worked fine with 7.x-2.0-beta11. Why not merge it? Are there any side-effects?
Comment #26
grahlComment #27
grahlComment #29
oenie CreditAttribution: oenie commented@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 :)
Comment #30
grahlComment #32
grahlNo one reported problems, committing.