Security

Having some trouble coming up with a solution to our Guest network. We have devices that utilize guest, but cannot use a captive portal, so we whitelist devices today using the Local User Repository and it works fine. We want to move the MAC addresses to the Guest Device Repository instead, so we can set account expirations and have more management control over disabling devices if necessary.

 

I'm trying to test adding, expiring, and disabling before expiration of a device and running into a few issues.

 

1. When the device is first added and does not exist in Endpoints, remaining expiration works fine, but account status is showing as 0. In Guest Device Repository, it shows Account Status as 1.

 

When the device goes into Disabled because of the expiration date, it remains as 0.

 

2. When I manually go in and disable a device, which may happen in production for us, it does not update the "remaining time" in access tracker, and because the account status isn't changing, it's still getting access.

 

I've tried using Account Status and Remaining Expiration to determine if a device is active or disabled, but both have given me trouble. 

 

Is there something I'm missing here or any suggestions?

We'll be adding these two attributes by default in a future release, but you can add them now to meet your use case:

 

Device Account Active essentially combines the other two (not expired and is enabled) into one attirbute and also evaluates the start time of the account (ex: this account isn't active until next week).

 

SELECT 
       CASE WHEN expire_time is null or expire_time > now() THEN 'false' 
       ELSE 'true'
       END AS is_expired,
       CASE WHEN enabled = true THEN 'true' ELSE 'false' END as is_enabled,
       CASE WHEN (expire_time is null or expire_time > now()) and (start_time < now()) and (enabled = true) THEN 'true' ELSE 'false' END as is_active
FROM tips_guest_users           
WHERE ((guest_type = 'DEVICE') AND (user_id = '%{Connection:Client-Mac-Address-Upper-Hyphen}') AND (app_name = 'Guest'))

 

Where did you add that filter at? I'm looking to utilize this check in my role mapping policy, not sure where you put that.

The Guest Device Repository auth source.

I added that in there, removed and re-added the test device and I'm not seeing any of that information in access tracker. Do I need to update the mac_create form with any of those fields or should it be showing up already? 

You need to reference them in policy or they won’t appear (unless you change them to attributes).

Also, things like account status should be used directly in enforcement policies and not role mapping. You don’t want that type of data cached.

Ok, so I have them showing up now and the policy works on the initial connection, but if I go in and manually disable a device, it doesn't seem like it's updating in access tracker when I bounce the device afterward. Same thing when I re-enable it, not updating. Is there a delay between Guest and CPPM pulling data?

There is a default cache of 5 minutes on the auth source, so when testing in a short window, you will see this behavior. You can clear the auth source cache at the bottom of the source.

Thanks for all the help Tim! Oddly enough, it worked immediately, but I don't fully understand why. So my Role Mapping policy has the standard for Guest looking at Endpoint: Guest Role ID = 2. When I disable the account in Manage Devices and bounce the client, it rejects the auth and does not show [Guest] as one of the roles, however, that attribute is in the access tracker log of = 2. When I re-enable the account, it allows access immediately, showing [Guest] as a role again, without changing anything else. Access Tracker logs look the same in both. The Expired, Active, Etc. that I just added didn't change in that short window from the 5 minute delay, so it is immediately working, just not what I expected.

Make sure you’re using [Allow All MAC Auth], not [MAC Auth] as the auth method. Never use [MAC Auth].

It is set to [Allow All MAC Auth].

 

Thanks for the help again!

Nevermind, found it right after asking the question. Thanks! I'm going to test it now, and fingers are crossed!