Wireless Access

Reply
MVP Guru

Re: AOS8.4 client stuck in denyall role

Are you getting prompted to accept the RADIUS certificate ?

Sent from Mail for Windows 10
Thank you

Victor Fabian
Lead Mobility Architect @WEI
AMFX | ACMX | ACDX | ACCX | CWAP | CWDP | CWNA
MVP Guru

Re: AOS8.4 client stuck in denyall role

Double check your AAA Profile within 8.4. It is picking up the AAA Profile Defaults which is assigning denyall.

 

May 20 13:41:05 authmgr[3711]: <522049> <5129> <INFO> |authmgr| MAC=84:10:0d:f3:71:04,IP=N/A User role updated, existing Role=logon/none, new Role=denyall/none, reason=Set AAA profile defaults
--- TRUNCATED ---
May 20 13:41:05 authmgr[3711]: <522142> <5129> <DBUG> |authmgr| Setting default role to denyall for user 84:10:0d:f3:71:04".
May 20 13:41:05 authmgr[3711]: <522158> <5129> <DBUG> |authmgr| Role Derivation for user N/A-84:10:0d:f3:71:04- N/A Set AAA profile defaults.

Are you certain the configuration copied across successfully? Your 6.5 configuration does have denyall for the Initial Role and correct role for dot1x.

 

You do successfully authenticate :

 

May 20 13:41:05 dot1x-proc:1[4380]: <522038> <4380> <NOTI> |dot1x-proc:1| username=@x.x.uk MAC=84:10:0d:f3:71:04 IP=0.0.0.0 Result=Successful method=802.1x server=radius1-lapwing_radius
May 20 13:41:05 dot1x-proc:1[4380]: <526124> <4380> <DBUG> |dot1x-proc:1| dot1x_supplicant_up(): MAC:84:10:0d:f3:71:04, pmkid_present:False, pmkid:N/A

ACMP, ACSA, ACDX #985
If my post addresses your query, give kudos:)
Regular Contributor I

Re: AOS8.4 client stuck in denyall role

Thanks - useful to confirm that authentication is successful. There's no profile called defaults in the config at all (that I can find). Though actually if I look on the 6.5 system I see this:

 

