There are many possible configuration decisions that may come up during the planning of an eduroam deployment at your institution. This section will provide how-tos and tips for configuring your servers and services for federation.
eduroam-US User Access Requirements
eduroam is authenticated via 802.1X. For a consistent user experience at all eduroam institutions globally, eduroam-US follows the policies set forth by GEANT (p. 29) (the global operator of eduroam) regarding minimum service support for all users joining the eduroam SSID:
- HTTP/HTTPS [tcp/80, tcp/443]
- SSH [tcp/22]
- IMAP(2+4,3,S) [tcp/143, tcp/220, tcp/993]
- POP(3S) [tcp/110, tcp/995]
- SMTP(S/STARTTLS) [tcp/465, tcp/587]
- Standard IPSec VPN [IP proto 50 (ESP), IP proto 51 (AH), udp/500 (IKE)]
- OpenVPN 2.0 [udp/1194]
- Cisco IPSec VPN over TCP [tcp/10000]
- PPTP VPN [IP proto 47 (GRE) and tcp/1723]
- IPv6 Tunnel Broker Service [IP proto 41]
- IPSec NAT-Traversal [udp/4500]
- Passive (S)FTP [tcp/21]
- RDP [tcp/3389]
Samba as a Domain Controller with OpenLDAP
Samba combined with OpenLDAP can be used to allow PEAP and TTLS authentication with free tools. This provides an alternative to Microsoft's Active Directory for institutions wishing to support PEAP natively under Windows without the use of Secure-W2.
Before getting Started
There are several things to consider before implementing OpenLDAP as the Identity Provider (IdP) for eduroam-US at your institution. The first is that if you already have an existing directory service (AD, LDAP, etc...) then trying to interface Samba with that server will be more difficult than simply implementing a Domain Controller in Samba as is described below. If you happen to be using OpenLDAP as your IdP Samba does provide tools to convert your existing LDAP schema into the format required for it to operate as an PDC. This process should be undertaken with care and is not described within this document.
Setting up OpenLDAP
The first step in the process is to install OpenLDAP. Depending on your underlying platform the specific steps may vary. Many use Red Hat or Ubuntu.
Configure Samba as a Primary Domain Controller (PDC)
We assume Samba is installed and configured but not acting as a PDC. Add the following to your smb.conf (generally /etc/samba/smb.conf) to configure Samba as a PDC:
workgroup = institution.edu security = user domain logons = yes domain master = yes #for a secondary (backup PDC) set this to no
To allow Windows machines to join the domain you also need to setup the following:
logon path = \\%N\%U\profile logon drive = H: logon home = \\%N\%U logon script = logon.cmd add machine script = sudo /usr/sbin/smbldap-useradd -t 0 -w "%u"
For Samba to act as a PDC we must also setup various shares including [homes], [netlogon], and [profiles]
[homes] comment = Home Directories browseable = no read only = no create mask = 0700 directory mask = 0700 valid users = %S [netlogon] comment = Network Logon Service path = /srv/samba/netlogon guest ok = yes read only = yes share modes = no [profiles] comment = Users profiles path = /srv/samba/profiles guest ok = no browseable = no create mask = 0600 directory mask = 0700
Other useful Samba options may be found in the Domain Control section of the Samba documentation. Some potentially useful options may be found below:
wins support = no #disable WINS (WINS is needed for pre-Win2k machines) unix password sync = yes #keep the UNIX passwords the same pam password change = yes #with the above, use PAM and not a passwd(1) program #Ensure that samba will remain the master browser local master = yes preferred master = yes os level = 33 #disable printing load printers = no printing =
Testing your Configuration
To test your configuration you should use the ntlm_auth(1) tool on the command-line. This tool acts as an intermediary between a domain controller (Samba or ActiveDirectory) and UNIX applications. An example command-line would be:
ntlm_auth --domain=INSTITUTION --username=eduroam_tester
Firewall Configuration Guidelines
RADIUS traffic is carried by UDP with various port pairs. Current conventions call for udp/1812, udp/1813 (for authentication and accounting respectively) where the now deprecated ports of udp/1645, udp/1646 are used by some RADIUS servers. The eduroam-US TLRS responds to both sets of authentication and accounting ports.
Your firewalls must allow all RADIUS traffic between the eduroam-US Top-Level RADIUS Server(s) (TLRS) and your RADIUS server(s) on the ports you choose during configuration.
Monitoring RADIUS infrastructure with Nagios
Monitoring of RADIUS from Nagios can be complicated but is possible with the right collection of plugins and configurations. The following are a few methods of doing so:
The provides two methods for checking your RADIUS infrastructure's status. The first is to do non-authenticated monitoring by using Status-Server packets (see plugin for more details). This was first implemented in FreeRADIUS by Alan DeKok and then adopted by Radiator (and maybe other servers). When the RADIUS server receives such a request (without a username or password for authentication but it does require a valid RADIUS secret to construct the request) it responds with various status and statistics about that RADIUS server. You may also use that plugin with a credentials to verify that Authentication is working on the remote host. 5997
There is additional information in the "Testing Your Connection" section on the Radius Server Configuration page.