Primer: Authentication - RADIUS, Kerberos, and LDAP

When someone "logs in" to a computer, typically a number of different systems play different roles in the process. You'd think it'd be simple - just have a server somewhere accept usernames and passwords, and respond accordingly. Reality is more complicated than that:

• People hate logging in over and over again
• Users have more to them than usernames and passwords
• A server that authenticates people needs to be trusted, and it needs to make sure that it can trust people using it.

Different applications require different approaches. Here's some typical services that require authentication:

• Logging into a PC in the morning, to verify you're the real owner of the machine so you can access the files stored under your name.
• Using network resources from your PC, such as email.
• Securely connecting your PC to the network via a less secure network (such as via a VPN, or just your office's wireless system.)

Now, depending on the network, one or more of these might be set up separately. The accounts on the PC, for example, might be manually set up by the PC's owner, the network resources such as the email system might be an entirely different set of accounts, and accessing, say, your wireless router, might require a single, shared, password. Your home network is probably set up this way. But as you add users and computers, you get a steadily more and more complicated network, and it becomes much more difficult to manage the system unless you have some centralization to the authentication systems.

Three technologies in particular make up the majority of authentication systems. These are LDAP, Kerberos, and RADIUS. Let's talk about how these work together and the roles each technology plays.


LDAP - The Who, What, and How

LDAP is what's called a Directory System. It's a database system, essentially, used to store information about the various entities on your network. On a typical network, it stores:

• Usernames
• Passwords associated with usernames
• Rights associated with usernames (eg. "This user can administer his PC")
• Configuration information (eg. "This user's name is Fred")
• Devices hooked up to the network (eg. "FredsPC")
• Configuration information that the devices hooked up to the network can use to configure themselves.

When you log into your PC in the morning, typically the PC does a number of things. Once it's verified you are who you say you are (it'll usually indirectly use LDAP for this), it'll download information from LDAP about you,  to set you up with the correct rights and permissions.

LDAP is typically the core of the authentication system. Everything else uses the information from LDAP, so that only one system needs to be kept up to date.


Kerberos - I'm Really Who I Say I am

While LDAP stores the information about you, Kerberos is responsible for telling services on the network who you are. When you log into your PC in the morning, the Kerberos system is responsible for verifying your username and password, and getting what's called a "Ticket" that can be used to identify you in the future. This system means that if, say, your email system needs to verify you really are who you say you are before giving you access to your email, all your PC needs to do is send the ticket behind the scenes to the email server, and the email server will know it's you.

Now, you might ask, why? Rather than get a ticket, why not have the PC send your login credentials and the mail server can verify that the credentials are correct by looking them up in LDAP? Well, two reasons:

1. Sending login credentials and checking them against LDAP creates more load, and more opportunities to break, for the LDAP server. If the LDAP server is down for a minute, all network services will shut down as soon as they require any kind of authentication. By comparisons, the tickets issued by Kerberos can be checked without going back to any other servers - using a system called cryptographic signatures.
2. Sending login credentials is inherently insecure. What if your PC sent your username and password to a computer masquerading as the email server, but run by someone trying to hack into your network? Kerberos's tickets don't contain any secure information, they expire after a certain period of time, and they can only be used for network services delivered to the computer that they were issued to.

Kerberos is typically implemented by having it read LDAP for information about the available users. Kerberos doesn't store anything other than usernames, passwords, and "keys", used to identify network services.

To expand on the "What happens when you log in in the morning" example above, here's how Kerberos fits into the picture.

1. You enter your username and password
2. Kerberos is used to obtain a ticket for the username and password, if they're valid. If they're not, then you're told you can't log in.
3. Your computer now obtains information about you from LDAP and ensures your account is set up correctly.
4. You get a desktop, and you double click on your email icon.
5. The email client sends the Kerberos ticket associated with your session to the email server. The email server sees that the ticket is for you, and verifies that the ticket was issued to your computer and that it hasn't expired. All this information is in the ticket, together with a signature that proves the ticket hasn't been forged or tampered with.
6. Your email client opens up and shows you the email on the server.

So, LDAP stores information about users, and Kerberos is one way of authenticating those users. But what if you can't authenticate someone using Kerberos, and you don't trust the device sending you authentication information?

RADIUS - He's with me, let him in

Unless a device is actually on the network, it can't use Kerberos (or LDAP) to authenticate itself. But your network would hardly be secure if you allowed anyone to connect to it without authenticating themselves first. This Catch-22 has been solved using a system called RADIUS. RADIUS is used to authenticate devices at the time that they're trying to connect to a "private" network. It's most often used by ISPs to ensure only customers can connect to their dial up systems, but the chances are your Wireless Access Point also supports RADIUS as a way to let authorized users connect securely - and keep unauthorized users out.

RADIUS was originally used by dial-up ISPs but over time became more advanced as the needs of those using it grew. It became necessary, for example, to ensure that the device needing to access the network never actually sent a password. Why? Well, suppose you have three parties.

• A user
• A dial-up ISP
• AOL (yeah, America Online)

The user is a customer of AOL. AOL has an agreement with the ISP allowing AOL's customers to access AOL via the ISP.

So the user needs to dial into the ISP, and log in using their AOL credentials. If the user sends her username and password, the ISP could log the information and use it to log in as that user. So instead, a system where AOL's RADIUS server sends information back to the user's PC saying things like "If I turn your password into a string of numbers, multiply them, add three, and divide by the fifth letter, what answer do you get?" This way, anything in between, like the ISP's dial-in server, never gets to see the user's credentials.

How is this relevant to your network? Well, RADIUS is no longer just a technology used by ISPs. It's also used on VPNs and on modern wireless routers (although it's surprising how few wireless routers are configured to use it!) The same concepts that made RADIUS work for ISPs with complex authentication requirements also make it extremely good for integrating an authentication system for devices that need to access your network.

As always, in a modern environment, the RADIUS server still uses the LDAP server for the master copy of the authentication information.

Between them, LDAP, Kerberos, and RADIUS generally cover all of the authentication requirements of a modern internal network.

Other authentication technologies are also creeping in as the world becomes steadily more web oriented, such as oAuth and OpenID. These technologies are designed under the assumption you'll need to access a network's resources from an arbitrary web browser, that might be on a user's PC, or a tablet, or smartphone. Unlike the above technologies, they don't assume integration with the operating system, but they're not designed for an environment where every device is managed centrally.


Trying them out

The technologies above constitute what's commonly referred to as domain security. If you're a member of one of the various Microsoft programs that allows you unlimited access to its technologies, an extremely good starting point towards learning this system is to use Active Directory. AD is a strong domain security system put together by people who obviously understood the concepts.

On the GNU/Linux side, the options are there (all of these technologies started off as open standards, built upon open source, and fostered within Unix environments), but there's a lack of expertise. Still, two systems you can seriously consider installing and setting up are Apache's ApacheDS and the FreeRADIUS project. ApacheDS is a combined LDAP/Kerberos server (so you don't have to worry about the details of how to connect the two), and FreeRADIUS, as the name implies, is an open source implementation of the RADIUS system. GNU/Linux supports PAM and NSS to integrate LDAP and Kerberos into the log in process.

I'll be posting a HOWTO shortly on how to set up domain security for a network comprised of Ubuntu machines. Stay tuned!