Security

Hello,

My organization wants to extend the expire time for guest accounts by 30 days on each successful login.  This would result in a guest account remaining valid indefinitely as long as it was used within 30 days of last login and would expire if not used in 30 days.

I have found some examples of similar requests, but most do not have a full solution, and one suggests writing directly the database tables, which I am not excited about. 

http://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/Clearpass-rolling-expiry-timers/td-p/137181

I was hopeful I could accomplish this with an enforcement profile.  There is a 'ClearPass Entity Update Enforcement' of:

Type: Expire-Time-Update
Name: GuestUser

Is my goal the intent of this attribute?  If so, can someone assist me with the proper value syntax?

I have also attempted by creating a dictionary attribute in CPPM for the expire_time field from entity GuestUser and manipulating it via an enforcement profile with no good results. 

If anyone knows another/better approach to this solution, please direct me.

Thank you in advance.

2) Create a context server dictionary entry to perform the API action:

3) Create an enforcement profile that references this dictionary entry to perform the action.

Action = Extend Expiration

4) Add enforcement profile to your enforcement policy

Open your enforcement policy and add the enforcement profile created in step 3.  This will perform the API action and extend the expire_time attribute on the guest user account.

5)  Ensure that the [Time Source] is added as an Authorization Source on the relevant Service

This was working for us, every time a user authenticates the enforcement profile is activated the expire_time for that account is extended for 1 year.  This allows for any accounts not used in 1 year to be automatically deleted, while indefinitely extending active accounts.

Original Message:
Sent: Feb 12, 2016 12:37 PM
From: David Johnson
Subject: ClearPass Guest Extend Expire Time

Hello,

My organization wants to extend the expire time for guest accounts by 30 days on each successful login.  This would result in a guest account remaining valid indefinitely as long as it was used within 30 days of last login and would expire if not used in 30 days.

I have found some examples of similar requests, but most do not have a full solution, and one suggests writing directly the database tables, which I am not excited about. 

http://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/Clearpass-rolling-expiry-timers/td-p/137181

I was hopeful I could accomplish this with an enforcement profile.  There is a 'ClearPass Entity Update Enforcement' of:

Type: Expire-Time-Update
Name: GuestUser

Is my goal the intent of this attribute?  If so, can someone assist me with the proper value syntax?

I have also attempted by creating a dictionary attribute in CPPM for the expire_time field from entity GuestUser and manipulating it via an enforcement profile with no good results. 

If anyone knows another/better approach to this solution, please direct me.

Thank you in advance.

Hi HPE Team,

I have implemented this configuration in one of my customer and somehow after the Internal API call happens, there is CoA sent by ClearPass out of nowhere. TAC also seems to be confused on where the CoA triggered from, and I have shared to them the Async Network DEBUG logs as per they requested but seems the TACs don't have same understanding between them and the progress of this case is really slow. Here is the case number: 5387333867.

I am afraid it is a product defect, on why it sends out the CoA after the Internal API call, unless you can tell me otherwise that this is a normal and expected behavior. The CoA causes RTO 3 times after the Enforcement is done, and my customer has the requirement to do reauthentication every 8-hours, so this is a bad thing for them coz it causes network downtime. The customer itself is a healthcare segment and they cannot tolerate it.

Original Message:
Sent: Nov 11, 2020 06:27 PM
From: a_human
Subject: ClearPass Guest Extend Expire Time

I recently worked with TAC to solve this very problem. It is not possible to do this with a simple post-auth enforcement profile utilizing the Expire-Time-Update attribute as I had originally thought, Clearpass will only let you reduce the expire_time with this attribute, not extend it.  However, you can effectively extend the expire_time by performing a SQL query or an internal API call.  We chose the API call route as its a bit more straightforward, you will need to set up an HTTP Context Server Action Dictionary and then reference that in an Enforcement Profile. You will also need to add a Time Source filter that matches the time you want to extend by (Now Plus 30days) and add the Time Source as an authorization source in your service.  In my case I extended expiration by 1 year, here's how i did it:


1) Create a Time Source filter for the time period you want to extend by

2) Create a context server dictionary entry to perform the API action:

3) Create an enforcement profile that references this dictionary entry to perform the action.

Action = Extend Expiration

4) Add enforcement profile to your enforcement policy

Open your enforcement policy and add the enforcement profile created in step 3.  This will perform the API action and extend the expire_time attribute on the guest user account.

5)  Ensure that the [Time Source] is added as an Authorization Source on the relevant Service

This was working for us, every time a user authenticates the enforcement profile is activated the expire_time for that account is extended for 1 year.  This allows for any accounts not used in 1 year to be automatically deleted, while indefinitely extending active accounts.

Original Message:
Sent: Feb 12, 2016 12:37 PM
From: David Johnson
Subject: ClearPass Guest Extend Expire Time

Hello,

My organization wants to extend the expire time for guest accounts by 30 days on each successful login.  This would result in a guest account remaining valid indefinitely as long as it was used within 30 days of last login and would expire if not used in 30 days.

I have found some examples of similar requests, but most do not have a full solution, and one suggests writing directly the database tables, which I am not excited about. 

http://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/Clearpass-rolling-expiry-timers/td-p/137181

I was hopeful I could accomplish this with an enforcement profile.  There is a 'ClearPass Entity Update Enforcement' of:

Type: Expire-Time-Update
Name: GuestUser

Is my goal the intent of this attribute?  If so, can someone assist me with the proper value syntax?

I have also attempted by creating a dictionary attribute in CPPM for the expire_time field from entity GuestUser and manipulating it via an enforcement profile with no good results. 

If anyone knows another/better approach to this solution, please direct me.

Thank you in advance.

Changes to the device account should be expected to kick off a CoA in order to put the device back through policy in case you've made a change that means the device shouldn't be on the network anymore.

Change device, kick the device off the network to reevaluate.

The better question for this is, why would you be doing a workflow like this for a device that is apparently critical and must be on the network?

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Feb 04, 2025 05:15 AM
From: breenubee
Subject: ClearPass Guest Extend Expire Time

Hi HPE Team,

I have implemented this configuration in one of my customer and somehow after the Internal API call happens, there is CoA sent by ClearPass out of nowhere. TAC also seems to be confused on where the CoA triggered from, and I have shared to them the Async Network DEBUG logs as per they requested but seems the TACs don't have same understanding between them and the progress of this case is really slow. Here is the case number: 5387333867.

I am afraid it is a product defect, on why it sends out the CoA after the Internal API call, unless you can tell me otherwise that this is a normal and expected behavior. The CoA causes RTO 3 times after the Enforcement is done, and my customer has the requirement to do reauthentication every 8-hours, so this is a bad thing for them coz it causes network downtime. The customer itself is a healthcare segment and they cannot tolerate it.

Original Message:
Sent: Nov 11, 2020 06:27 PM
From: a_human
Subject: ClearPass Guest Extend Expire Time

