After upgrading from a previous 1.0 beta to beta 10 and then to the latest dev release (7.x-1.0-beta10+19-dev (2012-Jun-05)), I ran into an issue with setting up ldap authorization on a new site. On a site where the module had been upgraded but the configuration had not been re-saved since an earlier beta, ldap authorization works just fine.
I tracked down the differences in configuration between sites to two database entries in the ldap_authorization table:
1.) derive_from_entry_user_ldap_attr (old site: NULL, new site: uid)
2.) derive_from_entry_entries_attr (old site: NULL, new site: dn)
I played around with each setting via MySQL update queries. Setting derive_from_entry_user_ldap_attr to NULL made my new site work. Any other attribute I tried (uid, dn, cn) and authorization failed.
Below are a typical user and a typical group in my environment:
[root@web ~]# ldapsearch -x -H -b "uid=mphillips,cn=users,dc=ciw,dc=edu" -LLL dn uid cn
dn: uid=mphillips,cn=users,dc=ciw,dc=edu
uid: mphillips
uid: mphillips@gl.ciw.edu
uid: m.phillips@gl.ciw.edu
cn: Morgan Phillips Hoople
[root@web ~]# ldapsearch -x -H -b "cn=glwebmgrs,cn=groups,dc=ciw,dc=edu" -LLL dn memberUid cn
dn: cn=glwebmgrs,cn=groups,dc=ciw,dc=edu
cn: glwebmgrs
memberUid: ghuntress
memberUid: smysen
memberUid: mphillips
memberUid: dappleby
memberUid: gqian
Below is the ldap_authorization table that works (after doing `update ldap_authorization set derive_from_entry_user_ldap_attr=NULL;`):
mysql> select * from ldap_authorization;
+--------------------------+--------+---------------+--------------------------------+--------+-------------------------+----------------+---------------------+------------------+-----------------------+---------------------------------+-------------------------+-------------------+--------------------------+---------------------------+--------------------------------+------------------------+------------------------------+----------------------------------+----------------------------------+-----------------------------------------------------------------------------------------------------------+------------+---------------+----------------+-------------------------+------------------+--------------------------+
| numeric_consumer_conf_id | sid | consumer_type | consumer_module | status | only_ldap_authenticated | derive_from_dn | derive_from_dn_attr | derive_from_attr | derive_from_attr_attr | derive_from_attr_use_first_attr | derive_from_attr_nested | derive_from_entry | derive_from_entry_nested | derive_from_entry_entries | derive_from_entry_entries_attr | derive_from_entry_attr | derive_from_entry_search_all | derive_from_entry_use_first_attr | derive_from_entry_user_ldap_attr | mappings | use_filter | synch_to_ldap | synch_on_logon | revoke_ldap_provisioned | create_consumers | regrant_ldap_provisioned |
+--------------------------+--------+---------------+--------------------------------+--------+-------------------------+----------------+---------------------+------------------+-----------------------+---------------------------------+-------------------------+-------------------+--------------------------+---------------------------+--------------------------------+------------------------+------------------------------+----------------------------------+----------------------------------+-----------------------------------------------------------------------------------------------------------+------------+---------------+----------------+-------------------------+------------------+--------------------------+
| 5 | CIW_OD | drupal_role | ldap_authorization_drupal_role | 1 | 1 | 0 | | 0 | | 0 | 0 | 1 | 0 | cn=groups,dc=ciw,dc=edu | dn | memberUid | 0 | 0 | NULL | glsysadmins|GL System Administrators
glwebadmins|GL Website Administrators
glwebmgrs|GL Website Managers
| 1 | 0 | 1 | 1 | 1 | 1 |
+--------------------------+--------+---------------+--------------------------------+--------+-------------------------+----------------+---------------------+------------------+-----------------------+---------------------------------+-------------------------+-------------------+--------------------------+---------------------------+--------------------------------+------------------------+------------------------------+----------------------------------+----------------------------------+-----------------------------------------------------------------------------------------------------------+------------+---------------+----------------+-------------------------+------------------+--------------------------+
1 row in set (0.00 sec)
Comments
Comment #1
johnbarclay CreditAttribution: johnbarclay commentedThis is quite possibly related to #1601270: LDAP Authorization: exportables functionality broken. Do you mind giving it a try and see if it solves this?
Comment #2
Garret Huntress CreditAttribution: Garret Huntress commentedNo joy using the June 11 build that included the patch mentioned in #1:
Screenshot of derive_from_entry_user_ldap_attr at NULL
Screenshot of derive_from_entry_user_ldap_attr at dn
Screenshot of derive_from_entry_user_ldap_attr at cn
Screenshot of derive_from_entry_user_ldap_attr at uid
Comment #3
johnbarclay CreditAttribution: johnbarclay commentedI'm setting up a reference ldap to test II.C. option and should be able to fix this at a later point. My current ldap is Active Directory which makes it difficult to test. The mock server is the simpletests aren't helping either.
If you want to get into debugging this, the code of interest is in ldap_authorization.inc under "Strategy 3: groups as entries". If you enable ldap help and turn on detailed logging, you should also get a pretty good watchdog entry on logon.
Comment #4
thanasis_v CreditAttribution: thanasis_v commentedHi,
I am using Anonymous Bind ( no credentials to bind to ldap server ) in my LDAP Server configuration. However after I updated from beta9 to beta11, I get a 'Failed to bind to ldap server' Error every time a user attempts to log in using the LDAP module. The Error message I get from the ldap module is:
No bind method set in ldap_server->bind_method in _ldap_authentication_user_login_authenticate_validate.
Severity error
It is strange that this error message comes right after a warning which used to also appear in the past,. Although before the anonymous bind wouldn't fail and it could read from the DN.
t : Success at connecting to myldapserverhost
Severity debug
When I try to run a test for my LDAP Server Configuration, this is successful:
Result Messages
Binding with DN for non-anonymous search (). Using password stored in configuration
Binding with null DN for anonymous search.
Successfully bound to server
Found test user test by searching on uid = test.
Thanks
Comment #5
johnbarclay CreditAttribution: johnbarclay commentedtagged as "7.x-1.0 release blocker"
Comment #6
johnbarclay CreditAttribution: johnbarclay commentedThis is fixed in 7.x-1.0-dev, I believe. Please confirm. Details at #1663842: LDAP Server: Ldap 7.x-1.0-beta11 module not allowing to bind to server Should have spotted this sooner. John
Comment #7
DaveRoberts CreditAttribution: DaveRoberts commentedI've been struggling with this too. I've just installed 7.x-1.0-dev and I'm afraid it didn't help. I still get the error message. The user name works fine in the server test but I get 15 instances of "Warning: htmlspecialchars(): Invalid multibyte sequence in argument in check_plain() (line 1572 of /var/www/includes/bootstrap.inc)." when I run the test.
Comment #8
DaveRoberts CreditAttribution: DaveRoberts commentedUpdate. I have un-installed and re-installed the 7.x-1.0-dev and the code works. I still get the multiple check_plain() error messages in the test, but users don't see that ....
Comment #9
johnbarclay CreditAttribution: johnbarclay commentedyeah. the tests will get lots of those. Its because its pulling in the binary attributes from the ldap entries. I should add some error checking and notes about that.
Comment #10
johnbarclay CreditAttribution: johnbarclay commentedThis is fixed in 7.x-1.x-dev.
Comment #11.0
(not verified) CreditAttribution: commentedRemoving server url