May 20 16:04:31 authmgr[4122]: <522049> <5247> <INFO> |authmgr| MAC=84:10:0d:f3:71:04,IP=N/A User role updated, existing Role=logon/none, new Role=denyall/none, reason=Set AAA profile defaults
May 20 16:04:31 authmgr[4122]: <522246> <5247> <DBUG> |authmgr| Idle timeout should be driven by STM for MAC 84:10:0d:f3:71:04.
May 20 16:04:31 authmgr[4122]: <524141> <5247> <DBUG> |authmgr| clr_pmkcache_ft():1016: MAC:84:10:0d:f3:71:04 BSS:c8:b5:ad:5e:02:c1
May 20 16:04:31 authmgr[4122]: <522287> <5247> <DBUG> |authmgr| Auth GSM : MAC_USER publish for mac 84:10:0d:f3:71:04 bssid c8:b5:ad:5e:02:c1 vlan 1344 type 1 data-ready 0
May 20 16:04:31 authmgr[4122]: <522254> <5247> <DBUG> |authmgr| VDR - mac 84:10:0d:f3:71:04 rolename denyall fwdmode 0 derivation_type Initial Role Contained vp not present.
May 20 16:04:31 authmgr[4122]: <522258> <5247> <DBUG> |authmgr| "VDR - Add to history of user user 84:10:0d:f3:71:04 vlan 0 derivation_type Reset Role Based VLANs index 3.
May 20 16:04:31 authmgr[4122]: <522320> <5247> <DBUG> |authmgr| handle_sta_up_dn (3007): rtts user=84:10:0d:f3:71:04 enabled=0 initial tput=48960
May 20 16:04:31 authmgr[4122]: <524124> <5247> <DBUG> |authmgr| dot1x_supplicant_up(): MAC:84:10:0d:f3:71:04, pmkid_present:True, pmkid:bc 2d 99 86 44 6b 58 2b 80 af b2 f0 88 b9 c4 12
May 20 16:04:31 authmgr[4122]: <522142> <5247> <DBUG> |authmgr| Setting cached role to eduroam-open_role for user 84:10:0d:f3:71:04".
May 20 16:04:31 authmgr[4122]: <522254> <5247> <DBUG> |authmgr| VDR - mac 84:10:0d:f3:71:04 rolename NULL fwdmode 0 derivation_type VLAN from pmk-cache vp not present.
May 20 16:04:31 authmgr[4122]: <522044> <5247> <INFO> |authmgr| MAC=84:10:0d:f3:71:04 Station authenticate(start): method=802.1x, role=denyall/eduroam-open_role//denyall, VLAN=1344/1344, Derivation=1/0, Value Pair=0, flags=0x8
May 20 16:04:31 authmgr[4122]: <522158> <5247> <DBUG> |authmgr| Role Derivation for user N/A-84:10:0d:f3:71:04-xxxxx@x.x.uk N/A station Authenticated with auth type: Unknown auth type.
May 20 16:04:31 authmgr[4122]: <522127> <5247> <DBUG> |authmgr| {L2} Update role from denyall to eduroam-open_role for IP=N/A, MAC=84:10:0d:f3:71:04.
May 20 16:04:31 authmgr[4122]: <522049> <5247> <INFO> |authmgr| MAC=84:10:0d:f3:71:04,IP=N/A User role updated, existing Role=denyall/none, new Role=eduroam-open_role/none, reason=station Authenticated with auth type: 802.1x
May 20 16:04:31 authmgr[4122]: <522050> <5247> <INFO> |authmgr| MAC=84:10:0d:f3:71:04,IP=N/A User data downloaded to datapath, new Role=eduroam-open_role/98, bw Contract=0/0, reason=Download driven by user role setting, idle-timeout=300
May 20 16:04:31 authmgr[4122]: <522301> <5247> <DBUG> |authmgr| Auth GSM : USER publish for uuid 0x38b07f03e9a81ab3 mac 84:10:0d:f3:71:04 name xxxxx@x.x.uk role eduroam-open_role devtype wired 0 authtype 4 subtype 0 encrypt-type 10 conn-port 8448 fwd-mode 0
May 20 16:04:31 authmgr[4122]: <522259> <5247> <DBUG> |authmgr| "VDR - Do Role Based VLAN Derivation user 84:10:0d:f3:71:04 role eduroam-open_role rolehow ROLE_DERIVATION_DOT1X.
May 20 16:04:31 authmgr[4122]: <522254> <5247> <DBUG> |authmgr| VDR - mac 84:10:0d:f3:71:04 rolename eduroam-open_role fwdmode 0 derivation_type User Dot1x Role Contained vp not present.
May 20 16:04:31 authmgr[4122]: <522258> <5247> <DBUG> |authmgr| "VDR - Add to history of user user 84:10:0d:f3:71:04 vlan 0 derivation_type Reset Role Based VLANs index 4.
May 20 16:04:31 authmgr[4122]: <522255> <5247> <DBUG> |authmgr| "VDR - set vlan in user for 84:10:0d:f3:71:04 vlan 1344 fwdmode 0 derivation_type Current VLAN updated.
May 20 16:04:31 authmgr[4122]: <522258> <5247> <DBUG> |authmgr| "VDR - Add to history of user user 84:10:0d:f3:71:04 vlan 1344 derivation_type Current VLAN updated index 5.
May 20 16:04:31 authmgr[4122]: <522260> <5247> <DBUG> |authmgr| "VDR - Cur VLAN updated 84:10:0d:f3:71:04 mob 0 inform 1 remote 0 wired 0 defvlan 1344 exportedvlan 0 curvlan 1344.
May 20 16:04:31 authmgr[4122]: <522029> <5247> <INFO> |authmgr| MAC=84:10:0d:f3:71:04 Station authenticate: method=802.1x, role=eduroam-open_role/eduroam-open_role//denyall, VLAN=1344/1344, Derivation=7/1, Value Pair=0
May 20 16:04:31 authmgr[4122]: <522301> <5247> <DBUG> |authmgr| Auth GSM : USER publish for uuid 0x38b07f03e9a81ab3 mac 84:10:0d:f3:71:04 name xxxxx@x.x.uk role eduroam-open_role devtype wired 0 authtype 4 subtype 0 encrypt-type 10 conn-port 8448 fwd-mode 0
May 20 16:04:31 authmgr[4122]: <522308> <5247> <DBUG> |authmgr| Device Type index derivation for 84:10:0d:f3:71:04 : dhcp (0,0,0) oui (0,0) ua (46,1,1) derived Android(1)
May 20 16:04:31 authmgr[4122]: <522299> <5247> <DBUG> |authmgr| Auth GSM : DEV_ID_CACHE publish for mac 84:10:0d:f3:71:04 dev-id Android index 1
May 20 16:04:31 authmgr[4122]: <522242> <5247> <DBUG> |authmgr| MAC=84:10:0d:f3:71:04 Station Created Update MMS: BSSID=c8:b5:ad:5e:02:c1 ESSID=eduroam VLAN=1344 AP-name=c8:b5:ad:cd:e0:2c

 

