Security

I am relatively new to CPPM and have been doing a lot of research and labbing in order to understand the architecture and configuration as best as I can. The one thing that I cannot determine through the aforementioned is best practices. Specifically, I would like best practices on how everyone categorises/organises their service list. I have done some research and have come across an old community post, which was great - it provided me with a list that I took as best practice. Below is the list I found

• 802.1x wireless
• 802.1x wired
• MAC auth wired 
• Guest registration (Radius)
• Guest MAC auth
• Wireless MPSK 

But the question that is bugging me is why? In theory, and correct me if I am wrong, you could lump wired and wireless into the same service and make highly granular service conditions and policies right? Is there something my uneducated mind is missing or is it simply for organisational purposes so we do not have services with rows upon rows of conditions?

Also is this a good general best practice list for a service set or are there others you've seen out in the wild within customer environments?

You could technically lump them together, and you'd regret it the first time something breaks. Service selection is first match, top down, so one giant service means every condition and every role-mapping rule gets evaluated for every request type, and troubleshooting turns into reading a wall of rules trying to work out which branch a client took.

Separate services keep the blast radius small. Wired and wireless usually want different enforcement anyway, different roles, different VLANs, different posture expectations, and when you split them you can change one without touching the other. Access Tracker also gets far more readable when the service name tells you what happened.

That list you found is a fine baseline. Add MPSK or Onboard services if you use those, and put your most specific services above the general ones since first match wins.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022-2023
If my post was useful accept solution and/or give kudos
------------------------------

To elaborate the answer from Dustin I normally make separate services for AOS-S and CX switches and also one service for each SSID if the customer has more than one SSID of a specific type. At least if the customer is implementing Downloadable User Roles.

So in many implementations I will get:

• 802.1x wireless SSID1
• 802.1x wireless SSID2
• 802.1x wired AOS-S
• 802.1x wired CX
• MAC auth wired AOS-S
• MAC auth wired CX
• Guest registration (Radius) wireless
• Guest MAC auth wireless
• Wireless MPSK 

To simplify administration, I have the same Role mapping policies for both AOS-S and CX switches. One for MAC auth and one for 802.1x. The 802.1x may also be useful for 802.1x wireless depending on how implementation is done.

It's possible to have same services for both AOS-S and CX, but as AOS-S and CX are listed under different vendors (Hewlett Packard Enterprise and Aruba respectively) and are using different attributes för dynamic authorization (CoA) it's preferred to have separate service to be able to send correct dynamic authorization attributes. With the same service the enforcement policy will be harder to maintain. On the other hand separate services and enforcement policies for AOS-S and CX will get two policies to update.

You will have pros and cons with both options. In the end it's more the way of working, personal preferences etc that will lead to the final design choice.

As a general advice, ClearPass doesn't have a rollback feature for configuration changes. When I have to do changes in configuration I always work with version numbers on the objects I update. In the names of the each policy I append a version number. Like "Wired 802.1x role mapping v1.5" 

This way I can copy version 1.5 to version 1.6, do the updates. This can be done before the actual change, as the service is still configured with the 1.5 version. When all config is done the service is updated to the new version.

This gives me the option to roll back a configuration in a very easy and controlled way.

Keep in mind to also implement a clean up routine, I have come to do this by tagging obsolete objects with a tag, like 2026Q3 in the description. 
This way I can plan for a quarterly clean up task and delete all objects with this specific task.

------------------------------
Best Regards
Jonas Hammarbäck
MVP Guru, ACEX, ACDX #1600, ACCX #1335, ACX-Network Security
Aranya AB
If you find my answer useful, consider giving kudos and/or mark as solution
------------------------------

Original Message:
Sent: Aug 03, 2026 01:33 PM
From: DB86
Subject: ClearPass Service Organisation

You could technically lump them together, and you'd regret it the first time something breaks. Service selection is first match, top down, so one giant service means every condition and every role-mapping rule gets evaluated for every request type, and troubleshooting turns into reading a wall of rules trying to work out which branch a client took.

Separate services keep the blast radius small. Wired and wireless usually want different enforcement anyway, different roles, different VLANs, different posture expectations, and when you split them you can change one without touching the other. Access Tracker also gets far more readable when the service name tells you what happened.

That list you found is a fine baseline. Add MPSK or Onboard services if you use those, and put your most specific services above the general ones since first match wins.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022-2023
If my post was useful accept solution and/or give kudos
------------------------------

I do things a bit different for our own vs what I would do for customers in the past. The general idea for someone that is new to product is to create individual items to make it easier to fix when a problem occurs. KISS = keep it simple stupid. 

