One of the limitations with Firepower Device Management (FDM) is that it does not allow creating multiple admin accounts for FDM GUI accesses. This means that all the admins will use the same admin account to log into the FTD, which leads to sharing the admin credentials between them. As security chaps we don’t like this, at least when possible. For CLI it is a bit different since we would be able to create multiple accounts, however, those accounts will only be valid for CLI accesses, not for GUI with the exception of the default admin account. The default admin account can interact with both CLI and GUI.

Now if we have the right tools in our environment that would allow us to workaround this limitation why not using them?!. To do so we need to rely on an external authentication (authC) and authorization (authZ) server and also on our AD to check against the interested AD group where the admin users would be located. The end result would be to have a centralized accesses through the external server for both SSH and HTTPS only if a user exists in a specific AD group. We will also create a read only HTTPS access in our lab. ISE is going to be our external RADIUS server which is already joined to a domain controller. let’s get started 🙂

Here is our topology, simple. We have our RADIUS server (ISE), FTD and our client, all on the same broadcast domain:



Let’s first start applying the configuration on ISE. We need to create a couple of authZ profiles and a policy set. One authZ profile will be for SSH and another for HTTPS access. The authZ profiles will be configured to return a specific attribute to the NAD based on the matched rule which will be used to apply the access level based on the received value. The FTD is already added to ISE as a network device.

We will start with the SSH profile and we will call it FTD_CLI. In this profile we will configure the RADIUS Service Type with Administrative as a value, this will allow the FTD to associate an admin access level to the session that is matching the policy set on ISE where this authZ is applied.

At the bottom of the authZ profile page in the Advanced Attributes Settings section click on the yellow little circle next to Select an item, scroll down and click on Radius:



Now from the RADIUS types list scroll down and click on Service-Type–[6]:



Now we need to click on the yellow little circle next to the empty filed and select Administrative as a RADIUS attribute value:



Let’s verify what we have in the Attributes Details section and finally click on Submit to save:



The second authZ profile we need to create is for HTTPS accesses. It is a bit similar to the one we’ve just created. However, in this profile we are going to use Cisco AV Pair instead of RADIUS. The value we are going to set is fdm.userrole.authority.admin. This value will allow the FDM to grant a full admin access through HTTPS to the session that is matching the policy set on ISE where this authZ is applied. There are three Cisco AV Pair that we can use for HTTPS accesses through FDM, one for a full admin, another for a restricted admin and the last is for a read only access. Here they are:




We will call this new profile FDM_HTTPS. Similar to what we’ve done before, at the bottom of the authZ profile page in the Advanced Attributes Settings section click on the yellow little circle next to Select an item, scroll down and click on Cisco:



Scroll down and click on cisco-av-pair–[1]:



Now we need to type the Cisco AV Pair attribute in the empty field. The value as we said above will be fdm.userrole.authority.admin, then click Submit to save:



Now let’s configure ISE policy set. The top condition in the policy set will check against the FTD management interface IP address, the authC rule will check against our AD, and finally the authZ rules will check against the AD group LabAdmins where the admin users will be located. Each authZ rule will apply a different authZ profile. One of the authZ rule will have one more condition which is the RADIUS NAS Identifier sshd, this condition will match the SSH connections. This is how the policy set looks like:



We have completed ISE configuration, let’s now move to the FDM. On the FDM we need to create ISE RADIUS server, a RADIUS group and finally associating this RADIUS group to the management accesses for both SSH and HTTPS.

From the FDM main landing page go to Objects and then go to Identity Sources:




Click on the + sign to the right and click on RADIUS Server, and then insert ISE RADIUS server details along with the RADIUS preshared key which is the same as the one that has been configured on ISE when the FTD was added as a network device:




Now we need to click one more time on the + sign but this time to create the RADIUS group and add the RADIUS server we created previously to it. We will call the group ISE_RADIUS:




You might be wondering why we need to create a RADIUS server group if we have only one single RADIUS server!. The answer is because from the management access configuration page we cannot point to an individual RADIUS server as an identity source, only a RADIUS server group is supported.

Now we need to go back to the FDM landing page and click on Management Access. In both HTTPS and SSH sections click on the Server Group and change it from LocalIdentitySource to be the new RADIUS group we’ve created which is ISE_RADIUS:






The Authentication with LOCAL option is to provide a fallback in case the external server is not reachable. Although we can change the order for HTTPS connection the default order is Before External Server.

Now that we changed the server groups we need to click on Save under each section. When we click on Save button for each section we will see an individual Successfully saved. message on the page:



Now it is time to deploy the changes. To deploy the changes go to the FDM landing page and click on the Deployment icon on the top right and click on Deploy Now:




We would see a similar window to this whilst the changes are being deployed to the FTD:



Once the changes have been successfully deployed, we should see a similar window to this:



Finally it is time to test :). We will first start with SSH connection, the username we will use is admin1:



It does not seem to be working right?!. Let’s have a closer look at the output:



We can see that the FTD purposely disconnected our session, and it is asking us to log in again to start our session. The reason behind this is that first time a user connects to the FTD, the FTD creates kind of a profile for that user, this does not mean that the user is added to the local database, it is instead kind of creating a space for that user before the FTD be able to create a session for the user. The FTD can’t do this operation and creating a user session at the same time, this is why the connected user gets disconnected by the FTD. Next time the user connects everything should work as expected, we will verify this in two seconds.

One thing to keep in mind here is that not all the emulators would show you that message, for example Putty does not show any thing, its window just gets disappeared, other software like Xshell which we are using shows us that message because Xshell uses a landing page where the output of the previous session will still show up after the session is disconnected.

Now let’s try again and see if this time it works:



This time it worked! Let’s see what logs do we have on ISE for this connection:



All looks good! Now let’s test the HTTPS access, the username of the admin we will use is the same we used for SSH which is admin1:



Also HTTPS worked as expected and as we can see the session has been successfully done with admin1 account, and underneath the account name we can see that the user role is Administrator. ISE logs look good as well, we can see that the FDM_HTTPS authZ profile has been applied:



Last thing we are going to do for this lab is to create a read only policy for HTTPS access, just for fun. Here are the relevant changes on ISE. We created a new authZ profile called FDM_HTTPS_ReadOnly and we assigned the Cisco AV Pair value, and then we added a new authZ rule to the policy set to match the AD group Group_Test1 to which the read only user account rouser belongs:




Let’s do some tests:



As we can see, FDM clearly states that the user rouser is a read only user, but by looking at the FDM landing page we don’t seem to have any less options comparing to when we logged in as admin! The thing is that although we see all those configuration parts, if we try to make any changes we will get an error complaining about our restricted role similar to this:



I hope you enjoyed reading this post, and as always, I would love to hear your feedback. Thanks for reading!


Did you like this post?

Click on a star to rate it!

Average rating / 5. Vote count:

Follow me on social media!

I am sorry that this post was not useful for you!

Share via: