using different LDAP queries to authorize for different services

[Sylvain Robitaille]

On Thu, 3 Apr 2008, Alan DeKok wrote:

>> ... is it possible to equate "notfound" to "fail" or "reject"?).
>
>  Yes.
>
> 	if (notfound) {
> 		fail
> 	}

Hrmmm... I thought I'd tried that before writing the above, but I didn't
keep a copy of it, so I can't recheck if I maybe simply tried it in the
wrong place.

However, I believe you're setting me straight, and showing me that
although this is possible, it isn't the best way to accomplish what I'm
trying to do ...

>  Set copy_request_to_tunnel in eap.conf.  Or, do:
>
> 	if (outer.NAS-Port-Type == Wireless-802.11) {
> 		...
>  Again, "man unlang" explains "outer.*".

Ah, yes!  That works.  (I know: see you not look surprised!)

I apologize if I'm seeming dense, or leaving the impression that I
haven't read documentation that you've already pointed me at.  I *have*
read that documentation, but I think the problem is that I'm struggling
to wrap my head around the details, perhaps because it seems that not
only are there many options, but there seem to be indeed several ways
that the same result *might* be achieved.  It's looking like what I'm
finding are all the ways that won't actually do what I want, though.

I feel as though *conceptually* I understand what I need to do, but I
haven't yet understood how to apply that to my configuration.

> If you're using TTLS, you *don't* want to do username/password lookups
> in ldap for sites-enabled/default.  That's what the "inner-tunnel"
> server is for.  Do the LDAP calls there.

Ok, this is definitely the bottom line of where I've been going wrong.
I *was* trying to get the ldap authorization done in "default".
Corrected.

> No... that looks like the *outer* tunnel data.  Inner tunnel requests
> do *not* have a Message-Authenticator attribute.

Hrmmm...  In that case the inner-tunnel isn't printing to debug output
the request as it is received at that point?

Ok, I think I see it now.  The debug output from the inner-tunnel starts
here then?
...
   rlm_eap_ttls: Session established.  Proceeding to decode tunneled attributes.
+- entering group authorize
++[chap] returns noop
++[mschap] returns noop
++[unix] returns notfound
     rlm_realm: No '@' in User-Name = "j_doe", looking up realm NULL
     rlm_realm: No such realm "NULL"
++[suffix] returns noop
++[control] returns noop
   rlm_eap: No EAP-Message, not doing EAP
++[eap] returns noop
++[files] returns noop
++? if (outer.NAS-Port-Type == Wireless-802.11)
? Evaluating (outer.NAS-Port-Type == Wireless-802.11) -> TRUE
++? if (outer.NAS-Port-Type == Wireless-802.11) -> TRUE
++- entering if (outer.NAS-Port-Type == Wireless-802.11)
rlm_ldap: - authorize
...

> Stop.  You are trying too many options, and too many different
> configurations.  It's not worth it.

Well, I'm trying these options and configurations because I do really
want to accomplish the result I'm after.  That I've been doing it all
wrong is simply an indication that I *still* haven't understood the way
the server functions.  I promise that it isn't because I'm not trying. :-(

> Keep the outer and inner tunnel configurations separate.  That's why
> they are in different virtual servers... because they are separate.

I expected that, but made the mistake of adding things in "default"
first, seeing the server do *some* of what I was after, then trying to
get it to do the *remainder* by attempting to configure (sometimes
similar) items in "inner-tunnel", though not with complete success.

> In the inner tunnel server, use "outer.Attribute-Name" to access
> attributes *outside* of the tunnel.

Hrmmm...  I just spotted why I didn't understand that previously from
"man unlang", but rather needed you to explain it to me directly:

    : natasha[syl] ~; man unlang |grep -w outer
           also   reference   "outer.request",   "outer.reply",   and
           "outer.control".  Those references will update  the  rele-
           vant list in the outer tunnel session.
                  "outer.request", "outer.reply", or "outer.control",

It talks about being able to *update* items in the outer request (to
which my mind certainly replied, "no, that's not what I'm trying to do
...") but not specifically about being able to access *incoming*
attributes from the outer tunnel.

Probably the following text (from "man unlang") is intended to make that
clear, but with my very limitted knowledge of the server's function,
it didn't:

        For  EAP  methods  with  tunneled  authentication sessions
        (i.e. PEAP and EAP-TTLS), the  inner  tunnel  session  can
        also   reference   "outer.request",   "outer.reply",   and
        "outer.control".   ...

Ie. In hindsight, "outer.request" should probably have been my clue, but
it was completely overlooked because this occurs in the "update" section
of KEYWORDS.  I saw it, but didn't really "see" what it was telling me.

I'd offer to patch the documentation to make it clear that the
inner-tunnel can reference *attributes* from the outer request using
"outer.Attribute-Name", but it seems despite all I've learned from all
of these experiments and from the help I've gotten on the mailing list, I
have only scratched the surface of what there is to know about FreeRadius,
and I would likely write yet more partially-correct-at-best third-party
documentation that folks really shouldn't follow.  :-(

> Honestly, it's not that difficult.  Find *something* in the outer
> request that is there only for wireless requests.  Key off of that in
> the *inner* tunnel to select the users from the correct LDAP instance.

I had the first part of that right: I was looking for a unique
attribute.  I appreciate the time you've taken to teach me *where* I
should have been looking for that attribute.

> 	if (outer.NAS-Port-Type == foo) {
> 		ldap_foo
> 	}
> 	elsif (outer.NAS-Port-Type == bar) {
> 		ldap_bar
> 	}

That's EXACTLY what I need to do, yes.

Once again, thanks for ALL the help.  I think I now have everything I
need to do exactly what I want.

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

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