Wireless Access

last person joined: 23 hours ago 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Expand all | Collapse all

Sticky SDR role after client logoff

This thread has been viewed 5 times
  • 1.  Sticky SDR role after client logoff

    Posted Jan 19, 2017 12:15 PM

    Hi,

    I have a setup were Windows domain clients are authenticated via RADIUS (NPS) with their domain credentials. NPS returns Aruba-User-Role after successful Machine & User authentication.

     

    When computer boots up and stays at logon screen, station gets machine authentication default machine role. After user logs in, role is mapped to derived one from returned VSA attribute.

     

    But when user logout/logoff from computer, there is still derived role assigned, while it should be only machine default role...

     

    Please, advice which parameter in controller (6.5.0.3) config is responsible for this sticky SDR behavior? I have experimented with a few settings in AAA and 802.1X profile, but non changed this.



  • 2.  RE: Sticky SDR role after client logoff

    Posted Jan 19, 2017 05:15 PM

    Below is show log user-debug output:

    x-init = AAA initial role

    x-comp = Machine Auth Default machine role

    x-sdr = SDR role (from VSA Aruba-User-Role)

    |authmgr|  dot1x_gsm_delete_pmkcache(): MAC:ac:f1:df:0c:c8:ce BSS:9c:1c:12:65:8f:e0 GSM: Successfully deleted PMK-cache object.
    |authmgr|  username=host/VLAP1.intext.local MAC=ac:f1:df:0c:c8:ce IP=0.0.0.0 Authentication result=Authentication Successful method=802.1x server=DC1
    |authmgr|  Setting cached role to NULL for user ac:f1:df:0c:c8:ce".
    |authmgr|  MAC=ac:f1:df:0c:c8:ce Station authenticate(start): method=8021x-Machine, role=x-sdr///x-init, VLAN=10/10, Derivation=9/1, Value Pair=1, flags=0x1
    |authmgr|  Role Derivation for user N/A-ac:f1:df:0c:c8:ce-host/VLAP1.intext.local N/A station Authenticated with auth type:  Unknown auth type.
    |authmgr|  Setting cached role to NULL for user ac:f1:df:0c:c8:ce".
    |authmgr|  Calling derive_role2 for user ac:f1:df:0c:c8:ce
    |authmgr|  {L2} x-comp from profile "corp-AAA" for user ac:f1:df:0c:c8:ce.
    |authmgr|  Error setting l2 role for user N/A ac:f1:df:0c:c8:ce host/VLAP1.intext.local x-sdr ROLE_DERIVATION_DOT1X_VSA (9) x-comp ROLE_DERIVATION_DOT1X(7).
    |authmgr|  "VDR - Add to history of user user ac:f1:df:0c:c8:ce vlan 0 derivation_type Reset Dot1x VLANs index 4.
    |authmgr|  Valid Dot1xct, remote:0, assigned:10, default:10, current:10,termstate:0, wired:0, dot1x enabled:1, psk:0 static:0 bssid=9c:1c:12:65:8f:e0.
    |authmgr|  "VDR - Add to history of user user ac:f1:df:0c:c8:ce vlan 0 derivation_type Reset Dot1x VLANs index 5.
    |authmgr|  "VDR - set vlan in user for ac:f1:df:0c:c8:ce vlan 10 fwdmode 0 derivation_type Current VLAN updated.
    |authmgr|  "VDR - Add to history of user user ac:f1:df:0c:c8:ce vlan 10 derivation_type Current VLAN updated index 6.
    |authmgr|  "VDR - Cur VLAN updated ac:f1:df:0c:c8:ce mob 0 inform 1 remote 0 wired 0 defvlan 10 exportedvlan 0 curvlan 10.
    |authmgr|  MAC=ac:f1:df:0c:c8:ce Station authenticate: method=8021x-Machine, role=x-sdr///x-init, VLAN=10/10, Derivation=9/1, Value Pair=1
    |authmgr|  Role Derivation for user 10.10.10.9-ac:f1:df:0c:c8:ce-host/VLAP1.intext.local N/A User authenticated with auth type:Unknown auth type role derivation:0.
    |authmgr|  Client ac:f1:df:0c:c8:ce idle timeout 300 profile global
    |authmgr|  User Authentication Successful: username=host/VLAP1.intext.local MAC=ac:f1:df:0c:c8:ce IP=10.10.10.9 role=x-sdr VLAN=10 AP=9c:1c:12:ce:58:fe SSID=corp AAA profile=corp-AAA auth method=8021x-Machine auth server=DC1
    |authmgr|  Auth GSM : USER publish for uuid 0x2046bbb8adc0001a mac ac:f1:df:0c:c8:ce name host/VLAP1.intext.local role x-sdr devtype  wired 0 authtype 10 subtype 9  encrypt-type 10 conn-port 8448 fwd-mode 0
    |authmgr|  Setting cached role to x-sdr for user ac:f1:df:0c:c8:ce".
    |authmgr|  PMK Cache getting updated for ac:f1:df:0c:c8:ce, (def, cur, vhow) = (10, 10, 1) with vlan=0 vlanhow=0 essid=corp role=x-sdr rhow=9
    |authmgr|  dot1x_gsm_set_keycache(): MAC:ac:f1:df:0c:c8:ce GSM: Successfully published Key-cache object.
    |authmgr|  dot1x_gsm_set_pmkcache(): MAC:ac:f1:df:0c:c8:ce BSS:9c:1c:12:65:8f:e0 GSM: Successfully published PMK-cache object.
    |authmgr|  add_pmkcache():876: MAC:ac:f1:df:0c:c8:ce BSS:9c:1c:12:65:8f:e0 Update:
    |authmgr|  dot1x_gsm_set_keycache(): MAC:ac:f1:df:0c:c8:ce GSM: Successfully published Key-cache object.
    |authmgr|  Reauthentication timer exists for user ac:f1:df:0c:c8:ce for 86400 seconds type Full Auth).
    |authmgr|  Reauthentication timer restarted for user ac:f1:df:0c:c8:ce (86400 seconds, type Dot1x-Non-Term).

     



  • 3.  RE: Sticky SDR role after client logoff
    Best Answer

    Posted Jan 20, 2017 05:20 AM

    Solved: problem is caused by the STA that will not send EAPOL-logoff message when user logs off/signs out and controller is not aware that is should change applied role to the client.

     

    See below output from 'show dot1x supplicant-info'

     

    Step 1: PC (win8.1) boots up, awaits user logon.

     EAPOL Starts                        1
     EAP ID Requests                     2
     EAP ID Responses                    1
     EAPOL Logoffs from station          0
     Ignored EAPOL Starts                1
     EAP pkts to the station             14
     EAP pkts from station               13
     Unknown EAP pkts from station       0
     EAP Successes sent                  1
     EAP Failures sent                   0

    Step 2: User loged on to the system.

     EAPOL Starts                        2
     EAP ID Requests                     3
     EAP ID Responses                    2
     EAPOL Logoffs from station          0
     Ignored EAPOL Starts                2
     EAP pkts to the station             29
     EAP pkts from station               26
     Unknown EAP pkts from station       0
     EAP Successes sent                  2
     EAP Failures sent                   0

    Step 3: User logs off/signs out from system. PC stays on network.

     EAPOL Starts                        3
     EAP ID Requests                     4
     EAP ID Responses                    3
     EAPOL Logoffs from station          0 <-- should increase!
     Ignored EAPOL Starts                3
     EAP pkts to the station             41
     EAP pkts from station               38
     Unknown EAP pkts from station       0
     EAP Successes sent                  3
     EAP Failures sent                   0

     



  • 4.  RE: Sticky SDR role after client logoff

    Posted Jan 25, 2017 03:24 AM

    Well, sorry to dig out old topic which I marked as solved, but I was wrong.

    EAPOL-logoff is not send by Windows by design. It does not change the fact that re-authentication should change applied role from SDR to Machine default role.

     

    Attached are two files containing output from ‘sh auth-tracebuf, sh log security authmgr/aaa, sh log user-debug, sh dot1x supplicant-into, sh user’

    x-init = initial role AAA

    x-comp = Machine Auth Default Machine role

    x-user = Machine Auth Default User role

    x-auth = Default 802.1X role

    x-sdr = SDR from VSA Aruba-User-Role returned by NPS

     

    Step1: PC boots up, no user logon: role=x-init -> x-comp

    Step2: User logs into the system: role=x-comp && x-user -> SDR -> x-sdr

    Step3: User logs out from the system: No new role, stays at SDR role ‘x-sdr’

     

    Problem: At step 3, there is no role change back to default machine role. You can see that after user logs out, there is new EAP-Start message, station is identified by computer (not user) name, authentication method is 8021x-Machine but the role is still SDR. There is no EAP-logoff send by the station when user logs off from system, but it is intended Microsoft behavior by design (security vulnerability). But still, new EAP-Start message that begins new authentication process, should reset derived role and do clean machine auth with computer only completed authentication.

     

    Why it sticks with SDR role?

     

     

    Attachment(s)



  • 5.  RE: Sticky SDR role after client logoff

    EMPLOYEE
    Posted Jan 25, 2017 07:04 AM

    In your 802.1x profile, you have "Enforce Machine Authentication" enabled.  Uncheck that and things should behave normally.  http://community.arubanetworks.com/t5/forums/searchpage/tab/message?include_tkbs=true&location=category%3ASupport-Documentation-Downloads&q=enforce+machine+authentication

    EDIT:  To be clear, the SDR is only run when a user logs into a machine where machine authentication has already taken place.  When machine authentication takes place, the device should get the machine authentication role in the 802.1x profile.  Long story short, unchecking Enforce Machine Authentication in the 802.1x profile should make things appear normal.

     

    Jan 20 10:57:48 :522029:  <3698> <INFO> |authmgr|  MAC=ac:f1:df:0c:c8:ce Station authenticate: method=8021x-Machine, role=x-comp///x-init, VLAN=10/10, Derivation=7/1, Value Pair=1

     



  • 6.  RE: Sticky SDR role after client logoff

    Posted Jan 25, 2017 05:49 PM

    No. Enforcing Machine Authentication is desired to differentiate users connecting from domain computer from users connecting (with domain username & pass) from smartphones for example.

     

    Under URL you referenced, there is:

    6) After the user has logged in, Windows never attempts another machine authentication. When the user logs out, Windows can attempt it.

    What does it mean "can attempt" machine auth on user log out? When? Under what conditions?

     



  • 7.  RE: Sticky SDR role after client logoff

    EMPLOYEE
    Posted Jan 25, 2017 06:38 PM

    We might be talking about two slightly different things:

     

    If you have "enforce machine authentication" enabled, the SDR is only run on a device that has a user authenticating on a device that has already machine authenticated.  A machine authenticating by itself does not run any SDRs.

     

    If a machine authenticates, it only gets the enforce machine authentication machine role.

     

    In very secure facilities, devices only machine authenticate over wireless.  Users are still required to authenticate to Windows gain access to the machine and the domain.  This behavior matches the security posture of wired machines, really.