I just updated my version of the LDAP module to 7.x-2.0-beta5, and it's almost working perfectly. What an improvement!
The issue that I'm having is regarding LDAP Authorization when I use LDAP SSO:
1) If I go to user/login/sso, it authenticates me without a problem, and states "You have been successfully authenticated". But in fact I'm not logged in at all, as I cannot see the admin menu and can still see the user login form.
2) If I manually enter my username and password at user/login, I'm logged in correctly and can see everything properly.
Here are the troubleshooting steps that I've tried so far:
1) SERVERS: Entering my username in the "Testing Drupal Username" textbox results in my data being displayed.
2) AUTHORIZATION: Entering my username in the "Drupal usernames to test role authorizations results for." textbox *does not* result in my data being displayed. This is what's displayed instead:
*LDAP Authorizations Test Results for consumer drupal role*
Drupal Username: jayhawkfan75
Authorization Type: drupal role
Authorization IDs: ##empty## <<<---This appears to be the problem.
Configuration: drupal role
LDAP Server Configuration: myserver
*Prefiltered and Final Mappings*
Derive from DN (without filter): disabled
Group DN's (without filter): ##empty##
*After "Convert Full DN to Value of First Attribute Before Mapping*
Convert full dn to value of first attribute before mapping. NOT enabled
*After Mappings and Filters Applied*
Use Mappings as Filter = 1
Configured Mappings: ##list of mappings I've entered##
Results after any filtering and mappings applied: ##empty##
(Please Note: The mappings entered were copied-and-pasted out of my earlier version of this module that worked, 7.x-1.0-beta12.)
3) WATCHDOG: No logs were created.
I'm thinking that something's up with my AUTHORIZATION (or maybe SSO?) setup that's not allowing my LDAP account to connect with a Drupal account and its corresponding roles, but I'm not sure of the steps that I need to take at this point.
I'm attaching an LDAP Status Report in a txt file. Any suggestions on how to resolve this would be very helpful. Thanks.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | ldap_sso.patch | 836 bytes | eerorika |
| #3 | ldap_sso.patch | 1.73 KB | eerorika |
| LDAPStatusReport_052913.txt | 3.17 KB | katannshaw |
Comments
Comment #1
katannshaw commentedI've done some further testing, and can see that my credentials are getting pulled into ldap_module.sso without a problem. So it definitely appears to be an issue with the LDAP mappings to Drupal roles. I verified this by testing my username under the UI's Authorizations section, which pulled my data but not mappings.
I'm using the same mappings (copied & pasted) that I used in the previous version of 7.x-1.0-beta12, and I'm not sure what's changed between them. My settings are already listed on the original post, so I won't be redundant. Hopefully I'll get a response to this issue soon, as it's really going to hold me back from launching the site until it's resolved.
Comment #2
katannshaw commentedMarking as duplicate of LDAP Authorization does not map ldap groups to drupal roles.
Comment #3
eerorika commentedI'm re-opening this issue because the title matces exactly the problem that I have. However, as I understand, the issue is not related to the drupal roles.
The issue that I have is that sso authenticates users successfully but does not actually log them in and I believe it's the same as this issue.
I have created a patch that fixes it (or works around the issue). The code in the patch simply replaces the global
$userobject with whateverldap_authentication_user_login_authenticate_validatereturns and callsuser_login_finalizeif the user was authenticated by the server.If I should create a separate issue for this, please let me know.
Comment #4
eerorika commentedSorry, I forgot to save the patch before I removed the unrelated project files, please use this one instead.
Comment #5
katannshaw commented@eerorika: Thanks for the information and the patch. I just gave it a try and it didn't work for me.
Unfortunately when testing with IE9, Firefox and Chrome, I get redirected to the user login page with this notice: "You were not authenticated by the server. You may log in with your credentials below.". No Watchdog logs were created for this login attempt.
However, when I look at the logs I do see 3 notices from the server test with the same message:
I'm not sure why I'm getting a "bad search error", since that test worked.
I also see these notices when visiting the "admin/config/people/ldap/help/status" page:
*****
UPDATE:
After some debugging, I got rid of the above notices by re-installing only the ldap_sso folder and re-running the patch from #4. I could see that the setting for ldap_sso were missing on the Help/Status page at admin/config/people/ldap/help/status, and it wasn't listed under the modules. Hope it helps.
*****
On the Server section's test, entering my username returned all of my information property. But when I run the Authorization section's test against my username, the LDAP roles are not mapped to Drupal roles as they should be. The "Results after any filtering and mappings applied" section is just blank.
This is all very confusing to me, and I really hope to get some clarification and/or resolution to this issue soon or I'll have to come up with an alternative to the LDAP module.
Comment #6
katannshaw commentedUpdate:
I just disabled Anonymous access on IIS 7.5 and it worked for me on all three browser version...yea!!!
I remembered that I had to do that to get a previous version of this module to work, and voila...it now works. I had tried this before your patch without success, so thanks for your help. Hopefully the patch will get committed.
Next step, getting the LDAP > Drupal role mappings to work under Authorization, which they still aren't. I'll keep up with the other issue report titled LDAP Authorization does not map ldap groups to drupal roles concerning that.
I'd also like to have it so that anonymous users can also access the site (i.e. network users without an Active Directory account), but I'll create another support request for that issue since it's unrelated. Thanks eerorika; your help is *much* appreciated!
Comment #7
aphm commentedI have the same issue as #1 on a Linux CentOS box.
#4 patch solved it and it works now like a charm.
Thank you for your help ! :)
Comment #8
svax commentedI can also confirm that the patch in #4 solved the described problem.