AAA Authentication on Cisco IOS

Lessons Discussion
81

Hello, I’ve went through this lesson and also check the guide from Cisco but there are still some confusions.

" Enter a case-sensitive password that is common among users who access this RADIUS authorization server via the Cisco ASA under the Common Password field. If you do not use a common password, the user’s username is used as the password when accessing the RADIUS authorization server."

I thought when users access VPN, VPN send the requests to the radius server for authentication, why do we still need a common password?
What is the differences between key and radius-common-pw?
The shared key that we configured in the radius server should be key, right?

After setting up the VPN for test, I received “You have no dial in permission”, what could be the issue?

82

Hello Po

This is a good question. After doing some research, I have found that the radius-common-pw parameter is used internally by the ASA for its communication with the RADIUS server for all authorization transactions. More about it can be found at this ASA command line reference. The syntax is:

radius-common-pw string

It states:

The RADIUS authorization server requires a password and username for each connecting user. The ASA provides the username automatically. You enter the password here. The RADIUS server administrator must configure the RADIUS server to associate this password with each user authorizing to the server via this ASA. Be sure to provide this information to your RADIUS server administrator.

If you do not specify a common user password, each user password is the username. If you are using usernames for common user passwords, as a security precaution, do not use the RADIUS server for authorization anywhere else on your network.

It also says (interestingly):

The string argument is essentially a space-filler. The RADIUS server expects and requires it, but does not use it. Users do not need to know it.

So this configuration is optional, but the administrator of the RADIUS server must know what has been configured in order to correctly communicate with the ASA. Note also, that this password is used only for internal communication between the ASA and the RADIUS server, and only for authorization mechanisms. End users don’t need to know this password. They simply use their own credentials.

The “key” parameter is used for authentication. This authenticates the ASA to the RADIUS server. More about this can be found at this CiscoPress article.

This error typically means that the user account trying to connect through the VPN does not have permission to dial in. This could be due to several reasons which may be related to the key or the common password, or even the credentials of the user. You would typically have to start troubleshooting by checking the user’s permissions in the RADIUS server. Then you should try to verify your configs on the ASA and the RAIDUS server.

I hope this has been helpful!

Laz

83

can you suggest fore me free RADIUS server high-performance , such as ISE?

84

Hello Ridhwan

There are several free RADIUS servers that are high-performance and can be a suitable alternative to Cisco’s ISE. Here are a few options:

  • FreeRADIUS: This is one of the most popular open-source RADIUS servers in use today. It supports all common authentication protocols and is known for its flexibility and high performance.
  • Radiator: This is a highly configurable and flexible RADIUS server. It supports a wide range of authentication methods and has excellent performance. However, while it’s not completely free, it does offer a trial version.
  • PacketFence: This is a fully supported, trusted, Free and Open Source network access control (NAC) solution. It provides a lot of features like registration, detection of abnormal network activities, isolation of problematic devices, etc.
  • daloRADIUS: It’s a web-based application for managing RADIUS server. It’s built on top of FreeRADIUS, so it provides a user-friendly interface to manage the complex functionalities of FreeRADIUS.

Remember, while these solutions are free or offer free versions, you might need to invest time to learn how to properly configure and manage them.

I hope this has been helpful!

Laz

85

Hello Laz,

I looked through the past replies and google before asking this question:
Unable able to login to privilege mode as either user after getting access to enable mode
I can login with the configured local user LOCAL_ENABLE successfully when the radius server is
down but logging in as a configured radius user does not work

FYI : I’m using ISE as a Radius Server, and all of the aaa configuration on my switch is working good. I suspens that my switch can’t read the attribut of privilege 15 send it from ISE : cisco -av-pair = priv-lvl=15

Can u please give me your opinion about this issue ?

Thanks for advance Laz !

86

Hello Abderrahmane

Based on your descriptions, I can make some assumptions concerning the issue you are facing, and hopefully, my thoughts will help you in your troubleshooting process. At this point, I don’t believe the problem is related to the shell:priv-lvl=15 attribute.

The lesson is demonstrating two separate authentication processes:

  1. The user authenticates to gain access to the CLI.
  2. The user types enable and authenticates separately to gain access to privileged EXEC mode.

When Cisco IOS performs RADIUS authentication for the enable command, it does not normally send the username of the user who initially logged in. Instead, it sends a special username based on the requested privilege level: $enab15$

Therefore, ISE must be able to authenticate a request using the username $enab15$ and the password that you want users to enter after typing enable. The relevant IOS configuration should look similar to this:

aaa authentication enable default group radius enable

Here, the device first tries the RADIUS server. The final enable keyword means that the locally configured enable secret is used only as a fallback if the RADIUS server is unavailable.

This explains why your local enable password works when ISE is down. However, while ISE is reachable, the switch sends the enable authentication request to ISE using $enab15$. If ISE does not recognize or permit that username, it will return an Access-Reject, and IOS will not try the local enable secret.

The attribute: cisco-AVPair = shell:priv-lvl=15 is used for a different approach. It can place a user directly into privilege level 15 after the initial login, provided that EXEC authorization is configured. It is not required for the separate enable authentication method demonstrated in this lesson.

I suggest checking the ISE Live Logs while entering the enable command. You should see an authentication request with a username similar to: $enab15$. Check whether ISE is rejecting that username and which policy set and authentication rule are being matched.

You can also use the following debugging commands on the switch:

debug aaa authentication
debug radius authentication

Let us know how you get along and if you’ve resolved your issue!

I hope this has been helpful!

Laz

87

Laz, I just want to thank you for it. Your assumptions were the key to the solution.

What you said about the username $enab15$ is totally correct. When my Server Radius (ISE in my case) is reachable, the switch doesn’t send the username of the user who initially logged in. Instead, it sends a special username called: $enab15$:

image

Logs on ISE:

ISE doesn’t have a username called $enab15$ in its database, so the request matches the default policy and gets denied due to the deny ACL.

image

So after that, I created a new username identity on my Radius Server (ISE) using this username: $enab15$ with a different password. Then, I got logged in on my switch :slight_smile: .

ISE Logs after I got successfully logged in:

image

88

Hello Abderrahmane

That’s great to hear! Yeah, that’s a particular behavior of RADIUS using that username for the enable mechanism. And this information is extremely useful for others who are deploying a similar setup, so thanks for sharing your results.

Your fix was the right way to go, creating a user identity on ISE with that username and password. Just a note, if your deployment ever uses TACACS+ instead of RADIUS for device administration, this $enab15$ user and mechanism doesn’t apply in the same way. TACACS+ handles enable authentication differently and is often preferred for admin access for this reason. But with RADIUS, you’ve nailed the behavior and the solution perfectly.

Thanks for following up with the solution to your issue!

I hope this has been helpful!

Laz