Security

I've inherited the ClearPass server for one of our customers set up by a colleague who has resigned. I've been experiencing issues with the way the services are laid out. 

Essentially, there is a separate service for each authentication method. Each with their own role mappings and enforcement profiles. For example:

• Intune Machine Authentication | EAP-TLS
• Intune User Authentication | EAP-TLS
• JamfSchool iPads | EAP-TLS
• JamfPro iPads | EAP-TLS
• AD Staff User | PEAP
• AD Student User | PEAP
• Devices | MPSK

When I compare this to another customer we recently onboarded, their previous IT manager had set the server up, and they have the services set up per SSID, with all authentication methods available, and a single role mapping and enforcement profile each. For example:

• SchoolName - Mobility | EAP-TLS, PEAP
• SchoolName - Guest | PSK with Captive Portal
• SchoolName - Devices | MPSK

My main question is, which is best practice? The latter seems much easier to manage to me, as I only need to add service filters for the SSID name, then perform all authorisation based on the authentication method and endpoint data after authentication has complete.

For the former, it was set up in the service filters that SSID is the relevant SSID (seems like duplication to me) the endpoint source must match the MDM. This is causing issues with user authentication of managed devices, as the machine auth cache expires after 24 hours. 

I am proposing implementing TEAP for this customer to resolve the MDM user authentication issues (Plus streamline the initial certificate issuing experience). However, should I also look at auditing their existing configuration and consolidate them to one service per SSID? One concern I have is that students and staff are in different AD domains. The student domain is a child domain of the staff domain, so will the student users be able to authenticate against the staff domain if I set them up as one source?

Depends on the use-case.  Typically I also organize from most hits to least hits to speed up processing time.  

In your case I would organize based on SSID and/or auth method.  One service for wired EAP-TLS, one for wireless EAP-TLS.  One service for Guest.  One service for MAB, etc. etc

Depends on the use case.

Usually it's by SSID, then Switch type with each auth type (802.1x / MAC / Captive Portal) of the same switch type.

If there's no reason to break them up, then don't it's just more stuff to have to click through when it comes to troubleshooting / maintaining. 

But that can change if you have to strip the domain from some usernames but not others (such as eduroam with AD) or if you have a really long enforcement policy that is better broken up into multiple enforcement policies for readability / manageability.

Dummy Services for spacing are nice for readability, service name something like -------------Wired Auth------------.

Just make sure they can never match since it's really easy to enable the service with an errant click. I like MAC address equals and MAC address not equals the same value; Leave the service disabled, but if it gets clicked you're not nuking your network.  

I've found that the most important best practice is consistent naming convention.

In general terms I usually implements customer with as few services as possible and try to have the one role mapping policy for all 802.1x services and one role mapping policy for all MAC auth services.

In most cases the base services are:

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

For 802.1x I usually have all needed authentication methods in the same service.

If you have a distributed environment with local ClearPass servers in several countries and AD domain controllers in the same sites, you also need separate LDAP sources for each of the sites, and also a separate 802.1x service for each country with the LDAP source for this specific country. Otherwise you can't control how ClearPass connects to LDAP.

In networks with multiple switch families or brands you may also have to implement services with the specific CoA settings in the Profiling tab for each switch type..

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

@jonas.hammarback @mholden

Thank you both. This is valuable insight. Seems like my predecessor didn't do us any favours they way he has set this up. A lot of the services are relying on ClearPass to match the device prior to the authentication phase (e.g. Device source equals Intune/JamfPro, etc). This, to me, seems unreliable. Instead, this should be evaluated during authorisation, as you will then have all information required for the device or user, since that will be contained in the authentication request, or can be queried easily. Querying during the service filter seems quite difficult, which is where I've been running into diffculties.

As an aside, have either of you used EAP-TEAP? If so, what was the experience? Did it improve user authentication, especially in cases where the machine authentication cache has expired for that particular device? For context, the student users rarely log out of their managed laptops, let along restart them. Bad practice, but they are not my responsibility, unfortunately. I have proposed TEAP to streamline the process, plus revising their services to better meet best practices.

Original Message:
Sent: Feb 08, 2024 09:48 AM
From: jonas.hammarback
Subject: ClearPass: How are you organising your services?

In general terms I usually implements customer with as few services as possible and try to have the one role mapping policy for all 802.1x services and one role mapping policy for all MAC auth services.

In most cases the base services are:

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

For 802.1x I usually have all needed authentication methods in the same service.

If you have a distributed environment with local ClearPass servers in several countries and AD domain controllers in the same sites, you also need separate LDAP sources for each of the sites, and also a separate 802.1x service for each country with the LDAP source for this specific country. Otherwise you can't control how ClearPass connects to LDAP.

In networks with multiple switch families or brands you may also have to implement services with the specific CoA settings in the Profiling tab for each switch type..

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

Yes TEAP works great in my experience.  It doesn't necessarily "improve" auth from a properly deployed EAP-TLS or PEAP deployment but it does add the additional "Factor" and visibility into both machine and user states.

If you use TEAP with PEAP inner method you will still see the machine auth cache expired issue.  You would use TLS as an inner method and use certificates instead for both machine and user auth.

Original Message:
Sent: Feb 08, 2024 03:26 PM
From: MatazaNz
Subject: ClearPass: How are you organising your services?

@jonas.hammarback @mholden

Thank you both. This is valuable insight. Seems like my predecessor didn't do us any favours they way he has set this up. A lot of the services are relying on ClearPass to match the device prior to the authentication phase (e.g. Device source equals Intune/JamfPro, etc). This, to me, seems unreliable. Instead, this should be evaluated during authorisation, as you will then have all information required for the device or user, since that will be contained in the authentication request, or can be queried easily. Querying during the service filter seems quite difficult, which is where I've been running into diffculties.

As an aside, have either of you used EAP-TEAP? If so, what was the experience? Did it improve user authentication, especially in cases where the machine authentication cache has expired for that particular device? For context, the student users rarely log out of their managed laptops, let along restart them. Bad practice, but they are not my responsibility, unfortunately. I have proposed TEAP to streamline the process, plus revising their services to better meet best practices.

Original Message:
Sent: Feb 08, 2024 09:48 AM
From: jonas.hammarback
Subject: ClearPass: How are you organising your services?

In general terms I usually implements customer with as few services as possible and try to have the one role mapping policy for all 802.1x services and one role mapping policy for all MAC auth services.

In most cases the base services are:

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

For 802.1x I usually have all needed authentication methods in the same service.

If you have a distributed environment with local ClearPass servers in several countries and AD domain controllers in the same sites, you also need separate LDAP sources for each of the sites, and also a separate 802.1x service for each country with the LDAP source for this specific country. Otherwise you can't control how ClearPass connects to LDAP.

In networks with multiple switch families or brands you may also have to implement services with the specific CoA settings in the Profiling tab for each switch type..

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