Cisco IOS 23 - User authentication on the switch against Active Directory

The basic protection of access to switch configuration is the use of authentication. We can protect access to privileged mode with a password. We can also define combinations of usernames and passwords that will be used when accessing the switch (via console, telnet, ssh, etc.). We can define these accounts locally on the switch, but we can also use a central directory, such as MS Active Directory, and utilize a RADIUS or TACACS+ server. We can also assign privilege levels (i.e., authorization) to accounts, which the user will gain after logging in.

Password for accessing privileged mode

The enable password consists of a string of 1 to 25 alphanumeric characters, must start with a letter, and is case-sensitive. We can enter the password so that it is stored in the configuration in plain text or only its MD5 hash is stored. If we don't specify otherwise, the privilege level is set to 15 (options are 0 to 15, 15 is the highest).

SWITCH(config)#enable password Password // unencrypted password 
SWITCH(config)#no enable password    // removes the password
SWITCH(config)#enable secret Password   // encrypted password

If we want to set a lower privilege level, we can enter it along with the level.

SWITCH(config)#enable secret level 10 Password 

Note: By default, only levels 1 (user mode) and 15 (privileged mode) exist. If we want to use more detailed permissions, we must define additional levels using the privilege command.

When we enter an enable secret password, we will see it encrypted in the configuration. The command then contains the encryption type (5) and the password hash.

SWITCH(config)#enable secret 5 $1$x5YQ$lVO5XFIA19d06rYOPJb3G/ 

Creating local users

Enable password protects access to privileged mode (after entering the enable command), but it doesn't protect access to the device itself (and thus to user mode). Only one can exist for each level. As another layer, we can create local users (i.e., a combination of username and password) and then assign them as an authentication source to various places, such as access to the switch via console. We can enter users with or without specifying privileges. The same rules apply to passwords as for the enable password.

SWITCH(config)#username admin secret Password
SWITCH(config)#username admin privilege 15 secret 5 $1$VdJx$jU4LU/TtOsJjd2iHS/gAh0 

Using RADIUS server for authentication

In a larger environment and for more manageable user administration, it's certainly useful to use a central directory (such as MS Active Directory). We can set up authentication against the directory using a RADIUS server. On the switch, the AAA component - Authentication, Authorization, Accounting - is used for this purpose.

First, we must define at least one RADIUS server. It's better to use two for redundancy. Optionally, we can specify UDP ports for authentication and accounting.

SWITCH(config)#radius-server host 10.0.0.10 auth-port 1645 acct-port 1646 key 1234567890

Next, we create a named list of authentication methods. This list determines which methods and in what order they will be used. We then apply this list to certain access lines. By default, there is a default list that is applied to all lines. We can modify the parameters of the default list or create a new one.

In the example, we create a list named RADIUSauthGroup. We set two methods for this list: first, local users will be tried - local, and if unsuccessful (but also not returning that an incorrect password was entered), then the RADIUS server will be tried - group radius.

Note: When using RADIUS, it's important to remember certain crisis situations when this server is not available. Therefore, it's necessary to have some local method for logging in as well.

SWITCH(config)#aaa new-model      // turns on AAA
SWITCH(config)#aaa authentication login RADIUSauthGroup local group radius

Other possible methods for authentication are enable - uses the password for accessing privileged mode (must be set first) and line - uses the password set for the line.

After creating the list, we need to apply it to an input. In the example, it's access via console.

SWITCH(config)#line console 0     // select the line, here console
SWITCH(config-line)#login authentication RADIUSauthGroup  // apply the authentication list

Similarly, we can change the methods used for authentication to privileged mode. Here we can only change the default behavior and replace the enable method with, for example, none (no password). When using a RADIUS server, there's an issue here because we don't enter a username (a special string $enab15$ is used), but only a password.

SWITCH(config)#aaa authentication enable default none

When logging in via RADIUS, we can also arrange to go directly to privileged mode after logging in (and not have to enter the enable command and possibly a password). We do this by setting authorization on VTY and passing the AV pair shell:priv-lvl=15 from the RADIUS server. Along with authorization, authentication must also be set.

Note: I don't know why, but this setting doesn't work for the console. When debugging, it's visible that the whole process behaves a bit differently.

