Matt Bernstein wrote:
We will have multiple server certificates; our departments are rather independent here.
Ugh. There's not really any good reason for this. If the departmental certs are signed by a university CA, then you can still get away with one server instance.
update control { Virtual-Server = "%{Realm}" }
What does this achieve?
What I said in my previous message: If you have one server certificate for TTLS, you don't need this extra layer of nesting. The TTLS && PEAP modules will look for a *dynamic* definition of the virtual server for the inner-tunnel.
Does it avoid the first layer of proxying?
It does what I said it does.
My set-up is working without it, AFAICT:
Yes, I did read your message. I did see the point where you said your configuration worked. Maybe I was trying to describe how you could acheive your goal *without* source code patches.
Maybe the inner eap config can be the same for the "inner" virtual servers, but the server{} blocks will necessarily be different.
Well, yes. That's the point of virtual servers.
I have run into another bug: if I instantiate rlm_ldap in my servers "dcs-inner" and "maths-inner", it seems to use the base DN for "maths-inner" (instantiated second) for queries from "dcs-inner".
As always, debug mode.
Am I just being too weird and hairy? Or should I use a separate radiusd and raddb for each subrealm, as is the case with my production FreeRADIUS 1.1 set-up?
It's a little complicated. Unnecessarily so, IMHO. Alan DeKok.