Skip to content

Ops 301 Class 12

Jump to bottom
Bill Kachersky edited this page Oct 4, 2021 · 1 revision

AAA (Authentication, Authorization and Accounting)

AAA is a security framework that allows a network or organization to create terms and conditions that a user must comply with before that user is granted access to network resources. The three A's of AAA are as follows:

  1. Authentication - This portion of the framework usually takes the form of a login portal where a user must input specific credentials/information in order to gain entry into the network.

  2. Authorization - This part is where the supplied credentials are checked against a server's database of stored credentials. With those stored credentials are also configuration files that specify the type of network resources the authentication credentials supplied are authorized or unauthorized to gain access to.

  3. Accounting - Once a user has been authenticated and authorization privileges have been extended based on the configurations linked to the authenticated credentials, the accounting portion of AAA is all about logging the authenticated user's activity while they're accessing the network and its' resources. It also keeps track of how long they are logged in for, and by what manner they log off (disconnect/time out)

AAA Implementation

AAA frameworks are implemented using either a local database or an ACS server. In the case of the ACS server, the client, or Network Access Server, sends the authentication request to the ACS server which then verifies the credentials and authorizes the NAS to let the user through to the network. In the event that the ACS fails to authenticate because of a network outage, a network administrator should use a local database as a backup whenever possible.

RADIUS Concepts

How things work in RADIUS

The client sends the server a RADIUS authentication request. You don't decide what's in the request, the client does. The server doesn't decide what's in the request, the client does. The client is 100% responsible for everything in the request.

The radius server looks at the request and depending on what authentication types you have enabled in the server, what the server can look up in a database, and what is in the request; The server will then start querying the modules in the authorize section.

At some point, one of the modules will see something in the request it recognizes. The module does this by looking in the request for key attributes, such as MS-CHAP-Challenge (for mschap), or CHAP-Challenge (for chap), or EAP-Message (for eap). Or it may just assume it needs to add something to every request.

If the module thinks it has a shot at authenticating the user it will acknowledge that it's able to authorize but not authenticate them, then redirect the server to its corresponding auth-type.

If the module doesn't see anything it recognizes or knows it doesn't need to look up anything, it does nothing. At the end of authorize, the server will check if anything set the Auth-Type. If nothing did, it immediately rejects the request. If one of the modules does recognize the request though, it will set the auth-type to itself.

This triggers the server to move to the authenticate section, where it queries the corresponding module, then compares the local "known good" password to the password as entered by the user. This is how authentication works.

This content is relevant to our class materials because it deals directly with security protocols and frameworks that we will be working with all of the time as security professionals.

Clone this wiki locally