Delayed Radius Access-Reject response may cause authorization from local accounts to be possible

book

Article ID: 168122

calendar_today

Updated On:

Products

XOS

Issue/Introduction

The default timeout setting of 3 seconds for "radius-server" XOS command may not be long enough if the Radius server uses the "delayed Access-Reject response" feature.Even with correctly configured radius-server it may be possible under certain circuimstances (see below) to bypass Radius and authenticate as a local user instead.

Cause

XOS command "radius-server" has a default timeout of 3 seconds while it waits for the reply (positive/negative) from the Radius server. However, in cases where the Radius server is using a "delayed Access-Reject response", the negative reply might not come back soon enough and XOS will fall back to another Radius server in the list, or, if no other radius-server is present, it falls back to a local authentication.

Example of the Radius server configuration which can cause such behaviour (FreeRADIUS):

radiusd.conf:
cleanup_delay = 5
reject_delay = 5

(request gets rejected as per reject_delay value or a cleanup_delay in case the latter one is lower)

Resolution

Configure XOS radius-server with a timeout value which is higher than a "delayed Access-Reject response" as configured in the Radius server.

Example:
CBS# configure radius-server host 192.168.10.10 key secret timeout 6

Workaround

N/A