Child pages
  • 4. non-RADIUS configurations
Skip to end of metadata
Go to start of metadata

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]
  • Email:
    • IMAP(2+4,3,S) [tcp/143, tcp/220, tcp/993]
    • POP(3S) [tcp/110, tcp/995]
    • SMTP(S/STARTTLS) [tcp/465, tcp/587]
  • VPN
    • 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]
  • Miscellaneous
    • 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 =
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]

   comment = Home Directories
   browseable = no
   read only = no
   create mask = 0700
   directory mask = 0700
   valid users = %S

   comment = Network Logon Service
   path = /srv/samba/netlogon
   guest ok = yes
   read only = yes
   share modes = no

   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 plugin provides two methods for checking your RADIUS infrastructure's status. The first is to do non-authenticated monitoring by using Status-Server packets (see RFC 5997 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.

There is additional information in the "Testing Your Connection" section on the Radius Server Configuration page. 

  • No labels