Security

Hey,

Details:
SSID is using 802.1x auth.
Currently testing with laptops joined to an AD domain that are authenticating using PEAP and MSCHAPv2.

After learning about how the "Profiler" feature works that is available under Services I implemented it into a test Service.

I do a Role Mapping to identify which Endpoints have not been profiled:
(Authorization:[Endpoints Repository]:IsProfiled NOT_EXISTS )

I then have a rule in my Enforcement Policy that looks for this role and if it is found the machine is placed into a restricted role that gives access to get an IP address.

The Profiler feature then kicks in and sends the CoA back to the controller and forces the disconnect.

The machine then tries to reconnect and is processed by the same Enforcement Policy but a different Enforcement Profile is applied. One of the profiles that gets applied is one that writes an attribute back into the Endpoints database for the particular Endpoint indicating that it is a "corporate" device. It basically means that it has succesfully completed a machine auth at some point.

Where I get into trouble is when a user is signed in.

If I sign in on a laptop, then go into the Endpoints database and delete the profiled Endpoint, then manually disconnect and reconnect myself to the WiFi the same process that happens with the machine account happens except that the attribute indicating that this is a coporate device never gets written into the Endpoints database. This only happens during machine auth. So the user is never able to authenticate as I map a role based on that attribute and it is required for when user authentication is happening.

I was thinking that to deal with this scenario I could place the user into a restricted role with a captive portal associate with it. I could then tell the user they need to sign off. This would allow the machine authentication to happen and the whole process to work.

Is there another way of handling this? Perhaps I have over thought the situation.

I initially started out trying to get devices that have never connected to our wireless network profiled properly before being allowed to get full access the network. It has gotten a little more complicated as I think about the different scenarios.

Thank you,

Cheers

Bourne,

Why don't you just use the method in the thread here?  http://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/Enforce-Machine-Authentication/td-p/58918/highlight/true/page/2

A device passing machine authentication is cached for 24 hours by default.  You can then extend that cache to 1000 hours if you want.  That way you can just check the attribute and cache it for as long as you want.  

Hey cjoseph,

That is interesting I could definitely do that.

Are there any potential draw backs to setting the value for this long?

I think I will still face an issue with laptop users who don't sign out of their computers. We have users who visit us from our other global locations who have never been on our wireless. I have seen a lot of them that simply close the lid, as opposed to signing out. So machine authentication never gets an opportunity to occur.

Caching the machine authentication for a greater period of time is definitey something that will come in handy once machine authentication has occrued. I still need someway to get a user to sign out and sign in to make sure machine authentication actually happens.

Thank you,

Cheers

Caching is the solution.  Everytime a user reboots, the cache is refreshed or reset.  Everytime a user authenticates successfuly, the machine cache is also refreshed or reset.  I would increase the cache first, because that would allow CPPM to collect the machine cache state.  Every time a user authentication occurs on that mac, the machine cache is reset.

I see what you are saying about increasing the machine cache timeout.

That means that once a machine has successfully authenticated, then it basically becomes like a perpetual thing where the machine authenticated role will pretty much always be there. Depending upon how long the cache is set for.

I guess I am still a little fuzzy on how the increased cache timeout would solve the situation where the machine hasn't authenticated before. There would be no cached machine authentication. And Windows won't send machine authentication if the user is signed in.

This may just be a situation where we need to tell the users they need to sign out. Then after that the cache would take over and we would be good! 

Cheers

Exactly.  You have to start somewhere..

Fair enough!

And your absolutely right.

We can't do all the hand holding.

I appreciate your help and patience.

Thank you!

Cheers