I recently worked with TAC to solve this very problem. It is not possible to do this with a simple post-auth enforcement profile utilizing the Expire-Time-Update attribute as I had originally thought, Clearpass will only let you reduce the expire_time with this attribute, not extend it.  However, you can effectively extend the expire_time by performing a SQL query or an internal API call.  We chose the API call route as its a bit more straightforward, you will need to set up an HTTP Context Server Action Dictionary and then reference that in an Enforcement Profile. You will also need to add a Time Source filter that matches the time you want to extend by (Now Plus 30days) and add the Time Source as an authorization source in your service.  In my case I extended expiration by 1 year, here's how i did it:


1) Create a Time Source filter for the time period you want to extend by

2) Create a context server dictionary entry to perform the API action:

3) Create an enforcement profile that references this dictionary entry to perform the action.

Action = Extend Expiration

4) Add enforcement profile to your enforcement policy

Open your enforcement policy and add the enforcement profile created in step 3.  This will perform the API action and extend the expire_time attribute on the guest user account.

5)  Ensure that the [Time Source] is added as an Authorization Source on the relevant Service

This was working for us, every time a user authenticates the enforcement profile is activated the expire_time for that account is extended for 1 year.  This allows for any accounts not used in 1 year to be automatically deleted, while indefinitely extending active accounts.

Original Message:
Sent: Feb 12, 2016 12:37 PM
From: David Johnson
Subject: ClearPass Guest Extend Expire Time

Hello,

My organization wants to extend the expire time for guest accounts by 30 days on each successful login.  This would result in a guest account remaining valid indefinitely as long as it was used within 30 days of last login and would expire if not used in 30 days.

I have found some examples of similar requests, but most do not have a full solution, and one suggests writing directly the database tables, which I am not excited about. 

http://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/Clearpass-rolling-expiry-timers/td-p/137181

I was hopeful I could accomplish this with an enforcement profile.  There is a 'ClearPass Entity Update Enforcement' of:

Type: Expire-Time-Update
Name: GuestUser

Is my goal the intent of this attribute?  If so, can someone assist me with the proper value syntax?

I have also attempted by creating a dictionary attribute in CPPM for the expire_time field from entity GuestUser and manipulating it via an enforcement profile with no good results. 

If anyone knows another/better approach to this solution, please direct me.

Thank you in advance.

Hi Carson,

Thanks for your response-it really made me take a moment to think before answering.

Basically, we follow a nationwide healthcare configuration standard, where reauthentication is enforced every 8 hours. Once the session expires, a CoA (Change of Authorization) is triggered-specifically a Reauthenticate Session, rather than a Terminate Session. Based on our observations, CoA-Reauth doesn't appear to cause an RTO (Request Timeout) on the endpoint side. But in this case, after the Internal API call, always the CoA-Terminate-Session sent out by CPPM back to the NAD, so it causes RTOs (at least x3 RTO).

A bit background to this configuration: We heavily use the Guest Device Repository with 802.1x-devices also registered onto it, for some reason, such as we are limited by the environment capability to do device profiling so we could not see other means to differentiate a device to another, hence the "whitelisting" via Guest Device Repository.

Note that we do have the systems that doesn't have reauth-timer, such as Access Points, and other critical systems (I could not tell further). For these devices we consider this as a deviation from standard (like an exception).

Edit: And the customer requests that everything under the Guest Device Repo should have the Expiry Date because to maintain the registered devices there is so cumbersome since we have a 10K+ devices.

Original Message:
Sent: Feb 04, 2025 10:41 AM
From: chulcher
Subject: ClearPass Guest Extend Expire Time

Changes to the device account should be expected to kick off a CoA in order to put the device back through policy in case you've made a change that means the device shouldn't be on the network anymore.

Change device, kick the device off the network to reevaluate.

The better question for this is, why would you be doing a workflow like this for a device that is apparently critical and must be on the network?

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Feb 04, 2025 05:15 AM
From: breenubee
Subject: ClearPass Guest Extend Expire Time

Hi HPE Team,

I have implemented this configuration in one of my customer and somehow after the Internal API call happens, there is CoA sent by ClearPass out of nowhere. TAC also seems to be confused on where the CoA triggered from, and I have shared to them the Async Network DEBUG logs as per they requested but seems the TACs don't have same understanding between them and the progress of this case is really slow. Here is the case number: 5387333867.

I am afraid it is a product defect, on why it sends out the CoA after the Internal API call, unless you can tell me otherwise that this is a normal and expected behavior. The CoA causes RTO 3 times after the Enforcement is done, and my customer has the requirement to do reauthentication every 8-hours, so this is a bad thing for them coz it causes network downtime. The customer itself is a healthcare segment and they cannot tolerate it.

Original Message:
Sent: Nov 11, 2020 06:27 PM
From: a_human
Subject: ClearPass Guest Extend Expire Time

I recently worked with TAC to solve this very problem. It is not possible to do this with a simple post-auth enforcement profile utilizing the Expire-Time-Update attribute as I had originally thought, Clearpass will only let you reduce the expire_time with this attribute, not extend it.  However, you can effectively extend the expire_time by performing a SQL query or an internal API call.  We chose the API call route as its a bit more straightforward, you will need to set up an HTTP Context Server Action Dictionary and then reference that in an Enforcement Profile. You will also need to add a Time Source filter that matches the time you want to extend by (Now Plus 30days) and add the Time Source as an authorization source in your service.  In my case I extended expiration by 1 year, here's how i did it:


1) Create a Time Source filter for the time period you want to extend by

2) Create a context server dictionary entry to perform the API action:

3) Create an enforcement profile that references this dictionary entry to perform the action.

Action = Extend Expiration

4) Add enforcement profile to your enforcement policy

Open your enforcement policy and add the enforcement profile created in step 3.  This will perform the API action and extend the expire_time attribute on the guest user account.

5)  Ensure that the [Time Source] is added as an Authorization Source on the relevant Service

This was working for us, every time a user authenticates the enforcement profile is activated the expire_time for that account is extended for 1 year.  This allows for any accounts not used in 1 year to be automatically deleted, while indefinitely extending active accounts.

Original Message:
Sent: Feb 12, 2016 12:37 PM
From: David Johnson
Subject: ClearPass Guest Extend Expire Time

Hello,

My organization wants to extend the expire time for guest accounts by 30 days on each successful login.  This would result in a guest account remaining valid indefinitely as long as it was used within 30 days of last login and would expire if not used in 30 days.

I have found some examples of similar requests, but most do not have a full solution, and one suggests writing directly the database tables, which I am not excited about. 

http://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/Clearpass-rolling-expiry-timers/td-p/137181

I was hopeful I could accomplish this with an enforcement profile.  There is a 'ClearPass Entity Update Enforcement' of:

Type: Expire-Time-Update
Name: GuestUser

Is my goal the intent of this attribute?  If so, can someone assist me with the proper value syntax?