SWITCH(config)#aaa authorization exec RADIUSauthGroup local group radius
SWITCH(config)#line vty 0 4       // select the line, VTY 0 to 4
SWITCH(config-line)#authorization exec RADIUSauthGroup  // apply the authorization list

Security checks for logging in

IOS offers us several control mechanisms for monitoring logins to the switch. The first option is logging failed login attempts or sending an SNMP trap. The following command will log a message for each failed login. We can also add the keyword every to the command, which ensures that the message is stored only after a specified number of failed logins.

SWITCH(config)#login on-failure log  // creates a log entry
SWITCH(config)#login on-failure trap // sends an SNMP trap
SWITCH(config)#login on-failure      // creates a log entry and sends an SNMP trap

In the same way, we can also log successful login attempts. The record includes the username and IP address from which the login is made, which can be useful to monitor.

SWITCH(config)#login on-success log

We can also add protection against Brute Force attacks to discover the password (various passwords are automatically tried until the correct one is guessed). We can set how many failed login attempts can be made in a certain time; when exceeded, the switch switches to quiet-mode, where it doesn't accept logins. The first value in the command (60s in the example) means the number of seconds the switch switches to quiet mode (doesn't accept logins). The second value is the number of failed login attempts (3 here). And the last is the time interval (60s in the example) in which the specified number of failed logins must occur for it to switch to quiet mode.

SWITCH(config)#login block-for 60 attempts 3 within 30

When the switch switches to quiet-mode, an ACL is applied that blocks all login attempts via telnet, ssh, and http. If there was a targeted attack on the switch that would constantly block logins, it would block access for us too. Therefore, we can set up a security measure, which is an ACL that is applied after switching to quiet-mode, which allows us to log in from one specific IP address, for example.

SWITCH(config)#access-list 10 permit 10.0.0.5
SWITCH(config)#login quiet-mode access-class 10

We can also set one more parameter, which is the delay after which login attempts (successful or unsuccessful) can follow. We can enter 1 (which is the default value) to 10 seconds.

SWITCH(config)#login delay 10

We can check what values we have set with the following command.

SWITCH#show login

Authentication for web access HTTP(S)

Above, we described how to set up authentication (and possibly authorization) and assign it to access via console, telnet, or ssh. We can use the same method for authentication when accessing the switch's web interface. We can use the default list where we define the use of the RADIUS server. We must set both authentication and authorization, and then assign them with one command.

SWITCH(config)#aaa authentication login default group radius
SWITCH(config)#aaa authorization exec default group radius
SWITCH(config)#ip http authentication aaa

Or we create a new named list of authentication methods and assign it to authentication and authorization on the web.

SWITCH(config)#aaa authentication login WEB group radius
SWITCH(config)#aaa authorization exec WEB group radius
SWITCH(config)#ip http authentication aaa login-authentication WEB
SWITCH(config)#ip http authentication aaa exec-authorization WEB

Non-functional authentication from RADIUS to web

When I was dealing with authentication on the switch's CLI and simultaneously to the web interface, I encountered a problem that is widely discussed on the internet (although I don't know if successfully). It happens that we have created a list and it works beautifully for CLI. We just add a command to use it for http as well, and there we keep getting a pop-up window asking for login credentials.

Note: In older versions of IOS, there was only the command ip http authentication aaa, so a named list couldn't be specified and default was always used.

The situation can occur even if we have a separate list for logging in from the web, like the following.

SWITCH(config)#aaa authentication login WEB local group radius
SWITCH(config)#aaa authorization exec WEB local group radius
SWITCH(config)#ip http authentication aaa login-authentication WEB
SWITCH(config)#ip http authentication aaa exec-authorization WEB

If we turn on debugging, we see that authentication passes fine, but there's an error with authorization and the following is written to the log:

HTTP: Authentication failed for level 15

On the RADIUS server, there are two requests at the same second. The first passes fine (granted access), but the second doesn't (denied access). I couldn't figure out what was wrong with the query. During authentication from CLI, only one request is sent and its data is used for authorization as well.
In any case, the whole problem lies in the fact that in the list for authorization, there was still the local method before RADIUS. If we remove it, everything works fine.

