Wireless Access

last person joined: 20 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

IAS NPS - restrict user account to one SSID

This thread has been viewed 0 times
  • 1.  IAS NPS - restrict user account to one SSID

    Posted Feb 10, 2017 07:18 PM

    We are using 2 SSIDs - one corporate using PEAP and another that is open using captive portal.

     

    The captive portal is for our users that don't want to be restricted by our network requirements, but we authenticate using our AD credentials (Windows IAS).   We also have a guest account that is local on each controller.

     

    A while back we noticed that if a user typed in the wrong credentials for that local account, it would then fail over to the RADIUS server (as is correct per our intended configuration).  The problem is that once they do that, any subsequent attempts do not query the local DB and instead continue to hit our authentication server.

     

    When that happens, the only way to fix that is to manually delete the user from the controller via CLI.   Given the size of our network that isn't an easy thing to do.

     

    A quick fix was to create a domain account with the same name and password - restricted so as to not allow it to logon to any PCs.   A poorly thought out idea, we didn't realize that would also allow users to connect to our PEAP network using that same account until we noticed quite a few mobile devices using that account.

     

    Is there a simple way to enable this account to exist and only authenticate to our captive portal SSID and not the corporate network SSID?

     

    The guest account in AD is in the domain guests group, whereas the other accounts are members of domain users.   I can also create a special AD group for this one account if needed.

     

    A quick brainstorm seems that the easy solution is create an IAS policy that denies access to users of the domain guests group - but that also denies access at the captive portal.

     

    I have a feeling we need to do something along the lines of creating a filter ID on the IAS server, then also put something into the SSID profile on the controller that will deny anything that is returned with that filter - like filter ID returns "guest" and somewhere in the PEAP SSID policy/profile we create a deny condition for guest, while our CP SSID allows guest to connect.

     

    We do something similar with our captive portal - network users get full bandwidth, while anybody not in that group gets guest access which is rate-limited.

     

    I guess my problem is that we set this up over 7 years ago, and I'm not exactly sure where I need to be to set that up, or how exactly to go about it.  I vaguely remember setting up the filters and stuff in IAS, but our SE did most of the profile config and I don't remember if he created a certain role, where that was, or how he did it.

     

    If anybody can point me in the proper direction, any help is greatly appreciated.   As of now I've had to disable that guest network account because it is too great of a security risk.



  • 2.  RE: IAS NPS - restrict user account to one SSID

    Posted Feb 16, 2017 04:33 AM

    If so, have your RADIUS server pass back an attribute that includes "guest" (based on group membership).  Then, setup your Server Derivation Rule (SDR) like this:

     

    Attribute: Class (or whatever other RADIUS attribute you are passing back, but Class is a good one)

    Operation: value-of

    Type: string

    Action: set role

     

    What that means is that upon successful authenticaiton, the controller will take what ever the RADIUS server sends back in the Class attribute (or which ever attribute you selected) and use it as the role for that user (assuming that role exists).

     

    If you have the Aruba dictionary loaded on your RADIUS server, you can pass back Aruba-User-Role and the controller will automatically use that value as the user role without having to create an SDR.