I have also attempted by creating a dictionary attribute in CPPM for the expire_time field from entity GuestUser and manipulating it via an enforcement profile with no good results. 

If anyone knows another/better approach to this solution, please direct me.

Thank you in advance.

This is wired or wireless?

You are or are not using reauthentication via the RADIUS Session-Timeout TLV?

This is 802.1X or MAC auth?

Hi Carson,

Thanks for your response-it really made me take a moment to think before answering.

Basically, we follow a nationwide healthcare configuration standard, where reauthentication is enforced every 8 hours. Once the session expires, a CoA (Change of Authorization) is triggered-specifically a Reauthenticate Session, rather than a Terminate Session. Based on our observations, CoA-Reauth doesn't appear to cause an RTO (Request Timeout) on the endpoint side. But in this case, after the Internal API call, always the CoA-Terminate-Session sent out by CPPM back to the NAD, so it causes RTOs (at least x3 RTO).

A bit background to this configuration: We heavily use the Guest Device Repository with 802.1x-devices also registered onto it, for some reason, such as we are limited by the environment capability to do device profiling so we could not see other means to differentiate a device to another, hence the "whitelisting" via Guest Device Repository.

Note that we do have the systems that doesn't have reauth-timer, such as Access Points, and other critical systems (I could not tell further). For these devices we consider this as a deviation from standard (like an exception).

Edit: And the customer requests that everything under the Guest Device Repo should have the Expiry Date because to maintain the registered devices there is so cumbersome since we have a 10K+ devices.

Original Message:
Sent: Feb 04, 2025 10:41 AM
From: chulcher
Subject: ClearPass Guest Extend Expire Time

Changes to the device account should be expected to kick off a CoA in order to put the device back through policy in case you've made a change that means the device shouldn't be on the network anymore.

Change device, kick the device off the network to reevaluate.

The better question for this is, why would you be doing a workflow like this for a device that is apparently critical and must be on the network?

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Feb 04, 2025 05:15 AM
From: breenubee
Subject: ClearPass Guest Extend Expire Time

Hi HPE Team,

I have implemented this configuration in one of my customer and somehow after the Internal API call happens, there is CoA sent by ClearPass out of nowhere. TAC also seems to be confused on where the CoA triggered from, and I have shared to them the Async Network DEBUG logs as per they requested but seems the TACs don't have same understanding between them and the progress of this case is really slow. Here is the case number: 5387333867.

I am afraid it is a product defect, on why it sends out the CoA after the Internal API call, unless you can tell me otherwise that this is a normal and expected behavior. The CoA causes RTO 3 times after the Enforcement is done, and my customer has the requirement to do reauthentication every 8-hours, so this is a bad thing for them coz it causes network downtime. The customer itself is a healthcare segment and they cannot tolerate it.

Original Message:
Sent: Nov 11, 2020 06:27 PM
From: a_human
Subject: ClearPass Guest Extend Expire Time

I recently worked with TAC to solve this very problem. It is not possible to do this with a simple post-auth enforcement profile utilizing the Expire-Time-Update attribute as I had originally thought, Clearpass will only let you reduce the expire_time with this attribute, not extend it.  However, you can effectively extend the expire_time by performing a SQL query or an internal API call.  We chose the API call route as its a bit more straightforward, you will need to set up an HTTP Context Server Action Dictionary and then reference that in an Enforcement Profile. You will also need to add a Time Source filter that matches the time you want to extend by (Now Plus 30days) and add the Time Source as an authorization source in your service.  In my case I extended expiration by 1 year, here's how i did it:


1) Create a Time Source filter for the time period you want to extend by

2) Create a context server dictionary entry to perform the API action:

3) Create an enforcement profile that references this dictionary entry to perform the action.

Action = Extend Expiration

4) Add enforcement profile to your enforcement policy

Open your enforcement policy and add the enforcement profile created in step 3.  This will perform the API action and extend the expire_time attribute on the guest user account.

5)  Ensure that the [Time Source] is added as an Authorization Source on the relevant Service

This was working for us, every time a user authenticates the enforcement profile is activated the expire_time for that account is extended for 1 year.  This allows for any accounts not used in 1 year to be automatically deleted, while indefinitely extending active accounts.

Original Message:
Sent: Feb 12, 2016 12:37 PM
From: David Johnson
Subject: ClearPass Guest Extend Expire Time

Hello,

My organization wants to extend the expire time for guest accounts by 30 days on each successful login.  This would result in a guest account remaining valid indefinitely as long as it was used within 30 days of last login and would expire if not used in 30 days.

I have found some examples of similar requests, but most do not have a full solution, and one suggests writing directly the database tables, which I am not excited about. 

http://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/Clearpass-rolling-expiry-timers/td-p/137181

I was hopeful I could accomplish this with an enforcement profile.  There is a 'ClearPass Entity Update Enforcement' of:

Type: Expire-Time-Update
Name: GuestUser

Is my goal the intent of this attribute?  If so, can someone assist me with the proper value syntax?

I have also attempted by creating a dictionary attribute in CPPM for the expire_time field from entity GuestUser and manipulating it via an enforcement profile with no good results. 

If anyone knows another/better approach to this solution, please direct me.

Thank you in advance.

Hi Carson,

This is for both wired and wireless.

I am using the Session-Timeout (27) in the Enforcement Profile.

This is for 802.1x. For Mac-Auth we already have the solution. TAC said we cannot have the same solution for 802.1x because the username in 802.1x authentication is not the MAC address, hence cannot extend the expiry date with the same way.

Since we have the Expiry Date, we have to configure the Session-Timeout (27) to continuously extend the expiry date with the reauth.

For devices like AP, we don't have the reauth as well as the Expiry Date.

Please correct me if I am wrong about the understanding of the "TLV". Thanks much!

This is wired or wireless?

You are or are not using reauthentication via the RADIUS Session-Timeout TLV?

This is 802.1X or MAC auth?

Hi Carson,

Thanks for your response-it really made me take a moment to think before answering.

Basically, we follow a nationwide healthcare configuration standard, where reauthentication is enforced every 8 hours. Once the session expires, a CoA (Change of Authorization) is triggered-specifically a Reauthenticate Session, rather than a Terminate Session. Based on our observations, CoA-Reauth doesn't appear to cause an RTO (Request Timeout) on the endpoint side. But in this case, after the Internal API call, always the CoA-Terminate-Session sent out by CPPM back to the NAD, so it causes RTOs (at least x3 RTO).

A bit background to this configuration: We heavily use the Guest Device Repository with 802.1x-devices also registered onto it, for some reason, such as we are limited by the environment capability to do device profiling so we could not see other means to differentiate a device to another, hence the "whitelisting" via Guest Device Repository.

Note that we do have the systems that doesn't have reauth-timer, such as Access Points, and other critical systems (I could not tell further). For these devices we consider this as a deviation from standard (like an exception).

