• 06/23/2014
    7:00 AM
    Ethan Banks
  • Ethan Banks
  • Commentary
  • Connect Directly
  • Rating: 
    0 votes
    Vote up!
    Vote down!

Network Device Management, Part 2: Implementing AAA

Securing remote access to network devices is essential. Here are some tips for authentication, authorization, and accounting.

The previous post in this series on network device management addressed SNMP and logging management for network devices -- two important elements not only for managing the devices themselves, but also for reacting to events happening on the network. In this post, I'll discuss controlling access to the network devices themselves, as well as a strategy for limiting what folks can do once they're logged in.

Authentication, authorization, and accounting
The common abbreviation for authentication, authorization, and accounting is AAA. AAA is controlling who has access to a device, controlling what people can do when they've been granted access, and tracking their behavior throughout the session. Since most devices are still managed via the CLI or a GUI, AAA remains an important tool to control device access. Here are some tips for implementing AAA:

1. Authenticate externally, but fail back locally. AAA typically allows a network device to authenticate a user requesting device management access via RADIUS, TACACS, LDAP, or Microsoft Active Directory. Each of these external methods has its pros and cons, but all have one common advantage: the ability to log user authentication requests centrally. Also, these methods help with single sign-on, where a user's credentials housed in a central database can be used by the network device to authenticate a login request.

The issue is that sometimes these external authentication methods fail. RADIUS servers crash, and any server might become slow or unreachable. In these cases, the network device needs to timeout the external authentication request and fail to a local user database. This ensures that the device can still be managed even if no external servers are available.

2. Authorization can be valuable but difficult to manage, so keep it simple. Authorization is controlling what authenticated users can do once they've connected to a device. The concept is powerful, but in practice it can be difficult to manage, usually requiring a tool like Cisco Access Control Server or Identity Services Engine. From a practical standpoint, I've found the following authorization schemes useful.

First, have all-powerful users who can do anything; that's where the network engineering staff is going to work. Second, have a restricted set of read-only commands available to employees like NOC staff -- folks who will diagnose a problem but not resolve it. Third, have a restricted set of commands available to automated processes like scripts or network management stations -- devices that only need to do very specific tasks, but whose account should never be used for anything else. This prevents folks from obfuscating their tracks by logging in with an account reserved for scripts.

3. Accounting requires someone to keep up with the data. Accounting data is generated by a network device back to a AAA server. The AAA server archives what users have done in their session in the accounting logs. The question is then one of what is done with that log data. There are a couple of typical scenarios. One is that the accounting data is checked only when there's been some sort of a network outage. When reconstructing the events that led up to a critical failure, accounting data can be very helpful. "Oh, I see. At 1:15 p.m., Bob logged into the core router and typed, 'no router ospf 1.' Well, that would do it. Bad, Bob! Bad!!"

The second scenario is that someone is assigned the duty of checking through accounting logs each and every day. To be fair, I've never worked with an organization that took this step, but it's an interesting idea that could be useful in highly secure shops. What I see more often is a daily "diff" report sent to key IT staff members, which shows how a network configuration has changed.

Next steps
With AAA sorted out, another overlooked area in managing network devices is time management. There are a couple of areas related to time that I see frequently neglected. One is that of time synchronization. How should time be synchronized? And what time zone should be reflected? Once that is sorted out, there's a question of how to make the best use of that all-important time signature. In the next installment of this series, we'll explore the issue of network device time.


essential security

Organizations would do well to spend more time on AAA. Using shared generic credentials across network devices opens up huge vulnerabities. 



Re: essential security

@MarciaNWC: "Organizations would do well to spend more time on AAA. Using shared generic credentials across network devices opens up huge vulnerabities."


Right - not only is there a lack of accountability internally (because you never know who uses the account), let's be honest - who goes back and changs that password when somebody leaves the team, or worse, the company? You can have an employee who is fired, perhaps, who knows the network design, knows the standard admin username/password, and may wish for retribution.

So in addition to any AAA management and password policies, this is also a good time to confirm that your (in Cisco language) vty access-class policies are in good shape, and logins are only accepted from authorized internal sources. You certainly never want access available from the Internet, for example.

Authorization management

One of the most overlooked issues is the actual management of authorization and priviledges.

Large IT deparments usually forget to revoke authorization levels for employees that no longer need them or the ones that have different resposibilities. That has created serious problems.

Re: Authorization management

That's a really important point Pablo. Neglecting to revoke access, especially after an employee leaves the company, is a huge risk. I think security vendors have tried to address this with various automated role management systems, but it seems like a tricky area.

Re: Authorization management

Marcia, I've seen this issue happening more when an employee changes roles within the organization. Many times he/she gets addtional network or IT priviledges but the ones no longer needed are not revoked.

Even today, after all the hacking and security problems organizations face from the outside, most of the security breaches and intentional damage come from the inside.

Re: Authorization management

True, so much is made of the outside hacker threat that organizations can overlook the bigger insider threat. Michele Chubirka, a Network Computing blogger, wrote an interesting blog post last fall that examined the risks stemming from poor design and bad planning.


Re: Authorization management

@Pablo: "I've seen this issue happening more when an employee changes roles within the organization. Many times he/she gets addtional network or IT priviledges but the ones no longer needed are not revoked."

Pablo speaks the truth. The underlying issue of ensuring that AAA accounts are closed out when an employee leaves can usually be solved if you marry your AAA solution to LDAP fro your Active Directory servers. This works because when employees leave, most companies do seem to have a "disable their domain account" notification. Not all, mind you, but most I think, as part of a standard TERM process.

However when an internal move occurs, that process is not triggered and Pablo is absolutely correct about what can happen.


Re: Authorization management

Thank you John, 

Actually I've seen this problem more with software licenses, especially SaaS platforms such as SAP and Oracle. The licensing system is so complicated that IT just adds new priviledges to the user account without auditing what he/she doesn't need anymore. This not only poses a security threat but also costs a lot of money in addtional licenses not needed.