In previous blogs about ACS 5.x, we saw some examples, such as basic authentications and authorizations. We will now talk about ACS inner working. Let’s take a look at this picture from Cisco:
Now we will explain and illustrate this work flow.
The AAA request is made from some network device, such as router, switch or a firewall. These are called Network Devices or AAA Clients. Each of them must be defined in the ACS server with desired protocol and password. The protocol can be RADIUS or TACACS+. Which protocol we will use depends on the use case. Generally speaking, when we try to access the network via VPN, we will most probably use the RADIUS protocol, but for accessing some of devices mentioned, for device administration, we will use the TACACS+.
Depending on request type or protocol the AAA client is using, we will chose appropriate Access Service. This access service will be chosen based on Service Selection Rules. By default we have two rules, one for each protocol, and a default rule that denies all requests. This deny rule might look as optional, because there is no third option: either the request is RADIUS or TACACS+. Let’s see this more vividly:
So, when a packet hits ACS, a service selection rules are examined to determine the type of access. Rule-1 says “if a packet is of type RADIUS, use the Default Network Access access service”. Rule-2 says “if a packet is a TACACS+ packet, use the Default Device Admin access service”. And the default rule at the bottom is explicit deny/drop rule.
Now each access service comprises of two sections: Identity and Authorization. Personally, I would like more that the Identity is called Authentication, because it more closely depicts first two As in AAA. However, under the Identity section we chose how to authenticate user, and under Authorization we actually authorize this user. Let’s see the defaults more closely:
This example is for Default Device Admin and shows that this access service will use internal ACS database to authenticate users. After user is authenticated, we then authorize him/her:
As we can see, if a users are authenticated, we just allow them access with a default PermitAccess rule. Here we can create our rules, depending on our needs. So, for example, we could use custom filters to authorize users different ways.
Let’s pay attention to the Result column. With the Default Device Admin, we can assign a Shell Profile to users, and/or Command Sets. With the Shell Profile we can assign a privilege level for users, for example, and with Command Sets we can authorize them to execute only specific shell commands.
For Default Network Access access service, we can also specify how we would like our users to be authenticated, under the Identity node, and instead of assigning them the Shell Profile or/and Command Sets, we assign them Authorization Profile. The assigned profile is displayed in the Results column:
By default the result is just a default profile called PermitAccess. Of course, here we can create our own rules that will assign different profiles for different conditions we specify.
Finally, as depicted on the first picture, we return a result to our users, if he/she is authenticated/authorized or not, and if he/she is, we return a set of attributes so they can be applied by the AAA client.
This was just the basics of how the ACS 5.x processes AAA requests. In the blogs that follow, we will see some practical examples.
Thanks for reading.