Edit: And the customer requests that everything under the Guest Device Repo should have the Expiry Date because to maintain the registered devices there is so cumbersome since we have a 10K+ devices.

Original Message:
Sent: Feb 04, 2025 10:41 AM
From: chulcher
Subject: ClearPass Guest Extend Expire Time

Changes to the device account should be expected to kick off a CoA in order to put the device back through policy in case you've made a change that means the device shouldn't be on the network anymore.

Change device, kick the device off the network to reevaluate.

The better question for this is, why would you be doing a workflow like this for a device that is apparently critical and must be on the network?

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Feb 04, 2025 05:15 AM
From: breenubee
Subject: ClearPass Guest Extend Expire Time

Hi HPE Team,

I have implemented this configuration in one of my customer and somehow after the Internal API call happens, there is CoA sent by ClearPass out of nowhere. TAC also seems to be confused on where the CoA triggered from, and I have shared to them the Async Network DEBUG logs as per they requested but seems the TACs don't have same understanding between them and the progress of this case is really slow. Here is the case number: 5387333867.

I am afraid it is a product defect, on why it sends out the CoA after the Internal API call, unless you can tell me otherwise that this is a normal and expected behavior. The CoA causes RTO 3 times after the Enforcement is done, and my customer has the requirement to do reauthentication every 8-hours, so this is a bad thing for them coz it causes network downtime. The customer itself is a healthcare segment and they cannot tolerate it.

Original Message:
Sent: Nov 11, 2020 06:27 PM
From: a_human
Subject: ClearPass Guest Extend Expire Time

I recently worked with TAC to solve this very problem. It is not possible to do this with a simple post-auth enforcement profile utilizing the Expire-Time-Update attribute as I had originally thought, Clearpass will only let you reduce the expire_time with this attribute, not extend it.  However, you can effectively extend the expire_time by performing a SQL query or an internal API call.  We chose the API call route as its a bit more straightforward, you will need to set up an HTTP Context Server Action Dictionary and then reference that in an Enforcement Profile. You will also need to add a Time Source filter that matches the time you want to extend by (Now Plus 30days) and add the Time Source as an authorization source in your service.  In my case I extended expiration by 1 year, here's how i did it:


1) Create a Time Source filter for the time period you want to extend by

2) Create a context server dictionary entry to perform the API action:

3) Create an enforcement profile that references this dictionary entry to perform the action.

Action = Extend Expiration

4) Add enforcement profile to your enforcement policy

Open your enforcement policy and add the enforcement profile created in step 3.  This will perform the API action and extend the expire_time attribute on the guest user account.

5)  Ensure that the [Time Source] is added as an Authorization Source on the relevant Service

This was working for us, every time a user authenticates the enforcement profile is activated the expire_time for that account is extended for 1 year.  This allows for any accounts not used in 1 year to be automatically deleted, while indefinitely extending active accounts.

Original Message:
Sent: Feb 12, 2016 12:37 PM
From: David Johnson
Subject: ClearPass Guest Extend Expire Time

Hello,

My organization wants to extend the expire time for guest accounts by 30 days on each successful login.  This would result in a guest account remaining valid indefinitely as long as it was used within 30 days of last login and would expire if not used in 30 days.

I have found some examples of similar requests, but most do not have a full solution, and one suggests writing directly the database tables, which I am not excited about. 

http://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/Clearpass-rolling-expiry-timers/td-p/137181

I was hopeful I could accomplish this with an enforcement profile.  There is a 'ClearPass Entity Update Enforcement' of:

Type: Expire-Time-Update
Name: GuestUser

Is my goal the intent of this attribute?  If so, can someone assist me with the proper value syntax?

I have also attempted by creating a dictionary attribute in CPPM for the expire_time field from entity GuestUser and manipulating it via an enforcement profile with no good results. 

If anyone knows another/better approach to this solution, please direct me.

Thank you in advance.

If you are using 802.1X, then why bother with registering the device?  You have credentials being used in the EAP exchange, if you need the device to not be on the network, then disable the credentials.

Note, the difference in reauthenticate vs terminated session is to be expected.  Reauthenticate prompts the NAS (assuming 802.1X) to initiate an EAP exchange whereas terminate session just de-authenticates the session and forces everything to start over.  Terminate session should be used for wireless sessions where the device should be disconnected.  Switches should be instructed to bounce the port.

Hi Carson,

This is for both wired and wireless.

I am using the Session-Timeout (27) in the Enforcement Profile.

This is for 802.1x. For Mac-Auth we already have the solution. TAC said we cannot have the same solution for 802.1x because the username in 802.1x authentication is not the MAC address, hence cannot extend the expiry date with the same way.

Since we have the Expiry Date, we have to configure the Session-Timeout (27) to continuously extend the expiry date with the reauth.

For devices like AP, we don't have the reauth as well as the Expiry Date.

Please correct me if I am wrong about the understanding of the "TLV". Thanks much!

This is wired or wireless?

You are or are not using reauthentication via the RADIUS Session-Timeout TLV?

This is 802.1X or MAC auth?

Hi Carson,

Thanks for your response-it really made me take a moment to think before answering.

Basically, we follow a nationwide healthcare configuration standard, where reauthentication is enforced every 8 hours. Once the session expires, a CoA (Change of Authorization) is triggered-specifically a Reauthenticate Session, rather than a Terminate Session. Based on our observations, CoA-Reauth doesn't appear to cause an RTO (Request Timeout) on the endpoint side. But in this case, after the Internal API call, always the CoA-Terminate-Session sent out by CPPM back to the NAD, so it causes RTOs (at least x3 RTO).

A bit background to this configuration: We heavily use the Guest Device Repository with 802.1x-devices also registered onto it, for some reason, such as we are limited by the environment capability to do device profiling so we could not see other means to differentiate a device to another, hence the "whitelisting" via Guest Device Repository.

Note that we do have the systems that doesn't have reauth-timer, such as Access Points, and other critical systems (I could not tell further). For these devices we consider this as a deviation from standard (like an exception).

Edit: And the customer requests that everything under the Guest Device Repo should have the Expiry Date because to maintain the registered devices there is so cumbersome since we have a 10K+ devices.

Original Message:
Sent: Feb 04, 2025 10:41 AM
From: chulcher
Subject: ClearPass Guest Extend Expire Time

Changes to the device account should be expected to kick off a CoA in order to put the device back through policy in case you've made a change that means the device shouldn't be on the network anymore.

Change device, kick the device off the network to reevaluate.

The better question for this is, why would you be doing a workflow like this for a device that is apparently critical and must be on the network?

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Feb 04, 2025 05:15 AM
From: breenubee
Subject: ClearPass Guest Extend Expire Time

Hi HPE Team,

I have implemented this configuration in one of my customer and somehow after the Internal API call happens, there is CoA sent by ClearPass out of nowhere. TAC also seems to be confused on where the CoA triggered from, and I have shared to them the Async Network DEBUG logs as per they requested but seems the TACs don't have same understanding between them and the progress of this case is really slow. Here is the case number: 5387333867.