This successful auth also has "reason=Set AAA profile defaults", so perhaps it's not as relevant as initially thought?  :(

 

This is my first attempt at setting up AOS8 & porting the config and there are a couple of things I'm not happy with, so I have decided to blank everything and start again - a useful learning experience! I'll do that and see if afterwards this all magically works(!). Thanks for looking at it.

 

On a possibly unrelated note - should there be an ARM profile configured on the 11a/g radio profiles? I'm not sure whether this is a result of the ported config but we currently *do* have an ARM profile set, but I think in the new AOS8 world this  should all be done by ClientMatch? Is that right?

 

 

MVP Guru

Re: AOS8.4 client stuck in denyall role

Not so much a profile called "default" but the default role for the AAA
Profile e.g denyall. Can you run "#show configuration effective" from the
Group level (e.g cd /md/YOUR_GROUP) then provide the full output of the AAA
Profile in question.

ARM is legacy now and should be used by AirMatch if using a MM.

ACMP, ACSA, ACDX #985
If my post addresses your query, give kudos:)
Regular Contributor I

Re: AOS8.4 client stuck in denyall role

Here is the AAA profile as seen from the MM:

 

aaa profile "eduroam_aaa"
initial-role "denyall"
authentication-dot1x "default"
dot1x-default-role "eduroam-open_role"
dot1x-server-group "lapwing_srvgrp"
radius-accounting "lapwing_srvgrp"
radius-interim-accounting

 

And logged into the MD, this is show aaa profile "eduroam_aaa":

 

AAA Profile "eduroam_aaa"
-------------------------
Parameter Value
--------- -----
Initial role denyall
MAC Authentication Profile N/A
MAC Authentication Default Role guest
MAC Authentication Server Group default
802.1X Authentication Profile default
802.1X Authentication Default Role eduroam-open_role
802.1X Authentication Server Group lapwing_srvgrp
Download Role from CPPM Disabled
Set username from dhcp option 12 Disabled
L2 Authentication Fail Through Disabled
Multiple Server Accounting Disabled
User idle timeout N/A
Max IPv4 for wireless user 2
RADIUS Accounting Server Group lapwing_srvgrp
RADIUS Roaming Accounting Disabled
RADIUS Interim Accounting Enabled
RADIUS Acct-Session-Id In Access-Request Disabled
XML API server N/A
RFC 3576 server N/A
User derivation rules N/A
Wired to Wireless Roaming Enabled
Reauthenticate wired user on VLAN change Disabled
Device Type Classification Enabled
Enforce DHCP Disabled
PAN Firewall Integration Disabled
Open SSID radius accounting Disabled
Apply ageout mechanism on bridge mode wireless clients Disabled

 

We're still having issues with this. The RADIUS server shows the authentication completing, but the role never changes. On our 6.5 system we see this:

 

May 28 11:40:00 authmgr[4122]: <524158> <4122> <DBUG> |authmgr| rx_dot1x_radius (1709): rtts user=84:10:0d:f3:71:04 RADIUS ACCEPT result=-1 discard=0 reest=0 keepalive=0 bkoff=0 earlylift=0

 

But we never see that on the 8.4 system

 

We briefly tested this using our CPPM server (currently just a test server) configured as the RADIUS server and it worked fine. Is there anything that AOS8 might expect to be different by way of how our RADIUS server should respond to it? It seems like there is something that we need to do differently at the RADIUS end of things perhaps?

Re: AOS8.4 client stuck in denyall role

How have things been going with your issue? Any fresh logs from the commands you ran previously. I was trying to make sense of each piece but saw a switch from the "testing" ssid - so just getting a fresh perspective as of today.

Regular Contributor I

Re: AOS8.4 client stuck in denyall role

Hi,

 

The logs I posted a few messages ago were from our 6.5 system which is all working fine (hence 'eduroam' not 'eduroam-testing'), I was just using them as a comparison.

 

