Security

Hi

The steps looks correct.

By default a service created with the wizard for Guest with MAC caching and the MAC Auth authentication method responds with a Reject in this first step:

The reject will trigger the user to fall into the pre-logon role in the controller.

But subsequent connections after the MAC cache has expired will follow the flow in your picture, as the MAC address is already known by ClearPass but not allowed to connect any more without the captive portal.

Very good point!  I have modified mine a little bit so that something always matches there and returns a role.  Either "grant access" or return a role that redirects to captive portal. In hindsight though, you are right.  The pre auth role was then responsible for redirecting to captive portal.   Thank you for the comments!  I'm going to do some testing on that scenario.

I have a use case where I have to do the opposite. Instead of returning a role for known clients after the MAC cache has expired I return Reject.

In this specific case we have the same SSID name on multiple site, with some sites with sponsor approval and some sites without sponsor approval. As the role name differs for these two cases and it would be complicated to build the logic to return two different role names in ClearPass we selected to do the configuration in Central instead.

So there may be several other ways to implement the guest authentication flow beside the standard flow that is configured with the guest authentication with MAC caching wizard.

Very good point!  I have modified mine a little bit so that something always matches there and returns a role.  Either "grant access" or return a role that redirects to captive portal. In hindsight though, you are right.  The pre auth role was then responsible for redirecting to captive portal.   Thank you for the comments!  I'm going to do some testing on that scenario.

Hi

The steps looks correct.

By default a service created with the wizard for Guest with MAC caching and the MAC Auth authentication method responds with a Reject in this first step:

The reject will trigger the user to fall into the pre-logon role in the controller.

But subsequent connections after the MAC cache has expired will follow the flow in your picture, as the MAC address is already known by ClearPass but not allowed to connect any more without the captive portal.

Note that implementing Enhanced Open (OWE) requires that the MAC auth always return an Accept, along with the proper user role for the session, so that the four way handshake can complete.  Return a reject and the client won't connect to the Enhanced Open network at all.

I have a use case where I have to do the opposite. Instead of returning a role for known clients after the MAC cache has expired I return Reject.

In this specific case we have the same SSID name on multiple site, with some sites with sponsor approval and some sites without sponsor approval. As the role name differs for these two cases and it would be complicated to build the logic to return two different role names in ClearPass we selected to do the configuration in Central instead.

So there may be several other ways to implement the guest authentication flow beside the standard flow that is configured with the guest authentication with MAC caching wizard.

Very good point!  I have modified mine a little bit so that something always matches there and returns a role.  Either "grant access" or return a role that redirects to captive portal. In hindsight though, you are right.  The pre auth role was then responsible for redirecting to captive portal.   Thank you for the comments!  I'm going to do some testing on that scenario.

Hi

The steps looks correct.

By default a service created with the wizard for Guest with MAC caching and the MAC Auth authentication method responds with a Reject in this first step:

The reject will trigger the user to fall into the pre-logon role in the controller.

But subsequent connections after the MAC cache has expired will follow the flow in your picture, as the MAC address is already known by ClearPass but not allowed to connect any more without the captive portal.

Note that implementing Enhanced Open (OWE) requires that the MAC auth always return an Accept, along with the proper user role for the session, so that the four way handshake can complete.  Return a reject and the client won't connect to the Enhanced Open network at all.

I have a use case where I have to do the opposite. Instead of returning a role for known clients after the MAC cache has expired I return Reject.

In this specific case we have the same SSID name on multiple site, with some sites with sponsor approval and some sites without sponsor approval. As the role name differs for these two cases and it would be complicated to build the logic to return two different role names in ClearPass we selected to do the configuration in Central instead.

So there may be several other ways to implement the guest authentication flow beside the standard flow that is configured with the guest authentication with MAC caching wizard.

Very good point!  I have modified mine a little bit so that something always matches there and returns a role.  Either "grant access" or return a role that redirects to captive portal. In hindsight though, you are right.  The pre auth role was then responsible for redirecting to captive portal.   Thank you for the comments!  I'm going to do some testing on that scenario.

Hi

The steps looks correct.

By default a service created with the wizard for Guest with MAC caching and the MAC Auth authentication method responds with a Reject in this first step:

The reject will trigger the user to fall into the pre-logon role in the controller.

But subsequent connections after the MAC cache has expired will follow the flow in your picture, as the MAC address is already known by ClearPass but not allowed to connect any more without the captive portal.