Security

I would like to solicit any constructive feedback you might have about this document.  We have a captive portal that does NOT require anything more than accepting the AUP and clicking login.  After that it will do mac caching for 24 hours before forcing the captive portal again.  This is what I have deduced is happening.  Since documentation about "How it works" seems hard to find.  I'm trying to create my own. 

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.

I would like to solicit any constructive feedback you might have about this document.  We have a captive portal that does NOT require anything more than accepting the AUP and clicking login.  After that it will do mac caching for 24 hours before forcing the captive portal again.  This is what I have deduced is happening.  Since documentation about "How it works" seems hard to find.  I'm trying to create my own. 

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.

I would like to solicit any constructive feedback you might have about this document.  We have a captive portal that does NOT require anything more than accepting the AUP and clicking login.  After that it will do mac caching for 24 hours before forcing the captive portal again.  This is what I have deduced is happening.  Since documentation about "How it works" seems hard to find.  I'm trying to create my own. 

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.

I would like to solicit any constructive feedback you might have about this document.  We have a captive portal that does NOT require anything more than accepting the AUP and clicking login.  After that it will do mac caching for 24 hours before forcing the captive portal again.  This is what I have deduced is happening.  Since documentation about "How it works" seems hard to find.  I'm trying to create my own. 

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.

I would like to solicit any constructive feedback you might have about this document.  We have a captive portal that does NOT require anything more than accepting the AUP and clicking login.  After that it will do mac caching for 24 hours before forcing the captive portal again.  This is what I have deduced is happening.  Since documentation about "How it works" seems hard to find.  I'm trying to create my own. 

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.

I would like to solicit any constructive feedback you might have about this document.  We have a captive portal that does NOT require anything more than accepting the AUP and clicking login.  After that it will do mac caching for 24 hours before forcing the captive portal again.  This is what I have deduced is happening.  Since documentation about "How it works" seems hard to find.  I'm trying to create my own.