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 [EMAIL PROTECTED]
Systems and Network analyst Concordia University
Instructional Information TechnologyMontreal, Quebec, Canada
--
-
List info/subscribe/unsubscribe? See