I have created services that are used for labels. I logically group mine together. The order of operations does not matter in this specific case if you use enough logic. Like others mentioned they do go top down. I do share my role mapping across all 802.1x or mac auth services. I also share my enforcement across all 802.1x or mac auth services. I would generally not suggest to perform evaluate all on enforcement as its much more complex. 

The mac auth service I use is for guest and corp. The corp service is the same for 2930F, 6200, AOS GW set as untrusted interface, AP's doing mac-auth. I personally don't want to manage different enforcements when I have around 50+ possible rules in the enforcement policy. The only reason for a different service in my case would be to turn on authorization or to turn it off. I update endpoint attributes in one service so they can exist in a service that is higher up in the list. I have used different NAS-ID's for different environments to match services. 

I also have around 10+ services that are used for mgmt purposes on devices. The other general suggestions is to perform authorization on role mapping. You can perform authorization on enforcement policy rules, but its much easier to do it in role mapping and apply a role based on your logic. 

If you decided to lump things together, you can create device groups that are either static or regex. These device groups can be applied to enforcement profiles. When the NAD IP matches the device group, the radius attributes will be returned. You can have the same rule for wired or wifi but different enforcement profiles that have different device groups. This way those radius attributes will not be returned to the wrong device. This can also make things more complicated and this is why its easier to start off with isolated configs. 

Another suggestion I have is if you use AD with LDAP. Keep in mind that a machine host will work on the user LDAP just fine. You may not get all the attributes that LDAP may return for a machine under the user query. I used to create 2 different auth sources and use role mapping to force that specific query. in this example the role is applied to 2 different services. Each service performs authorization only for user vs machine. The service catagorization logic can be adjusted to look for user vs machine auth.  The examples below are only it quotes for this forum. By adding enough logic, you can force the type of users to that service regardless of order of operations. On the user service then you would link the user authorization; on the machine service you would link the machine authorization. 

- User Service - 

Radius:IETF User-Name "not-begins-with"  "host\"

- Machine Service - 

Radius:IETF User-Name "begins-with"  "host\"

I am not sure if this reply will be received by all commentors, but I wanted to reply to the most recent rather than to each comment, to just say thank you to all who have took their time to write a response. Each person has provided value in their own unique way and I could not have expected better answers than what I have received. I think I have more than I need now to understand the best approaches and the mindset to employ when designing and implementing services.

Regarding the marking of a best answer, because every response is the best in it's own respect as each comment provides something different, I would want to mark all three as the best, however, I am not sure if this is possible/best practice. Thus, instead, I have left a kudos for each answer.

Thank you all once more!

Original Message:
Sent: Aug 04, 2026 10:42 AM
From: JK-90898a
Subject: ClearPass Service Organisation

I do things a bit different for our own vs what I would do for customers in the past. The general idea for someone that is new to product is to create individual items to make it easier to fix when a problem occurs. KISS = keep it simple stupid. 

I have created services that are used for labels. I logically group mine together. The order of operations does not matter in this specific case if you use enough logic. Like others mentioned they do go top down. I do share my role mapping across all 802.1x or mac auth services. I also share my enforcement across all 802.1x or mac auth services. I would generally not suggest to perform evaluate all on enforcement as its much more complex. 

The mac auth service I use is for guest and corp. The corp service is the same for 2930F, 6200, AOS GW set as untrusted interface, AP's doing mac-auth. I personally don't want to manage different enforcements when I have around 50+ possible rules in the enforcement policy. The only reason for a different service in my case would be to turn on authorization or to turn it off. I update endpoint attributes in one service so they can exist in a service that is higher up in the list. I have used different NAS-ID's for different environments to match services. 

I also have around 10+ services that are used for mgmt purposes on devices. The other general suggestions is to perform authorization on role mapping. You can perform authorization on enforcement policy rules, but its much easier to do it in role mapping and apply a role based on your logic. 

If you decided to lump things together, you can create device groups that are either static or regex. These device groups can be applied to enforcement profiles. When the NAD IP matches the device group, the radius attributes will be returned. You can have the same rule for wired or wifi but different enforcement profiles that have different device groups. This way those radius attributes will not be returned to the wrong device. This can also make things more complicated and this is why its easier to start off with isolated configs. 

Another suggestion I have is if you use AD with LDAP. Keep in mind that a machine host will work on the user LDAP just fine. You may not get all the attributes that LDAP may return for a machine under the user query. I used to create 2 different auth sources and use role mapping to force that specific query. in this example the role is applied to 2 different services. Each service performs authorization only for user vs machine. The service catagorization logic can be adjusted to look for user vs machine auth.  The examples below are only it quotes for this forum. By adding enough logic, you can force the type of users to that service regardless of order of operations. On the user service then you would link the user authorization; on the machine service you would link the machine authorization. 

