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@alcor.concordia.ca Systems and Network analyst Concordia University Instructional & Information Technology Montreal, Quebec, Canada ----------------------------------------------------------------------