RADIUS Server Fail-Open

Aruba Employee

Summary : How to enable RADIUS Fail-Open in Mobility Access Switch

 

Introduction :

 

When wired users try to access a network where AAA servers are unreachable, they will be unable to authenticate and will continue to stay in the configured initial role. As a result, a user may effectively be blocked off the network due to a restrictive initial-role. To overcome this problem, ArubaOS provides support for RADIUS Fail-open. This feature enables the IT administrators to provide an alternate user-role (unreachable-role) to the users for network connectivity during a AAA server outage. When AAA servers are unreachable, the RADIUS Fail-open feature assigns the unreachable-role to the users trying to authenticate. The users will stay in the unreachable-role until at least one of the AAA servers is back in service.

 

Feature Notes :

 

 

Key Points to Remember:

A client remains in the initial role until all the AAA servers in the server group are processed. The unreachable-role is assigned to a user only when:

 

 

  • no intermediate role (such as UDR, MAC auth, and 802.1x machine-auth-machine-role) has been derived i.e. the user is still in initial role, and
  • the last AAA server in the AAA server group has been processed, and
  • if one or more AAA servers have timed out and the rest have failed the authentication, or if all the servers have timed out.
  • A role derived after authenticating UDR or MAC auth will have more privileges than the initial or unreachable-role.

 

A client will transition from the switch profile VLAN to AAA unreachable-role-based-VLAN only if:

 

  • AAA unreachable-role is assigned to that MAC, and
  • no intermediate VLAN has been derived.
  • AAA unreachable-role-based-VLAN (high priority) takes precedence over the switching profile's VLAN (low priority).

 

Clients that attempted AAA authentication and got timed out are added to the mac-in-unreachable-list table. This list also includes the clients that have derived an intermediate role (such as UDR and MAC auth) but failed AAA authentication due to time-out.
 

 

You can use the following command to view the list of clients in the unreachable-role:
 

 

(host) #show aaa mac-in-unreachable-list

 

Station Entry

 

-------------

 

MAC AAA profile Name AAA server Group Port
----------------- ---------------- ---------------- --------------------
00:60:6e:00:f1:7d dot1x mac gigabitethernet0/0/7
Entries: 1

When the dead timer has expired (default 10 minutes), the Mobility Access Switch sends a dummy authentication request to the AAA server (username: DummyArubaUser).

When the AAA server comes back in service, all the clients corresponding to that server group are cleared from the mac-in-unreachable-list table. The clients then re-attempt authentication

When a client is removed from the mac-in-unreachable-list table, the port to which it is connected is administratively disabled (shutdown) and then re-enabled (in 5 seconds). This is to ensure that the client initiates the DHCP process again when it re-attempts authentication. The port is administratively disabled and then reenabled in the following scenarios:
  • When all the clients on the same port are removed from the mac-in-unreachable-list table, if there are more than one client on the same port.
  • When aaa user delete command is executed to delete a client entry that is in the mac-in-unreachable-list table.
  • The port does not get shut when the client entry that is in the unreachable-role ages out due to AAA timer expiry..
  • the AAA server dead time expiry is set to 0, the clients that are in the unreachable-role are rolled back to initial role and are removed from the mac-in-unreachable-list table. No clients will be assigned the unreachable-role as RADIUS Fail-open gets disabled.
  • If a system switch over happens (the secondary switch becomes the new primary and the primary switch becomes the new secondary) in the network while RADIUS Fail-Open is active, the following process takes place:
The servers that were marked out of service in the old primary are marked as in-service in the new primary.
  • The user table entries for the clients that were in mac-in-unreachable-list table are deleted and their respective interfaces are administratively disabled and then re-enabled. These clients re-attempt authentication and derive a role based on the authentication outcome.
  • If the servers are still out of service during the authentication re-attempt, they will be marked as out of service
When more than one server is configured under a server group and when server-group fail-through option is disabled, then the unreachable-role is assigned to the user only if:
 
  • all the servers are out of service, or
  • when all the servers except the last one in the server group are out of service and the last one fails authentication.

 