I am afraid it is a product defect, on why it sends out the CoA after the Internal API call, unless you can tell me otherwise that this is a normal and expected behavior. The CoA causes RTO 3 times after the Enforcement is done, and my customer has the requirement to do reauthentication every 8-hours, so this is a bad thing for them coz it causes network downtime. The customer itself is a healthcare segment and they cannot tolerate it.

Original Message:
Sent: Nov 11, 2020 06:27 PM
From: a_human
Subject: ClearPass Guest Extend Expire Time

I recently worked with TAC to solve this very problem. It is not possible to do this with a simple post-auth enforcement profile utilizing the Expire-Time-Update attribute as I had originally thought, Clearpass will only let you reduce the expire_time with this attribute, not extend it.  However, you can effectively extend the expire_time by performing a SQL query or an internal API call.  We chose the API call route as its a bit more straightforward, you will need to set up an HTTP Context Server Action Dictionary and then reference that in an Enforcement Profile. You will also need to add a Time Source filter that matches the time you want to extend by (Now Plus 30days) and add the Time Source as an authorization source in your service.  In my case I extended expiration by 1 year, here's how i did it:


1) Create a Time Source filter for the time period you want to extend by

2) Create a context server dictionary entry to perform the API action:

3) Create an enforcement profile that references this dictionary entry to perform the action.

Action = Extend Expiration

4) Add enforcement profile to your enforcement policy

Open your enforcement policy and add the enforcement profile created in step 3.  This will perform the API action and extend the expire_time attribute on the guest user account.

5)  Ensure that the [Time Source] is added as an Authorization Source on the relevant Service

This was working for us, every time a user authenticates the enforcement profile is activated the expire_time for that account is extended for 1 year.  This allows for any accounts not used in 1 year to be automatically deleted, while indefinitely extending active accounts.

Original Message:
Sent: Feb 12, 2016 12:37 PM
From: David Johnson
Subject: ClearPass Guest Extend Expire Time

Hello,

My organization wants to extend the expire time for guest accounts by 30 days on each successful login.  This would result in a guest account remaining valid indefinitely as long as it was used within 30 days of last login and would expire if not used in 30 days.

I have found some examples of similar requests, but most do not have a full solution, and one suggests writing directly the database tables, which I am not excited about. 

http://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/Clearpass-rolling-expiry-timers/td-p/137181

I was hopeful I could accomplish this with an enforcement profile.  There is a 'ClearPass Entity Update Enforcement' of:

Type: Expire-Time-Update
Name: GuestUser

Is my goal the intent of this attribute?  If so, can someone assist me with the proper value syntax?

I have also attempted by creating a dictionary attribute in CPPM for the expire_time field from entity GuestUser and manipulating it via an enforcement profile with no good results. 

If anyone knows another/better approach to this solution, please direct me.

Thank you in advance.

Hi Carson,

I need to put the similar devices (mostly Windows) to a different VLAN. And, we cannot predict these Windows user identity (who uses the machine), so I am thinking to register the MAC addresses into the Guest Device Repo.

Noted on the CoA reauth and terminate session. So, is there any way we can change the behavior post-Internal-API-call? As I mentioned above, we are surprised that Terminate-Session is sent back to the NAD, where actually the Reauth-Session should be sufficient. Or, is there any way to stop the CPPM to send the CoA back to the NAD at all ?

If you are using 802.1X, then why bother with registering the device?  You have credentials being used in the EAP exchange, if you need the device to not be on the network, then disable the credentials.

Note, the difference in reauthenticate vs terminated session is to be expected.  Reauthenticate prompts the NAS (assuming 802.1X) to initiate an EAP exchange whereas terminate session just de-authenticates the session and forces everything to start over.  Terminate session should be used for wireless sessions where the device should be disconnected.  Switches should be instructed to bounce the port.

Hi Carson,

This is for both wired and wireless.

I am using the Session-Timeout (27) in the Enforcement Profile.

This is for 802.1x. For Mac-Auth we already have the solution. TAC said we cannot have the same solution for 802.1x because the username in 802.1x authentication is not the MAC address, hence cannot extend the expiry date with the same way.

Since we have the Expiry Date, we have to configure the Session-Timeout (27) to continuously extend the expiry date with the reauth.

For devices like AP, we don't have the reauth as well as the Expiry Date.

Please correct me if I am wrong about the understanding of the "TLV". Thanks much!

This is wired or wireless?

You are or are not using reauthentication via the RADIUS Session-Timeout TLV?

This is 802.1X or MAC auth?

Hi Carson,

Thanks for your response-it really made me take a moment to think before answering.

Basically, we follow a nationwide healthcare configuration standard, where reauthentication is enforced every 8 hours. Once the session expires, a CoA (Change of Authorization) is triggered-specifically a Reauthenticate Session, rather than a Terminate Session. Based on our observations, CoA-Reauth doesn't appear to cause an RTO (Request Timeout) on the endpoint side. But in this case, after the Internal API call, always the CoA-Terminate-Session sent out by CPPM back to the NAD, so it causes RTOs (at least x3 RTO).

A bit background to this configuration: We heavily use the Guest Device Repository with 802.1x-devices also registered onto it, for some reason, such as we are limited by the environment capability to do device profiling so we could not see other means to differentiate a device to another, hence the "whitelisting" via Guest Device Repository.

Note that we do have the systems that doesn't have reauth-timer, such as Access Points, and other critical systems (I could not tell further). For these devices we consider this as a deviation from standard (like an exception).

Edit: And the customer requests that everything under the Guest Device Repo should have the Expiry Date because to maintain the registered devices there is so cumbersome since we have a 10K+ devices.

Original Message:
Sent: Feb 04, 2025 10:41 AM
From: chulcher
Subject: ClearPass Guest Extend Expire Time

Changes to the device account should be expected to kick off a CoA in order to put the device back through policy in case you've made a change that means the device shouldn't be on the network anymore.

Change device, kick the device off the network to reevaluate.

The better question for this is, why would you be doing a workflow like this for a device that is apparently critical and must be on the network?

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Feb 04, 2025 05:15 AM
From: breenubee
Subject: ClearPass Guest Extend Expire Time

Hi HPE Team,

I have implemented this configuration in one of my customer and somehow after the Internal API call happens, there is CoA sent by ClearPass out of nowhere. TAC also seems to be confused on where the CoA triggered from, and I have shared to them the Async Network DEBUG logs as per they requested but seems the TACs don't have same understanding between them and the progress of this case is really slow. Here is the case number: 5387333867.

I am afraid it is a product defect, on why it sends out the CoA after the Internal API call, unless you can tell me otherwise that this is a normal and expected behavior. The CoA causes RTO 3 times after the Enforcement is done, and my customer has the requirement to do reauthentication every 8-hours, so this is a bad thing for them coz it causes network downtime. The customer itself is a healthcare segment and they cannot tolerate it.