- User Service - 

Radius:IETF User-Name "not-begins-with"  "host\"

- Machine Service - 

Radius:IETF User-Name "begins-with"  "host\"

Hi.

You are right. All answers are great (I add a kudos). 

There are some technical limitations as mentioned already. If you need Dynamic Authorization aka CoA, then you need to have separate service for each CoA environment. In practice this means separate service for each OS/technology...

You can aggregate in Role Mapping and in Enforcement Policy. Service itself is easy to create and maintain. The real work is in Role Mapping Policy and Enforcement Policy. Create device groups to consolidate same technology. Then use these groups in Enforcement Profiles to select appropriate action regardless of underlying OS. You can use many Enforcement Profiles in the same action.

For example you can have Enforcement Profile for CX switch that send attribute Aruba-User-Role when switch IP is in ArubaCX group, and send HPE-User-Role when switch IP is in ArubaOS-S group. Or send IETF attributes for vlan change if switch is from some other vendor.

A lot depend on your personal preferences. You will find what is comfortable to your way after some deployments.

Personally I'm using separator dummy service to distinguish between different service types. I see this in one of Herman's videos many years ago.

It also helps if you stick to consistent naming convention for all components (Roles, enforcement Profiles, policies,...).

If you are using wizards to create services, you can adopt this naming convention.

Best, Gorazd

 

------------------------------
Gorazd Kikelj
MVP Guru 2025
------------------------------

Original Message:
Sent: Aug 05, 2026 04:30 AM
From: EM-YnA358
Subject: ClearPass Service Organisation

I am not sure if this reply will be received by all commentors, but I wanted to reply to the most recent rather than to each comment, to just say thank you to all who have took their time to write a response. Each person has provided value in their own unique way and I could not have expected better answers than what I have received. I think I have more than I need now to understand the best approaches and the mindset to employ when designing and implementing services.

Regarding the marking of a best answer, because every response is the best in it's own respect as each comment provides something different, I would want to mark all three as the best, however, I am not sure if this is possible/best practice. Thus, instead, I have left a kudos for each answer.

Thank you all once more!

Original Message:
Sent: Aug 04, 2026 10:42 AM
From: JK-90898a
Subject: ClearPass Service Organisation

I do things a bit different for our own vs what I would do for customers in the past. The general idea for someone that is new to product is to create individual items to make it easier to fix when a problem occurs. KISS = keep it simple stupid. 

I have created services that are used for labels. I logically group mine together. The order of operations does not matter in this specific case if you use enough logic. Like others mentioned they do go top down. I do share my role mapping across all 802.1x or mac auth services. I also share my enforcement across all 802.1x or mac auth services. I would generally not suggest to perform evaluate all on enforcement as its much more complex. 

The mac auth service I use is for guest and corp. The corp service is the same for 2930F, 6200, AOS GW set as untrusted interface, AP's doing mac-auth. I personally don't want to manage different enforcements when I have around 50+ possible rules in the enforcement policy. The only reason for a different service in my case would be to turn on authorization or to turn it off. I update endpoint attributes in one service so they can exist in a service that is higher up in the list. I have used different NAS-ID's for different environments to match services. 

I also have around 10+ services that are used for mgmt purposes on devices. The other general suggestions is to perform authorization on role mapping. You can perform authorization on enforcement policy rules, but its much easier to do it in role mapping and apply a role based on your logic. 

If you decided to lump things together, you can create device groups that are either static or regex. These device groups can be applied to enforcement profiles. When the NAD IP matches the device group, the radius attributes will be returned. You can have the same rule for wired or wifi but different enforcement profiles that have different device groups. This way those radius attributes will not be returned to the wrong device. This can also make things more complicated and this is why its easier to start off with isolated configs. 

Another suggestion I have is if you use AD with LDAP. Keep in mind that a machine host will work on the user LDAP just fine. You may not get all the attributes that LDAP may return for a machine under the user query. I used to create 2 different auth sources and use role mapping to force that specific query. in this example the role is applied to 2 different services. Each service performs authorization only for user vs machine. The service catagorization logic can be adjusted to look for user vs machine auth.  The examples below are only it quotes for this forum. By adding enough logic, you can force the type of users to that service regardless of order of operations. On the user service then you would link the user authorization; on the machine service you would link the machine authorization. 

- User Service - 

Radius:IETF User-Name "not-begins-with"  "host\"

- Machine Service - 

Radius:IETF User-Name "begins-with"  "host\"