Configuration Steps :

 

 

Enabling RADIUS Fail-Open:
 
RADIUS Fail-open is an optional configuration. It is enabled only if:
  • the unreachable-role is configured under the AAA profile, and
  • the AAA server dead time expiry feature is enabled (i.e. the dead time value is set above 0)
Configuring Unreachable Role:
 
Use the following command to configure the unreachable-role:
 
(host) (config) #aaa profile profile1
(host) (AAA Profile "profile1") # unreachable-role <user-role>
 
The following is a sample configuration:
 
(host) (config) #aaa profile profile1
(host) (AAA Profile "profile1") # unreachable-role new-role

 

 

Answer :

Limitations:
 
·         RADIUS Fail-Open is not supported when re-authentication timer is enabled.
·         RADIUS Fail-Open is not supported when EAP-Termination is enabled under 802.1x authentication profile.

When the unreachable-role is assigned to a captive portal user, the user may be misled to the welcome screen indicating that the authentication has succeeded. It is recommended to configure the Captive Portal Authentication Profile under the unreachable-role to avoid such misleading scenarios.

 

Verification :

 

 

Verifying Unreachable Role Configuration:
 
You can use the following commands to verify the unreachable-role configuration:
 
(host) #show aaa profile profile1
AAA Profile "profile1"
-------------------
Parameter Value
--------- -----
Initial role logon
MAC Authentication Profile N/A
MAC Authentication Default Role guest
MAC Authentication Server Group N/A
802.1X Authentication Profile dot1x-auth-profile
802.1X Authentication Default Role default-role
802.1X Authentication Server Group server-group
Download Role from ClearPass Enabled
L2 Authentication Fail Through Disabled
RADIUS Accounting Server Group N/A
RADIUS Interim Accounting Disabled
XML API server N/A
AAA unreachable role new-role
RFC 3576 server N/A
User derivation rules N/A
SIP authentication role N/A
Enforce DHCP Disabled
Authentication Failure Blacklist Time 3600 sec

(host)# show running-config
...
...
...
aaa profile "profile1"
authentication-dot1x "dot1x-auth-profile"
dot1x-default-role "default-role"
dot1x-server-group "server-group"
unreachable-role "new-role"
...
...
...

 

 

Troubleshooting :

 

 

(ArubaS1500-24P) #show aaa authentication-server  radius  statistics

 

 

 

RADIUS Server Statistics

 

------------------------

 

Statistics

 

----------

 

Accounting Requests

 

Raw Requests

 

PAP Requests

 

CHAP Requests

 

MS-CHAP Requests

 

MS-CHAPv2 Requests

 

Mismatch Response

 

Bad Authenticator

 

Access-Accept

 

Access-Reject

 

Accounting-Response

 

Access-Challenge

 

Unknown Response code

 

Timeouts

 

AvgRespTime (ms)

 

Total Requests

 

Total Responses

 

Uptime (d:h:m)

 

SEQ Total/Free

 

Orphaned requests = 0

 


(ArubaS1500-24P) #show aaa  authentication-server  ldap  statistics
 
LDAP Server Statistics
----------------------
Statistics
----------
Login Requests
Login Success
Login Failure
Login Timeout
Total Unbind Requests
  - Reason: Timeout
AvgRespTime (ms)
Uptime (d:h:m)
 
Related Links:
 

http://www.arubanetworks.com/techdocs/ArubaOS_73_Web_Help/Default.htm#mas_guides/aaa_authentication/Radius_Fail_Open.htm%3FTocPath%3DAAA%20Authentication|_____2

Version history
Revision #:
1 of 1
Last update:
‎11-10-2014 04:19 AM
Updated by:
 
Labels (1)
Contributors
Tags (1)
Comments

Should this feature be available for WLAN users as well?

The concern is that skipping user authentication, the clients will have something like an "open" authentication connection.

 

Would it be advisable that when Authentication Servers are unavailable, users will have a redundant/backup connection to another WPA2/AES SSID using a passphrase?

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: 
Is this a frequent problem?

Request an official Aruba knowledge base article to be written by our experts.