Original Message:
Sent: Nov 11, 2020 06:27 PM
From: a_human
Subject: ClearPass Guest Extend Expire Time

I recently worked with TAC to solve this very problem. It is not possible to do this with a simple post-auth enforcement profile utilizing the Expire-Time-Update attribute as I had originally thought, Clearpass will only let you reduce the expire_time with this attribute, not extend it.  However, you can effectively extend the expire_time by performing a SQL query or an internal API call.  We chose the API call route as its a bit more straightforward, you will need to set up an HTTP Context Server Action Dictionary and then reference that in an Enforcement Profile. You will also need to add a Time Source filter that matches the time you want to extend by (Now Plus 30days) and add the Time Source as an authorization source in your service.  In my case I extended expiration by 1 year, here's how i did it:


1) Create a Time Source filter for the time period you want to extend by

2) Create a context server dictionary entry to perform the API action:

3) Create an enforcement profile that references this dictionary entry to perform the action.

Action = Extend Expiration

4) Add enforcement profile to your enforcement policy

Open your enforcement policy and add the enforcement profile created in step 3.  This will perform the API action and extend the expire_time attribute on the guest user account.

5)  Ensure that the [Time Source] is added as an Authorization Source on the relevant Service

This was working for us, every time a user authenticates the enforcement profile is activated the expire_time for that account is extended for 1 year.  This allows for any accounts not used in 1 year to be automatically deleted, while indefinitely extending active accounts.

Original Message:
Sent: Feb 12, 2016 12:37 PM
From: David Johnson
Subject: ClearPass Guest Extend Expire Time

Hello,

My organization wants to extend the expire time for guest accounts by 30 days on each successful login.  This would result in a guest account remaining valid indefinitely as long as it was used within 30 days of last login and would expire if not used in 30 days.

I have found some examples of similar requests, but most do not have a full solution, and one suggests writing directly the database tables, which I am not excited about. 

http://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/Clearpass-rolling-expiry-timers/td-p/137181

I was hopeful I could accomplish this with an enforcement profile.  There is a 'ClearPass Entity Update Enforcement' of:

Type: Expire-Time-Update
Name: GuestUser

Is my goal the intent of this attribute?  If so, can someone assist me with the proper value syntax?

I have also attempted by creating a dictionary attribute in CPPM for the expire_time field from entity GuestUser and manipulating it via an enforcement profile with no good results. 

If anyone knows another/better approach to this solution, please direct me.

Thank you in advance.

Authenticate the device (computer authentication) or use TEAP to authenticate the computer and user, apply policy based on whatever part of that is interesting.  Use the device management (Active Directory, Intune, etc.) if needed for additional authorization information that is specifically tied to the credentials used.

I don't know of a way to change or disable the dynamic authorization response on the account update.

Hi Carson,

I need to put the similar devices (mostly Windows) to a different VLAN. And, we cannot predict these Windows user identity (who uses the machine), so I am thinking to register the MAC addresses into the Guest Device Repo.

Noted on the CoA reauth and terminate session. So, is there any way we can change the behavior post-Internal-API-call? As I mentioned above, we are surprised that Terminate-Session is sent back to the NAD, where actually the Reauth-Session should be sufficient. Or, is there any way to stop the CPPM to send the CoA back to the NAD at all ?

If you are using 802.1X, then why bother with registering the device?  You have credentials being used in the EAP exchange, if you need the device to not be on the network, then disable the credentials.

Note, the difference in reauthenticate vs terminated session is to be expected.  Reauthenticate prompts the NAS (assuming 802.1X) to initiate an EAP exchange whereas terminate session just de-authenticates the session and forces everything to start over.  Terminate session should be used for wireless sessions where the device should be disconnected.  Switches should be instructed to bounce the port.

Hi Carson,

This is for both wired and wireless.

I am using the Session-Timeout (27) in the Enforcement Profile.

This is for 802.1x. For Mac-Auth we already have the solution. TAC said we cannot have the same solution for 802.1x because the username in 802.1x authentication is not the MAC address, hence cannot extend the expiry date with the same way.

Since we have the Expiry Date, we have to configure the Session-Timeout (27) to continuously extend the expiry date with the reauth.

For devices like AP, we don't have the reauth as well as the Expiry Date.

Please correct me if I am wrong about the understanding of the "TLV". Thanks much!

This is wired or wireless?

You are or are not using reauthentication via the RADIUS Session-Timeout TLV?

This is 802.1X or MAC auth?

Hi Carson,

Thanks for your response-it really made me take a moment to think before answering.

Basically, we follow a nationwide healthcare configuration standard, where reauthentication is enforced every 8 hours. Once the session expires, a CoA (Change of Authorization) is triggered-specifically a Reauthenticate Session, rather than a Terminate Session. Based on our observations, CoA-Reauth doesn't appear to cause an RTO (Request Timeout) on the endpoint side. But in this case, after the Internal API call, always the CoA-Terminate-Session sent out by CPPM back to the NAD, so it causes RTOs (at least x3 RTO).

A bit background to this configuration: We heavily use the Guest Device Repository with 802.1x-devices also registered onto it, for some reason, such as we are limited by the environment capability to do device profiling so we could not see other means to differentiate a device to another, hence the "whitelisting" via Guest Device Repository.

Note that we do have the systems that doesn't have reauth-timer, such as Access Points, and other critical systems (I could not tell further). For these devices we consider this as a deviation from standard (like an exception).

Edit: And the customer requests that everything under the Guest Device Repo should have the Expiry Date because to maintain the registered devices there is so cumbersome since we have a 10K+ devices.

Original Message:
Sent: Feb 04, 2025 10:41 AM
From: chulcher
Subject: ClearPass Guest Extend Expire Time

Changes to the device account should be expected to kick off a CoA in order to put the device back through policy in case you've made a change that means the device shouldn't be on the network anymore.

Change device, kick the device off the network to reevaluate.

The better question for this is, why would you be doing a workflow like this for a device that is apparently critical and must be on the network?

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Feb 04, 2025 05:15 AM
From: breenubee
Subject: ClearPass Guest Extend Expire Time

Hi HPE Team,

I have implemented this configuration in one of my customer and somehow after the Internal API call happens, there is CoA sent by ClearPass out of nowhere. TAC also seems to be confused on where the CoA triggered from, and I have shared to them the Async Network DEBUG logs as per they requested but seems the TACs don't have same understanding between them and the progress of this case is really slow. Here is the case number: 5387333867.

I am afraid it is a product defect, on why it sends out the CoA after the Internal API call, unless you can tell me otherwise that this is a normal and expected behavior. The CoA causes RTO 3 times after the Enforcement is done, and my customer has the requirement to do reauthentication every 8-hours, so this is a bad thing for them coz it causes network downtime. The customer itself is a healthcare segment and they cannot tolerate it.

