using different LDAP queries to authorize for different services

[Sylvain Robitaille]

On Thu, 3 Apr 2008, Alan DeKok wrote:

>>> You have to change the reference to "ldap" in sites-available/default.
>>> to the instance name.  e.g. "ldap_wireless".
> ...
> In 2.0, you don't really need Autz-Type.  I would suggest pretending
> that it doesn't exist.  Instead, use "unlang".
> ...
> The sections are processed top to bottom, as a linear list.  If you
> want to make the server do your bidding, write "if/else" statements
> using "unlang".
>
> i.e. write the conditions you want to match in plain english, and what
> you want it to do.  Then, translate that pretty much directly into
> "unlang".

and in a response to a different message:

>> What is the proper way to call a specific LDAP module based on
>> NAS-IP-Address (or huntgroup, probably)?
>
> authorize {
> 	...
> 	if (NAS-IP-Address == 1.2.3.4) {
> 		ldap_1
> 	}
> 	elsif (NAS-IP-Address == 3.4.5.6) {
> 		ldap_2
> 	}
> 	...
> }
>
>  Or, use "switch".  See "man unlang".
> ...
> Don't use the "users" file for things like this.  It doesn't know
> about modules, or module order.  The "unlang" parser does know.

On the one hand, "OH!!!"  I think I'm starting to understand, but on the
other hand, I appear to still not be doing it quite right.  I put into
the "authorize" section of sites-available/default:

...
         #
         #  The ldap module will set Auth-Type to LDAP if it has not
         #  already been set
         #ldap

         # wireless
         if (NAS-Port-Type == Wireless-802.11) {
                 ldap_wireless
         }
...

I also tried NAS-IP-Address with the same result so far, but I can
clearly see from the debug output that this part is now functioning as
expected.  If the user does not match the search filter configured in my
ldap_wireless instance of the ldap module, this section returns
"notfound", otherwise it returns "ok".

However, then the request carries on to the inner-tunnel of the TTLS
transaction (whether or not the outer authorization succeeded or returned
not found;  is it possible to equate "notfound" to "fail" or "reject"?).
If I configure sites-available/inner-tunnel's authorization section as
above, when it gets to that point, debug output says:

    ++? if (NAS-Port-Type == Wireless-802.11)
        (Attribute NAS-Port-Type was not found)

The user is rejected shortly after, even when the ldap search is
expected to succeed, with the following in debug output:

    auth: No authenticate method (Auth-Type) configuration found for the request: Rejecting the user
    auth: Failed to validate the user.

In other words, despite having found the user in the ldap_wireless
search in sites-available/default, the inner-tunnel seems to not receive
sufficient information about the request to decide to use the
ldap_wireless module, leaving the RADIUS server with no way to
authenticate the user.  This is despite ldap_wireless in
sites-available/default having produced:

rlm_ldap: checking if remote access for j_doe is allowed by cn
rlm_ldap: Added User-Password = {SSHA}*SANITIZED*QDmffXBQkU42Wt9x*SANITIZED*== in check items
rlm_ldap: looking for check items in directory...
rlm_ldap: looking for reply items in directory...
rlm_ldap: user j_doe authorized to use remote access
rlm_ldap: ldap_release_conn: Release Id: 0
+++[ldap_wireless] returns ok
++- if (NAS-Port-Type == Wireless-802.11) returns ok

ie. we have a password and have already determined authorization for
this user.

And also despite the debug output of the request arriving at inner-tunnel
*appearing* to contain items sufficient for me to select on:

         User-Name = "j_doe"
         NAS-IP-Address = 127.0.0.1
         Calling-Station-Id = "02-00-00-00-00-01"
         Framed-MTU = 1400
         NAS-Port-Type = Wireless-802.11
         Connect-Info = "CONNECT 11Mbps 802.11b"
         EAP-Message = 0x02050070150017030100207ec2e216f79ef34a114bb34054277beb1a45fd25505d975be42b62d449e1be8c1703010040ca0cbb9c6b5abfef1e656ccc100c8350cae810edc08d9b6c3135dabbcac32a2ef26c2a3824cb7eaf7423d00c83432cfaceb08721d92faa5c3579908e3be88ba3
         State = 0x6f66f2676b63e70a05f25e914c848f96
         Message-Authenticator = 0x314bc723b23efd033689667de8c0ca7a

If I put in inner-tunnel:

authorize {
...
         ldap
...
}

Then it seems to authorize access for users that "ldap_wireless" in
"default" didn't find.  I can get the intended result for *this* service
with inner-tunnel containing instead:

authorize {
...
         ldap_wireless
...
}

but that doesn't help me for other services for which I want to use
RADIUS.

Help?

-- 
----------------------------------------------------------------------
Sylvain Robitaille                              syl at alcor.concordia.ca

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