Another ClearPass post for you lovely, lovely readers.
Setting the scene
Imagine if you will that a customer has an “open” guest SSID and wanted to authenticate all guest accounts via a ClearPass captive portal using the same static guest user. They also didn’t want the guest to have to log back in for 12 hours following the initial captive portal authentication.
Sounds pretty simple right? Well, it is very simple but there’s a gotcha in there that you should be aware of. You’ll have to read my ramblings or skip to near the end to find out.
To achieve what the customer wanted I did the following:
- Created a guest user with no expiry
- Created a guest user auth with MAC caching service with corresponding enforcement
- Created a guest user MAC auth service with corresponding enforcement
- Created a guest login page
- Configured the SSID, AAA & roles on the controller
I used the wizard to create the services (I’ll probably get some stick for that). So, you can use the ClearPass service wizard to create service to auth guest and cache their MAC address.
When you do this it’ll create quite a few enforcement policies that you probably don’t need so remember to delete them or remove them from your enforcement profiles.
The wizard create a enforcement profile which sets the MAC auth expiry time to 1 day. That means after a guest logs into the captive portal, they can disconnect and reconnect to the guest SSID and gain network access without logging back into the captive portal for 24 hours.
ClearPass does this by keeping a record of the device that the guest user logged in from in the endpoint repository. Along with the endpoint device, ClearPass writes an attribute call “MAC-Auth Expiry” and populates it with a value which is 24 hours from date the guest user authenticated. Note the format of the date and time in the image of the endpoint attributes below.
OK, so all we need to do now is change the expiry to 12 hours.
Custom Time Config
ClearPass has a time source SQL database. By default the following time attributes are available.
- current time
- 2 hours time
- 1 days time
- 1 weeks time
- 1 months time
- 6 months time
I just used the “2 hours time” attribute as a template and created a “12 hours time” attribute as in the image below.
Next I updated my enforcement profile which sets the MAC-Auth Expiry to reference this new time attribute.
Awesome! Whoa there cowboy. Don’t celebrate prematurely. After making this change guests could MAC auth after authenticating via the captive portal days after the initial auth. Clearly the MAC Auth Expiry wasn’t working.
There were no errors anywhere. The times on all network devices were synced from the same NTP servers and were definitely not out of sync.
I double checked my custom time attribute and noticed there there were duplicates of the same time values but with different names. Probably should have noticed that when I was adding my custom attribute.
A little more digging around and I discovered one time format was in EPOCH and the other in Date/Time. Now we’re getting somewhere. The 12 Hours custom time attribute I created was a integer EPOCH time format.
My Guest MAC Auth service was checking the current time (Now DT) in date/time format to see if it was less than the endpoint device MAC-Auth Expiry which I’d specified in EPOCH format… and current time was always coming out less.
I check the time source and noticed 2 current time attributes:
- Now DT
Now is in EPOCH format and Now DT in date/time format.
I changed my Guest MAC Auth service role mapping policy from referencing Now DT to Now.
Now we’ve got both the time source and the MAC-Auth Expiry in EPOCH format and testing showed that the solution now worked.
Happy to hear if there are other ways to implement this.
FYI I know that using a static guest account isn’t ideal but this was a customer requirement.