RADIUS with LDAP: changing LDAP filter based on RADIUS request

[Sylvain Robitaille]

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 at alcor.concordia.ca

Systems and Network analyst                       Concordia University
Instructional & Information Technology        Montreal, Quebec, Canada
----------------------------------------------------------------------