Forgive the longevity of this post.
We have an ACAS scanner that using a hard coded PIN to scan our network elements. The PIN is then passed to an RSA server via RADIUS. All of the scans to ASR1001-Xs work, but the scans to switches sometimes succeeds, but mostly fails. The routers have the following config that allows the scanner to log in and the RSA server assigns priv level 15. The scanner is also coded with the enable password.
aaa group server radius XXXXXXX
server-private x.x.x.x key 7 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
ip vrf forwarding xxxxxx
ip radius source-interface xxxxxxx
aaa authentication login default group xxxxx local
aaa authorization exec default group xxxxx if-authenticated
This has been a stable working configuration to get the scans working.
On the switches we have either the same configuration as the routers or we have the following:
rsa server XXX
address ipv4 x.x.x.x auth-port 1645 acct-port 1646
key xxxxxxxx
ip radius source-interface vlanxxx
aaa authentication login default group radius local
aaa authorization exec default group xxxxx if-authenticated
With this configuration we have intermittent problems getting a scan to work.
We also have:
login block-for 100 attempts 5 within 100
But we have built an access list including the scanner IP being permitted and applied it to:
login quiet-mode access-class XXXXXXXXX
So the scanner is never blocked.
We also set up the RSA server so the scanner account is never locked.
But here is the problem and the crux of my question:
I cannot provide output as the devices are on a closed network, but on a debug of the radius process we see that the scanner tries bogus accounts, which are denied correctly, but sometimes the scanner credentials are permitted, sometimes denied, sometimes (most times) both denied and accepted within the same scan.
There is a big difference in that the access-denied responses from the RADIUS server have the following lines in the debug code that the access-accepts to not:
The first line and third line below expose on all debugs, the middle one only on access-denies:
RADIUS/ENCODE(00000030D):Orig. component type = Exec
RADIUS/ENCODE: Skip encoding 0 length AAA Cisco vsa password
RADIUS/ENCODE(00000030D): dropping service type, "radius-server attribute 6 on-for-login-auth" is off
When this middle line is present we receive an invalid credentials response from the RADIUS server.
The very next line after the reject is:
%SSH-3-PACK_INTEG_ERROR: Packet integrity erro (8 bytes remaining) from x.x.x.x (where x.x.x.x is the scanner IP)
That line always follows a failed access attempt.
With all this said we can open a terminal window and SSH to any of the switches just fine from any allowed location. This failure only occurs when we run the scan.
So the question is what would cause the "Skip encoding 0 length AAA Cisco vsa password" line to be created and who is creating it, the switch or the scanner? If it is the switch is that in response to an anomaly in the request from the scanner?
The switches are also on different software releases. Some are on 16.3.7 and some are on 16.9.4 and others are on 16.6.5.