We don't have this particular dot1x SSID working on the AOS 8 system yet. As we are at a bit of an impasse we have moved onto other things (getting used to clustering, testing AP failover, etc), so there is nothing new on this problem at the moment. We have an Aruba engineer coming to have a general look at how things are going (hopefully on Monday) so we will go through this with him.

Frequent Contributor II

Re: AOS8.4 client stuck in denyall role

I don't think I can help you directly with your problem, but I can provide you with some resources that may help you understand and troubleshoot it. A couple of years ago I created a role derivation flowchart for an ArubaOS 6 book that I wrote. From the book I have made 15 images, including the flowchart available for anyone to download because i thought they should be shared. If you go to www.westcott-consulting.com and click on download you can get them. You will be signing up for my mailing list (which I rarely use) but you can remove yourself from the list. After you fill out the form, you will receive an email (it may go to junk) that will download the files.

 

When I created this flowchart, I used the following command to track and validate what I was doing. The output shows as the role is assigned and reassigned during the login/connection process. The following is a sample output.

 

I hope this helps,

 

#show log all | include "new Role="
1. Sep  7 15:53:39  authmgr[3705]: <522049> <3705> <INFO> |authmgr|  MAC=00:24:d7:81:48:c8,IP=N/A User role updated, existing Role=Derived-Role-User-Rule-MAC-Begins-With/none, new Role=Derived-MACuser-Internaldb/none, reason=station Authenticated with auth type:  MAC based authentication
2. Sep  7 15:53:39  authmgr[3705]: <522049> <4253> <INFO> |authmgr|  MAC=00:00:00:00:00:00,IP=N/A User role updated, existing Role=none/none, new Role=logon/none, reason=mac user created
3. Sep  7 15:53:39  authmgr[3705]: <522049> <4253> <INFO> |authmgr|  MAC=00:24:d7:81:48:c8,IP=N/A User role updated, existing Role=Derived-Role-WPA2PSK-Initial/none, new Role=Derived-Role-User-Rule-MAC-Begins-With/none, reason= handle_sta_up_dn: setting l2 role for user attributes
4. Sep  7 15:53:39  authmgr[3705]: <522049> <4253> <INFO> |authmgr|  MAC=00:24:d7:81:48:c8,IP=N/A User role updated, existing Role=logon/none, new Role=Derived-Role-WPA2PSK-Initial/none, reason=Set AAA profile defaults
5. Sep  7 15:53:39  authmgr[3705]: <522050> <3705> <INFO> |authmgr|  MAC=00:24:d7:81:48:c8,IP=10.1.90.154 User data downloaded to datapath, new Role=Derived-MACuser-Internaldb/72, bw Contract=0/0, reason=New user IP processing, idle-timeout=300
6. Sep  7 15:53:39  authmgr[3705]: <522050> <3705> <INFO> |authmgr|  MAC=00:24:d7:81:48:c8,IP=N/A User data downloaded to datapath, new Role=Derived-MACuser-Internaldb/72, bw Contract=0/0, reason=Download driven by user role setting, idle-timeout=300
7. Sep  7 15:53:39  authmgr[3705]: <522050> <4253> <INFO> |authmgr|  MAC=00:24:d7:81:48:c8,IP=N/A User data downloaded to datapath, new Role=Derived-Role-User-Rule-MAC-Begins-With/91, bw Contract=0/0, reason=layer 2 event driven download, idle-timeout=300
 

 

David
Sr. Trainer and Author of upcoming "Understanding ArubaOS: Version 8.x" book
Regular Contributor I

Re: AOS8.4 client stuck in denyall role

Thanks for this David - I will definitely do that.

Highlighted
Regular Contributor I

Re: AOS8.4 client stuck in denyall role

Just to follow up on this - with the help of an Aruba techie we found that that when we transferred our config from our FreeRADIUS2 server onto our new FreeRADIUS3 server (some time ago), we accidentally also ported a fix for a bug which was fixed in FreeRADIUS3. This resulted in the username being added twice to the ACCEPT packet. I guess ArubaOS 6.x doesn't object to this, but 8.x clearly does. Once we removed the 'fix' all was happy.

 

The clue was in the logs where we could see the RADIUS packet being dropped. To see this we had turned on:

 

- logging security process dot1x-proc level debug

 

(I think we also had a couple of other 'logging security...' settings, I'm afraid I don't have a record of those)

 

Thanks to those on Airheads who helped

 

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: