The previous chapter covered some basic identity and access concepts. This chapter gets deeper into identity and access services. These services decide whether a user gets access to a system (or not). This is the second of three chapters in the Security+ book about identity and access management.
This is a continuation of my blog post series on the CompTIA Security+ exam, where I share my studying and connect it to real-world events.
Without providing much warning, the book launches into a tour of different services. These services are described in varying levels of depth. In a few cases, you even get some nitty-gritty details on how handshakes work!
LDAP
Directories are a form of data storage. They’re like databases, but not quite. Unlike a database, directories are designed to provide efficient data-retrieval services (reads). So, this what they’re optimized for. The data inside is also a tree-like hierarchy, storing data about servers, resources, and so on.
LDAP stands for Lightweight Directory Access Protocol. It’s used to handle user authentication, authorization, and to control access to Active Directory objects. This is the lightweight version of Directory Access Protocol, which is must less common.
Kerberos
Named after the three-headed dog from Greek mythology. Kerberos is a network authentication protocol meant for client/server environments. It’s able to securely exchange symmetric keys over an insecure network.
From there, you have key distribution centers, which handle authentication and ticket-granting. Tickets are time stamped, and function similarly to tokens (they prove that a user is who they say they are, after authentication has happened).
NTML
NTML stands for NT Lan Manager, also known as Windows Challenge/Response. This is a suite of security protocols from Microsoft. Functionality includes authentication, integrity, and confidentiality. This is the precursor to Kerberos. If you can’t update past Windows 7, you’d probably use this (yes, that’s an exam question hint). NTLM uses an encrypted challenge and response protocol to authenticate a user while avoiding sending the password over the wire. Still, the encryption used (MD4) is considered weak and deprecated.
TACACS+
The horribly named TACACS+ stands for Terminal Access Controller Access Control System+. This is another client/server protocol that operates using TCP (port 49). It separates out authentication, authorization, and accounting.
The client in TACACS+ is usually a network access server (NAS) and the server is a daemon process on a UNIX, Linux or Windows server. If the user’s machine is not the client, then communications can be unencrypted and passed in clear text. You can encrypt communications between the server and client by manually setting a shared secret on each side.
TACACS+ supports PPP, PAP, CHAP, EAP and other authentication methods. The authentication process uses a handshake of different packet types: START, CONTINUE and REPLY. Authorization uses REQUEST and RESPONSE message types. The responses for authorization requests aren’t a simple yes/no. They can be “smart” and include time limits or IP restrictions.
Lastly, TACACS+ has accounting to record what a user or process has done. This can be used for determining billing purposes, or security audit trails. How does it know what happened? The accounting process has information from the authorization and authentication processes.
CHAP
Since the “El Chapo” trial is happening, this gets rewritten from “CHAP” to “CHAPO” in my head. Oh well. CHAP is short for Challenge Handshake Authentication Protocol. It provides–you guessed it!–authentication for a point-to-point link. It uses PPP, which is strangely missing from this chapter. CHAP provides this authentication by way of a periodic challenge/response handshake.
MSCHAP
Microsoft Challenge Handshake Authentication Protocol is the Microsoft variant of CHAP.
PAP
Password Authentication Protocol is a two-way handshake that establishes authentication. However, it’s deprecated because the username and password are sent in clear text.
RADIUS
Another protocol that handles authentication, authorization and accounting. However, the “A” in RADIUS stands for Authentication. The full acronym is Remote Authentication Dial-In User Service.
It’s a connectionless protocol that uses UDP (ports 1812 and 1813). Like Kerberos and TACACS+, it’s a client/server protocol. It’s supports a number of authentication options: PPP, PAP, CHAP, UNIX login, and others. Authorization requires a number of parameters including service type allowed, protocols allowed, how IP addresses should be assigned, and the access list. Its accounting functions can also be used for time billing and security logging.
SAML
SAML standards for Security Assertion Markup Language. It’s a method of authentication and authorization for users, in a way that allows single sign-on. It’s XML-based. It was developed in the early 2000s, before a lot of new web technologies took off. As such, it’s a little difficult to translate to mobile or some types of web projects.
OpenID Connect and OAuth
OpenID Connect handles authentication, and is built on OAuth 2.0. This is a better fit for new web and mobile projects. With OpenID, a third party authenticates you so you don’t have to sign up for more accounts.
OAuth (Open Authorization) is a protocol that allows secure, token-based authorization on the internet. Like OpenID, this is a good fit for web, mobile, etc.
I cover OpenID and OAuth in this “authZ” post.
Shibboleth
This is another SSO service to allow federated identity-based authentication and authorization across networks. It’s built using SAML.
Secure Tokens
Some of the previous protocols provide tokens to users. These secure token services are responsible for issuing, validating, renewing and canceling these security tokens. Once a client is properly authenticated, it sends the token along with every request to prove its identity to the server.