On 13 Nov 2012, at 17:23, Olivier Beytrison <[email protected]> wrote:
> On 13.11.2012 18:03, Phil Mayers wrote: >> On 13/11/12 16:38, Olivier Beytrison wrote: >>> >>> Well not really a solution here. The central LDAP system is one of the >> >> Fair enough. >> >>> To summarize, if I proxy the outer tunnel, there will be more load on >>> the central server, and I'll add the custom attributes to the outer >>> reply in order for the local radius to analyse them and add the >>> nas-specific attribute. >> >> Yes. >> >>> >>> if I proxy the inner tunnel, the TLS is handled by the local radius >>> (more CERT to buy), on the central server I add the attributes in the >>> normal reply, and the local radius keep doing the authorization part. >>> I just have to take care of the encryption between the local and central >>> servers. thankfully l2l vpn are already established. >> >> Yes. However, buying separate certs might not be a good idea as it will >> complicate the client setup - they'll all have to come from the same CA >> and share the same CN (or you'll have to rely on wildcard CN matching on >> the clients). >> >> For this reason, it might be easier to do all the TLS on the central >> servers, and have the same cert on both of them. > > Another good point indeed. Well this will make the local radius setup > fairly easy. Proxy everything to the central one, and just do > post-auth/post-proxy section, and manage the accounting. > > This will also make things easier when people outside our local realm > logs in on eduroam, the outer tunnel is proxied to the central radius, > which in turn proxies it to the NRO radius ... All that *will* be going away eventually, you'll just use RADSec and DNS discovery. Honestly I don't really see the point of the central server here, other than to interface with the existing eduroam infrastructure, and even then it's mostly lazyness :). If I were implementing this I would terminate the EAP sessions on the local servers, and query LDAP directly from the different sites. I'd do this for the following reasons: a) The crypto is spread across multiple hosts, meaning you don't load central servers and the system as a whole scales better. b) The likelyhood of packet loss (and EAP authentications timing out) is greatly reduced. Packet loss is a big problem with EAP over RADIUS, if the path between your central RADIUS servers and your site specific ones is in any way unreliable it's not going to work well. c) LDAP is TCP based and can recover from packet loss far quicker than RADIUS where the normal retransmission interval is ~5 seconds (granted this is configurable, but it's usually not sub second). d) It's possible to build up caches of passwords locally on each site RADIUS server (see rlm_cache) and then failover to that in the event of the central LDAP servers being unavailable, this gives you far greater resilliency. You can't do that if you never see the NT-Password or Cleartext-Password at a site level. As Phil says, you only need one cert. There's absolutely no way that the supplicant can tell which server is presenting the certificate, so the CN validation checks will not fail unless the user has configured a set CN string in their supplicant. -Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