Original Message:
Sent: Nov 11, 2020 06:27 PM
From: a_human
Subject: ClearPass Guest Extend Expire Time

I recently worked with TAC to solve this very problem. It is not possible to do this with a simple post-auth enforcement profile utilizing the Expire-Time-Update attribute as I had originally thought, Clearpass will only let you reduce the expire_time with this attribute, not extend it.  However, you can effectively extend the expire_time by performing a SQL query or an internal API call.  We chose the API call route as its a bit more straightforward, you will need to set up an HTTP Context Server Action Dictionary and then reference that in an Enforcement Profile. You will also need to add a Time Source filter that matches the time you want to extend by (Now Plus 30days) and add the Time Source as an authorization source in your service.  In my case I extended expiration by 1 year, here's how i did it:


1) Create a Time Source filter for the time period you want to extend by

2) Create a context server dictionary entry to perform the API action:

3) Create an enforcement profile that references this dictionary entry to perform the action.

Action = Extend Expiration

4) Add enforcement profile to your enforcement policy

Open your enforcement policy and add the enforcement profile created in step 3.  This will perform the API action and extend the expire_time attribute on the guest user account.

5)  Ensure that the [Time Source] is added as an Authorization Source on the relevant Service

This was working for us, every time a user authenticates the enforcement profile is activated the expire_time for that account is extended for 1 year.  This allows for any accounts not used in 1 year to be automatically deleted, while indefinitely extending active accounts.

Original Message:
Sent: Feb 12, 2016 12:37 PM
From: David Johnson
Subject: ClearPass Guest Extend Expire Time

Hello,

My organization wants to extend the expire time for guest accounts by 30 days on each successful login.  This would result in a guest account remaining valid indefinitely as long as it was used within 30 days of last login and would expire if not used in 30 days.

I have found some examples of similar requests, but most do not have a full solution, and one suggests writing directly the database tables, which I am not excited about. 

http://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/Clearpass-rolling-expiry-timers/td-p/137181

I was hopeful I could accomplish this with an enforcement profile.  There is a 'ClearPass Entity Update Enforcement' of:

Type: Expire-Time-Update
Name: GuestUser

Is my goal the intent of this attribute?  If so, can someone assist me with the proper value syntax?

I have also attempted by creating a dictionary attribute in CPPM for the expire_time field from entity GuestUser and manipulating it via an enforcement profile with no good results. 

If anyone knows another/better approach to this solution, please direct me.

Thank you in advance.

We use this approach with several customers, each authentication extends the expiration date of the guest device by 30 days, for example. The URL in Context Server Actions must be extended as follows: "/api/device/mac/%{Connection:Client-Mac-Address-Hyphen}?change_of_authorization=false" . This allows expire_time to be extended without triggering CoA.

Authenticate the device (computer authentication) or use TEAP to authenticate the computer and user, apply policy based on whatever part of that is interesting.  Use the device management (Active Directory, Intune, etc.) if needed for additional authorization information that is specifically tied to the credentials used.

I don't know of a way to change or disable the dynamic authorization response on the account update.

Hi Carson,

I need to put the similar devices (mostly Windows) to a different VLAN. And, we cannot predict these Windows user identity (who uses the machine), so I am thinking to register the MAC addresses into the Guest Device Repo.

Noted on the CoA reauth and terminate session. So, is there any way we can change the behavior post-Internal-API-call? As I mentioned above, we are surprised that Terminate-Session is sent back to the NAD, where actually the Reauth-Session should be sufficient. Or, is there any way to stop the CPPM to send the CoA back to the NAD at all ?

If you are using 802.1X, then why bother with registering the device?  You have credentials being used in the EAP exchange, if you need the device to not be on the network, then disable the credentials.

Note, the difference in reauthenticate vs terminated session is to be expected.  Reauthenticate prompts the NAS (assuming 802.1X) to initiate an EAP exchange whereas terminate session just de-authenticates the session and forces everything to start over.  Terminate session should be used for wireless sessions where the device should be disconnected.  Switches should be instructed to bounce the port.

Hi Carson,

This is for both wired and wireless.

I am using the Session-Timeout (27) in the Enforcement Profile.

This is for 802.1x. For Mac-Auth we already have the solution. TAC said we cannot have the same solution for 802.1x because the username in 802.1x authentication is not the MAC address, hence cannot extend the expiry date with the same way.

Since we have the Expiry Date, we have to configure the Session-Timeout (27) to continuously extend the expiry date with the reauth.

For devices like AP, we don't have the reauth as well as the Expiry Date.

Please correct me if I am wrong about the understanding of the "TLV". Thanks much!

This is wired or wireless?

You are or are not using reauthentication via the RADIUS Session-Timeout TLV?

This is 802.1X or MAC auth?

Hi Carson,

Thanks for your response-it really made me take a moment to think before answering.

Basically, we follow a nationwide healthcare configuration standard, where reauthentication is enforced every 8 hours. Once the session expires, a CoA (Change of Authorization) is triggered-specifically a Reauthenticate Session, rather than a Terminate Session. Based on our observations, CoA-Reauth doesn't appear to cause an RTO (Request Timeout) on the endpoint side. But in this case, after the Internal API call, always the CoA-Terminate-Session sent out by CPPM back to the NAD, so it causes RTOs (at least x3 RTO).

A bit background to this configuration: We heavily use the Guest Device Repository with 802.1x-devices also registered onto it, for some reason, such as we are limited by the environment capability to do device profiling so we could not see other means to differentiate a device to another, hence the "whitelisting" via Guest Device Repository.

Note that we do have the systems that doesn't have reauth-timer, such as Access Points, and other critical systems (I could not tell further). For these devices we consider this as a deviation from standard (like an exception).

Edit: And the customer requests that everything under the Guest Device Repo should have the Expiry Date because to maintain the registered devices there is so cumbersome since we have a 10K+ devices.

Original Message:
Sent: Feb 04, 2025 10:41 AM
From: chulcher
Subject: ClearPass Guest Extend Expire Time

Changes to the device account should be expected to kick off a CoA in order to put the device back through policy in case you've made a change that means the device shouldn't be on the network anymore.

Change device, kick the device off the network to reevaluate.

The better question for this is, why would you be doing a workflow like this for a device that is apparently critical and must be on the network?

------------------------------
Carson Hulcher, ACEX#110

Original Message:
Sent: Feb 04, 2025 05:15 AM
From: breenubee
Subject: ClearPass Guest Extend Expire Time

Hi HPE Team,

I have implemented this configuration in one of my customer and somehow after the Internal API call happens, there is CoA sent by ClearPass out of nowhere. TAC also seems to be confused on where the CoA triggered from, and I have shared to them the Async Network DEBUG logs as per they requested but seems the TACs don't have same understanding between them and the progress of this case is really slow. Here is the case number: 5387333867.