SWITCH(config)#aaa authentication login WEB local group radius
SWITCH(config)#aaa authorization exec WEB group radius
SWITCH(config)#ip http authentication aaa login-authentication WEB
SWITCH(config)#ip http authentication aaa exec-authorization WEB

The problem is that we can choose either authentication against the RADIUS server or local users, but not both.

Sample configuration

An example configuration that sets up login via RADIUS server to the console, the first five VTY (telnet) and the web.

SWITCH(config)#enable secret Password  
SWITCH(config)#username admin secret Password
SWITCH(config)#radius-server host 10.0.0.10 auth-port 1645 acct-port 1646 key 1234567890
SWITCH(config)#aaa new-model 
SWITCH(config)#aaa authentication login RADIUSauthGroup local group radius
SWITCH(config)#aaa authorization exec RADIUSauthGroup local group radius
SWITCH(config)#aaa authentication login default group radius
SWITCH(config)#aaa authorization exec default group radius
SWITCH(config)#ip http authentication aaa
SWITCH(config)#line vty 0 4
SWITCH(config-line)#login authentication RADIUSauthGroup
SWITCH(config-line)#authorization exec RADIUSauthGroup
SWITCH(config)#line console 0
SWITCH(config-line)#login authentication RADIUSauthGroup

Parameters of access lines to CLI

To complement, here's some more information about access to CLI.

Access to the switch's CLI (Command Line Interface) is possible in several ways, which are collectively referred to as lines - line. The main types are CON - Console (referred to as CTY), which is access via the serial (console) port of the device. Then VTY - Virtual Terminal, logical (software) lines (they don't physically exist) which are used for network access, typically using the telnet protocol, or SSH (or others). AUX - Auxiliary, an auxiliary port, only some devices have it and it's a second physical serial port. The last option is TTY, asynchronous serial ports that can be used to connect serial modems or printers, usually on an additional card.

SWITCH(config-line)#logging synchronous    // prevents messages from being displayed in the typed text in CLI
SWITCH(config-line)#exec-timeout 0 0       // turns off timeout during inactivity (otherwise, enter number of minutes and seconds)
SWITCH(config-line)#session-timeout 3      // how long until the session expires in minutes, similar to the previous one
SWITCH(config-line)#transport input telnet // access to this line is via telnet protocol
SWITCH(config-line)#length 0               // number of lines on the screen, 0 means don't stop
SWITCH(config-line)#password Password         // sets a password for access to this line

Example configuration of MS IAS - RADIUS server

To make the description in this article complete, I'll briefly add how to set up Microsoft's RADIUS server to work with the above configuration.

A component of MS Windows Server 2003 is the Internet Authentication Service (IAS), which includes a RADIUS (Remote Authentication Dial-in User Service) server. In Windows Server 2008, RADIUS is also present, but the component (here role) is called Network Policy and Access Service. The configuration is similar in both cases, my description is for the 2003 version. If we have the Enterprise version of the OS, we gain one advantage: we can define clients using a range.

Creating a client

• open the IAS console
• right-click on RADIUS Clients and select New RADIUS Client
• enter a Friendly name, by which we'll distinguish clients, and Client address, in the Standard version we can only enter one address and then we must create a RADIUS client for each switch, in Enterprise we can enter an entire subnet using CIDR
• we can set Client-Vendor to Cisco and enter the numeric code we set as key on the switch for Shared secret

Creating a policy

At the beginning, we need to consider how we want to determine users who will have access to the switch. I find creating a special security group (Security Group) and including the required users in it most appealing.

• right-click on Remote Access Policies and select New Remote Access Policy
• enter a name for the policy Policy name and check Set up a custom policy
• for Policy conditions choose Windows-Groups, where we select the groups our users belong to, and Client-Friendly-Name, where we enter the name of the RADIUS client (or the beginning and * for any characters to cover multiple clients at once)
• select Grant remote access permission and click on Edit Profile
• on the Advanced tab, remove the attributes and insert the attribute Service-Type with the value Login
• and an attribute with the value Vendor-Specific, where we add the attribute Select from list: Cisco, Yes, it conforms, Configure Attribute - Vendor-assigned attribute number: 1, format: string, Attribute value: shell:priv-lvl=15
• on the Authentication tab, check only Unencrypted authentication (PAP, SPAP)
• on the Encryption tab, check No encryption