On Mon, 9 Jun 2008, Ivan Kalik wrote:
man unlang - attribute lists.
*** The "<list>:" prefix is optional, and if omitted, is assumed to refer to the "request" list. ***
Ah yes ... That helps a lot. Thank you. However, having fixed references to %{CU-LDAP-Filter} so they now refer to %{control:CU-LDAP-Filter} (since I've assigned a value to that attribute in an "update control" statement), I see now that it does indeed refer to the value I've set, but by the time that's handed to rlm_ldap, punctuation characters have been replaced with hexadecimal (escape) representations: ... +++- entering case 192.168.198.20 expand: %{Stripped-User-Name} -> expand: %{User-Name} -> j_doe expand: (&(cn=%{%{Stripped-User-Name}:-%{User-Name}})(|(memberOf=cn=role_active_emp,ou=portal_role,ou=Groups,dc=concordia,dc=ca)(memberOf=cn=role_faculty,ou=portal_role,ou=Groups,dc=concordia,dc=ca))) -> (&(cn=j_doe)(|(memberOf=cn=role_active_emp,ou=portal_role,ou=Groups,dc=concordia,dc=ca)(memberOf=cn=role_faculty,ou=portal_role,ou=Groups,dc=concordia,dc=ca))) ++++[control] returns noop +++- case 192.168.198.20 returns noop ++- switch %{NAS-IP-Address} returns noop ++? if ("%{control:CU-LDAP-Filter}" != "") expand: %{control:CU-LDAP-Filter} -> (&(cn=j_doe)(|(memberOf=cn=role_active_emp,ou=portal_role,ou=Groups,dc=concordia,dc=ca)(memberOf=cn=role_faculty,ou=portal_role,ou=Groups,dc=concordia,dc=ca))) ? Evaluating ("%{control:CU-LDAP-Filter}" != "") -> TRUE ++? if ("%{control:CU-LDAP-Filter}" != "") -> TRUE ++- entering if ("%{control:CU-LDAP-Filter}" != "") +++- entering redundant-load-balance group redundant-load-balance rlm_ldap: - authorize rlm_ldap: performing user authorization for j_doe expand: %{control:CU-LDAP-Filter} -> \28&\28cn\3dj_doe\29\28|\28memberOf\3dcn\3drole_active_emp\2cou\3dportal_role\2cou\3dGroups\2cdc\3dconcordia\2cdc\3dca\29\28memberOf\3dcn\3drole_faculty\2cou\3dportal_role\2cou\3dGroups\2cdc\3dconcordia\2cdc\3dca\29\29\29 expand: ou=people,dc=concordia,dc=ca -> ou=people,dc=concordia,dc=ca rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: attempting LDAP reconnection rlm_ldap: (re)connect to host1:389, authentication 0 rlm_ldap: bind as cn=rad_admin,ou=AdminRoles,dc=concordia,dc=ca/**SANITIZED** to host1:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: performing search in ou=people,dc=concordia,dc=ca, with filter \28&\28cn\3dj_doe\29\28|\28memberOf\3dcn\3drole_active_emp\2cou\3dportal_role\2cou\3dGroups\2cdc\3dconcordia\2cdc\3dca\29\28memberOf\3dcn\3drole_faculty\2cou\3dportal_role\2cou\3dGroups\2cdc\3dconcordia\2cdc\3dca\29\29\29 rlm_ldap: ldap_search() failed: Bad search filter: \28&\28cn\3dj_doe\29\28|\28memberOf\3dcn\3drole_active_emp\2cou\3dportal_role\2cou\3dGroups\2cdc\3dconcordia\2cdc\3dca\29\28memberOf\3dcn\3drole_faculty\2cou\3dportal_role\2cou\3dGroups\2cdc\3dconcordia\2cdc\3dca\29\29\29 rlm_ldap: search failed rlm_ldap: ldap_release_conn: Release Id: 0 ++++[ldap_host1] returns fail ... Notice the "expand: %{control:CU-LDAP-Filter}" line once it's in rlm_ldap. I suspect that this is happening in the update block, but I can't be sure of that (or how to avoid it). I've tried to read all documentation that refers to "update", but haven't yet found any enlightenment. My update block corresponding to the above is (in sites-enabled/default): switch "%{NAS-IP-Address}" { case 192.168.198.20 { # test update control { CU-LDAP-Filter = "(&(cn=%{%{Stripped-User-Name}:-%{User-Name}})(|(memberOf=cn=role_active_emp,ou=portal_role,ou=Groups,dc=concordia,dc=ca)(memberOf=cn=role_faculty,ou=portal_role,ou=Groups,dc=concordia,dc=ca)))" } } ... } The CU-LDAP-Filter variable is then referenced in the instance(s) of the ldap module configuration: ldap ldap_host1 { ... filter = %{control:CU-LDAP-Filter} ... } Hrmmm ... I see from further reading (man unlang again!) that there is a 253 character limit on the assignment of string values. The above sample is below that limit but the filter values I'm intending to ultimately use will be well beyond that, so this seems like it perhaps isn't the best way to get what I'm after. I'll see if there's some way I could simplify the variable portion of my LDAP search filter, but I'm bothered by the escaping of punctuation characters. Is there a way to "un-escape" those when the variable is referred to later? -- ---------------------------------------------------------------------- Sylvain Robitaille syl@alcor.concordia.ca Systems and Network analyst Concordia University Instructional & Information Technology Montreal, Quebec, Canada ----------------------------------------------------------------------