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.
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.