Security

I have a few dot1x clients stuck in initial roles (State SM_INITIAL) that wont authenticate.

They have initially authenticated but had a timeout on their last 802.1x login which generates a Deny Access Profile ( as per wired policy enforcement guide ).

However, once that profile is applied they get stuck in the initial role and no further authentication processing (either dot1x or mac-auth);

sw01# sh port-access clients 9 detailed

Port Access Client Status Detail

Client Base Details :
Port : 9 Authentication Type : 802.1x
Client Status : initial role Session Time : 480637 seconds
Client name : host/CLIENTX01 Session Timeout : 0 seconds
MAC Address : d067e5-1a3d82
IP : 10.11.10.44

Auth Order : Not Set
Auth Priority : Not Set
LMA Fallback : Disabled

Downloaded user roles are preceded by *

User Role Information

Name : denyall
Type : predefined
Reauthentication Period (seconds) : 0
Cached Reauth Period (seconds) : 0
Logoff Period (seconds) : 300
Untagged VLAN : 300
Tagged VLANs : 200
Captive Portal Profile :
Policy : denyall_104112101032097114117098097032098105108108

policy user "denyall_104112101032097114117098097032098105108108"
10 class ipv4 "classipv4_104112101032097114117098097032098105108108" action deny
20 class ipv6 "classipv6_104112101032097114117098097032098105108108" action deny
exit

class ipv4 "classipv4_104112101032097114117098097032098105108108"
10 match ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
exit

class ipv6 "classipv6_104112101032097114117098097032098105108108"
10 match ip ::/0 ::/0
exit

Tunnelednode Server Redirect : Disabled
Secondary Role Name :
Device Attributes : Disabled

Interface configuration is fairly standard as per wired policy enforcement guide;

interface 23
name "dot1x"
tagged vlan 200
untagged vlan 300
aaa port-access authenticator
aaa port-access authenticator tx-period 10
aaa port-access authenticator supplicant-timeout 10
aaa port-access authenticator client-limit 3
aaa port-access supplicant
aaa port-access mac-based
aaa port-access mac-based addr-limit 2

The only solution is to bounce the port which then triggers authentication again.

Can you try setting a re-auth req number as well? I'm surprised that after a single timeout, the device did not try again to authenticate. 

The other you could try is set the session timeout to 0, so when the port status changes (down/up) it will authenticate the device, but while it's still connected, it will just maintain it's status. 

We don't use Aruba switches, we have Cisco, but we use an auth-fail VLAN assignment of our quarantine VLAN, I've seen some devices have timeouts in the past, mostly when PC is locked or asleep, so we changed the session timeout to 0 and it now keeps them online unless their switch port bounces. Seemed to help in our scenario. 

Do you have reauth-period timer configured on the ports?

The line we use on our ports is "authentication timer reauthenticate server" and in the RADIUS response, we return a session timeout of 0 (meaning never). 

In our case, we saw no need to reauthenticate a machine that was already known to be valid.