Mobility Access Switch Configuration for 802.

1X Wired Authentication
This section describes how to configure the Mobility Access Switch (MAS) for 802.1X wired authentication. This section
contains the following information:
About Defining Wired 802.1X Authentication
Configuring Authentication with a RADIUS Server
Authentication Terminated on the Mobility Access Switch
Configuring Access Control Lists

About Defining Wired 802.1X Authentication

Port-based 802.1X authentication on the Mobility Access Switch is configured similarly to how it's done on the mobility
controller, the main difference being the AAA profile is applied on a wired interface or interface-group, as opposed to a
Virtual Access Point (VAP) on the mobility controller.
Figure 1 shows the network traffic flow for wired clients that connect to a Aruba Mobility Access Switch or a third-party
switch and perform 802.1X authentication to the ClearPass Policy Manager server.

Figure 1  Traffic flow for 802.1X Wired Authentication with Active Directory

The configuration process is as follows:

1. Define an external RADIUS server or create an internal database.
2. Define a server group and apply one of the servers above to this server group.
3. Create 802.1X authentication profiles.
4. Apply the server group to each of the 802.1X authentication profiles.
5. Apply the 802.1X authentication profiles to an AAA profile.
6. Apply the AAA profile to the physical interface or interface group.

You can now configure an interface for 802.1X authentication.

Configuring Authentication with a RADIUS Server

In order to authenticate to the network, the client communicates with the Mobility Access Switch through an EAP tunnel
(see Figure 2). Therefore, the network authentication and encryption configured must be the same on both the client and
the Mobility Access Switch.

Figure 2  802.1x Authentication with a RADIUS Server

To configure 802.1X authentication with a RADIUS server:
1. For the Mobility Access Switch to communicate with the authentication server, you must configure the following
paramters on the Mobility Access Switch:

Parameter Action/Description

IP address 1. Enter the IP address of the authentication server.

Authentication port 2. Enter the Authentication port number on the authentication server. Default: 1812.

Accounting port 3. Enter the Accounting port number on the authentication server. Default: 1813.

4. You must configure the supplicant (the client device) and authentication server (the Mobility Access Switch) to use the
same EAP type.
The Mobility Access Switch doesn't need to know the EAP type used between the supplicant and authentication server.
5. You must configure the authentication server with the IP address of the RADIUS client, which in this case is the Mobility
Access Switch.
6. Be sure to configure both the Mobility Access Switch and the authentication server to use the same shared secret.
 

Additional information on EAP types supported in a Windows environment for Microsoft supplicants and the
authentication server is available at http://technet.microsoft.com/en-us/library/cc782851(WS.10).aspx.

Authentication Terminated on the Mobility Access Switch

User authentication is performed either via the Mobility Access Switch’s internal database or a non-802.1x server.

Figure 3  802.1x Authentication with Termination on the Mobility Access Switch

In this scenario, the supplicant is configured for EAP-Protected EAP (PEAP) or EAP-Transport Layer Security (TLS).

EAP-PEAP
EAP-PEAP uses TLS to create an encrypted tunnel. Within the tunnel, one of the following “inner EAP” methods is used:
EAP-Generic Token Card (GTC)
Described in RFC 2284, this EAP method permits the transfer of unencrypted usernames and passwords from client to
server. The main uses for EAP-GTC are one-time token cards such as SecureID and the use of an LDAP or RADIUS
server as the user authentication server.
You can also enable caching of user credentials on the Mobility Access Switch as a backup to an external
authentication server.
EAP-Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAPv2)
Described in RFC 2759, this EAP method is widely supported by Microsoft clients. A RADIUS server must be used as
the backend authentication server.

EAP-TLS
EAP-TLS is used with smart-card user authentication. A smart card holds a digital certificate which, with the user-entered
personal identification number (PIN), allows the user to be authenticated on the network. EAP-TLS relies on digital
certificates to verify the identities of both the client and server.
EAP-TLS requires that you import server and certification authority (CA) certificates onto the Mobility Access Switch. The
client certificate is verified on the Mobility Access Switch (the client certificate must be signed by a known CA) before the
user name is checked on the authentication server.

Internal Database Configuration Task

If you are using the Mobility Access Switch’s internal database for user authentication, you need to add the names and
passwords of the users to be authenticated.

LDAP Server Configuration Task

If you are using an LDAP server for user authentication, you need to configure the LDAP server on the Mobility Access
Switch, and configure user IDs and passwords.

RADIUS Server Configuration Task

If you are using a RADIUS server for user authentication, you need to configure the RADIUS server on the Mobility Access
Switch:
For details, see Configuring Authentication with a RADIUS Server.
For the CLI example, see Examples of Common 802.1X Configuration Tasks Via the CLI).

Configuring Access Control Lists

To provide flexibility for controlling traffic, ArubaOS in Mobility Access Switches supports multiple types of Access Control
Lists (ACLs).
Ethertype ACL

Ethertype ACLs filter based on the Ethertype field in the frame header. Ethertype ACLs can be either named or numbered,
with valid numbers in the range from 200 to 299. These ACLs can be used to permit IP, while blocking other non-IP
protocols, such as IPX or AppleTalk.

MAC ACL

MAC ACLs filter traffic on a specific source MAC address or range of MAC addresses. MAC ACLs can be either named or
numbered, with valid numbers in the range from 700 to 799 and 1200 to 1299.

Standard IP ACL

Standard ACLs permit or deny traffic based on the source IP address of the packet. Standard ACLS can be either named or
numbered, with valid numbers in the range from 1 to 99 and 1300 to 1399. Standard ACLs use a bit-wise mask to specify
the portion of the source IP address to be matched.

Extended IP ACL

Extended ACLs permit or deny traffic based on the source or destination IP address, or the IP protocol. Extended ACLs can
be named or numbered, with valid numbers in the range from 100 to 199 and 2000 to 2699.

Stateless ACL

Stateless ACLs define stateless packet filtering and quality of service (QoS). A stateless ACL statically evaluates packet
contents. The traffic in the reverse direction is allowed unconditionally.

Note that you can use names only when configuring stateless ACLs.

Configuring a Stateless ACL

To configure a stateless ACL:
(ArubaSwitch) (config) #'''ip access-list stateless STATELESS'''

(ArubaSwitch) (config-stateless-STATELESS)#'''any host 192.16.0.100 tcp 0 65535 permit'''

Applying a Stateless ACL on a Physical Interface

To apply a stateless ACL on a physical interface:
(ArubaSwitch) (config) #'''interface gigabitethernet 0/0/8'''

(ArubaSwitch) (gigabitethernet "0/0/8") #'''ip access-group in STATELESS'''

Applying a Stateless ACL to a User Role

To apply a stateless ACL to a user role:
(ArubaSwitch)(config) #'''user-role EMPLOYEE_1'''

(ArubaSwitch) (config-role) #'''access-list stateless STATELESS'''

 

You can also apply MAC and Ethertype ACLs to a user role. However, these ACLs apply only to a user's non-IP traffic.

Verifiying Stateless ACL Configuration

To verify a stateless ACL configuration:
(ArubaSwitch) #'''show ip access-list STATELESS'''

Verifying Stateless ACL Traffic Hits

To verify stateless traffic hits:
(ArubaSwitch) #'''show acl hits'''

Verifying Stateless ACL Operation

To verify stateless ACL operation:
(ArubaSwitch) # '''show acl acl-table'''