I am afraid it is a product defect, on why it sends out the CoA after the Internal API call, unless you can tell me otherwise that this is a normal and expected behavior. The CoA causes RTO 3 times after the Enforcement is done, and my customer has the requirement to do reauthentication every 8-hours, so this is a bad thing for them coz it causes network downtime. The customer itself is a healthcare segment and they cannot tolerate it.

Original Message:
Sent: Nov 11, 2020 06:27 PM
From: a_human
Subject: ClearPass Guest Extend Expire Time

I recently worked with TAC to solve this very problem. It is not possible to do this with a simple post-auth enforcement profile utilizing the Expire-Time-Update attribute as I had originally thought, Clearpass will only let you reduce the expire_time with this attribute, not extend it.  However, you can effectively extend the expire_time by performing a SQL query or an internal API call.  We chose the API call route as its a bit more straightforward, you will need to set up an HTTP Context Server Action Dictionary and then reference that in an Enforcement Profile. You will also need to add a Time Source filter that matches the time you want to extend by (Now Plus 30days) and add the Time Source as an authorization source in your service.  In my case I extended expiration by 1 year, here's how i did it:


1) Create a Time Source filter for the time period you want to extend by

2) Create a context server dictionary entry to perform the API action:

3) Create an enforcement profile that references this dictionary entry to perform the action.

Action = Extend Expiration

4) Add enforcement profile to your enforcement policy

Open your enforcement policy and add the enforcement profile created in step 3.  This will perform the API action and extend the expire_time attribute on the guest user account.

5)  Ensure that the [Time Source] is added as an Authorization Source on the relevant Service

This was working for us, every time a user authenticates the enforcement profile is activated the expire_time for that account is extended for 1 year.  This allows for any accounts not used in 1 year to be automatically deleted, while indefinitely extending active accounts.

Original Message:
Sent: Feb 12, 2016 12:37 PM
From: David Johnson
Subject: ClearPass Guest Extend Expire Time

Hello,

My organization wants to extend the expire time for guest accounts by 30 days on each successful login.  This would result in a guest account remaining valid indefinitely as long as it was used within 30 days of last login and would expire if not used in 30 days.

I have found some examples of similar requests, but most do not have a full solution, and one suggests writing directly the database tables, which I am not excited about. 

http://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/Clearpass-rolling-expiry-timers/td-p/137181

I was hopeful I could accomplish this with an enforcement profile.  There is a 'ClearPass Entity Update Enforcement' of:

Type: Expire-Time-Update
Name: GuestUser

Is my goal the intent of this attribute?  If so, can someone assist me with the proper value syntax?

I have also attempted by creating a dictionary attribute in CPPM for the expire_time field from entity GuestUser and manipulating it via an enforcement profile with no good results. 

If anyone knows another/better approach to this solution, please direct me.

Thank you in advance.

Action = Extend Expiration

4) Add enforcement profile to your enforcement policy

Open your enforcement policy and add the enforcement profile created in step 3.  This will perform the API action and extend the expire_time attribute on the guest user account.

5)  Ensure that the [Time Source] is added as an Authorization Source on the relevant Service

This was working for us, every time a user authenticates the enforcement profile is activated the expire_time for that account is extended for 1 year.  This allows for any accounts not used in 1 year to be automatically deleted, while indefinitely extending active accounts.

Hello,

My organization wants to extend the expire time for guest accounts by 30 days on each successful login.  This would result in a guest account remaining valid indefinitely as long as it was used within 30 days of last login and would expire if not used in 30 days.

I have found some examples of similar requests, but most do not have a full solution, and one suggests writing directly the database tables, which I am not excited about. 

http://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/Clearpass-rolling-expiry-timers/td-p/137181

I was hopeful I could accomplish this with an enforcement profile.  There is a 'ClearPass Entity Update Enforcement' of:

Type: Expire-Time-Update
Name: GuestUser

Is my goal the intent of this attribute?  If so, can someone assist me with the proper value syntax?

I have also attempted by creating a dictionary attribute in CPPM for the expire_time field from entity GuestUser and manipulating it via an enforcement profile with no good results. 

If anyone knows another/better approach to this solution, please direct me.

Thank you in advance.

Action = Extend Expiration

4) Add enforcement profile to your enforcement policy

Open your enforcement policy and add the enforcement profile created in step 3.  This will perform the API action and extend the expire_time attribute on the guest user account.

5)  Ensure that the [Time Source] is added as an Authorization Source on the relevant Service

This was working for us, every time a user authenticates the enforcement profile is activated the expire_time for that account is extended for 1 year.  This allows for any accounts not used in 1 year to be automatically deleted, while indefinitely extending active accounts.

Hello,

My organization wants to extend the expire time for guest accounts by 30 days on each successful login.  This would result in a guest account remaining valid indefinitely as long as it was used within 30 days of last login and would expire if not used in 30 days.

I have found some examples of similar requests, but most do not have a full solution, and one suggests writing directly the database tables, which I am not excited about. 

http://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/Clearpass-rolling-expiry-timers/td-p/137181

I was hopeful I could accomplish this with an enforcement profile.  There is a 'ClearPass Entity Update Enforcement' of:

Type: Expire-Time-Update
Name: GuestUser

Is my goal the intent of this attribute?  If so, can someone assist me with the proper value syntax?

I have also attempted by creating a dictionary attribute in CPPM for the expire_time field from entity GuestUser and manipulating it via an enforcement profile with no good results. 

If anyone knows another/better approach to this solution, please direct me.

Thank you in advance.

Is there an updated version of this for CPPM 6.11 I tried to follow it but adding filters to the Time Source doesnt seem to be possible ?

Action = Extend Expiration

4) Add enforcement profile to your enforcement policy

Open your enforcement policy and add the enforcement profile created in step 3.  This will perform the API action and extend the expire_time attribute on the guest user account.

5)  Ensure that the [Time Source] is added as an Authorization Source on the relevant Service

This was working for us, every time a user authenticates the enforcement profile is activated the expire_time for that account is extended for 1 year.  This allows for any accounts not used in 1 year to be automatically deleted, while indefinitely extending active accounts.

Hello,

My organization wants to extend the expire time for guest accounts by 30 days on each successful login.  This would result in a guest account remaining valid indefinitely as long as it was used within 30 days of last login and would expire if not used in 30 days.

I have found some examples of similar requests, but most do not have a full solution, and one suggests writing directly the database tables, which I am not excited about. 

http://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/Clearpass-rolling-expiry-timers/td-p/137181

I was hopeful I could accomplish this with an enforcement profile.  There is a 'ClearPass Entity Update Enforcement' of:

Type: Expire-Time-Update
Name: GuestUser

Is my goal the intent of this attribute?  If so, can someone assist me with the proper value syntax?

I have also attempted by creating a dictionary attribute in CPPM for the expire_time field from entity GuestUser and manipulating it via an enforcement profile with no good results. 

If anyone knows another/better approach to this solution, please direct me.

Thank you in advance.