Security

Recently, I’ve been with enterprise clients that are looking to restrict their wireless and wired 802.1x sessions to valid domain devices that users log into. In terms of authenticating a Windows client, you can limit secure access to a Machine Authentication OR a User Authentication in Windows. These enterprise clients are looking for valid domain machines and providing elevated rights on a per-user level on non-BYOD devices.

Clearpass allows us to combine a Machine Authentication AND User Authentication to guarantee that the connecting device is a member of the domain while still providing per-user roles and ACLs.

 

The following was completed using Clearpass 6.4.1,a Windows 2012 backend, a 7005 running 6.4.2.2, and an AP-225.

From a high level, here's what I will be discussing:

 

1. We will create a Boolean Clearpass Endpoint Attribute

2. We will create an Enforcement Profile that sets the Endpoint Attribute

3. We will then apply that Enforcement Profile to a successful Machine Authentication in an Enforcement Policy

4. We will create a Clearpass Role to reference this Endpoint decision

5. We will adjust the existing Enforcement Policy and combine the Machine Authenticated Clearpass Role and the User Authentication

6. We will talk about how to roll this out in an enterprise environment

7. Troubleshooting and verification of this design

8. Caveats to this design

 

1. Creating a custom Clearpaass Endpoint Attribute

 

The first step is to create a custom Clearpass Endpoint Attribute. In Clearpass, go to the following:

 

i. Administration > Dictionaries > Attributes

ii. Click the "+Add" button in the top right-hand corner

iii. Fill in the attribute similar to the following screenshot:

 

 

Make sure the "Entity" is set to "EndPoint" and to select "No" for "Is Mandatory" and "Allow Multiple."

 

iv. Click the "Save" button

 

2. Creating an Enforcement Profile

 

Next, we are going to create an Enforcement Profile to set our newly created Endpoint Attribute.

 

i. Go to Configuration > Enforcement > Profiles

ii. Click the "+Add" button in the top right-hand corner

iii. Go to "Template" > "Clearpass Entity Update Enforcement"

iv. Click "Attributes" > "Type" > "Click to add..."

v. Type = "Endpoint" : Name = <Name that you provided in the previous example> : Value = Checked Box / "true"

 

A successful configuration of the Attributes section will look like the following:

 

 

Here's a summary of this Enforcement Profile:

 

 

3. Modifying the Enforcement Policy

 

The third step is to add the newly created Enforcement Profile to an Enforcement Policy. The easiest way to do this is to go to the wired or wireless service and select the Enforcement Policy. In this example, I will apply this to an 802.1X wireless service.

 

i. Go to Configuration > Services > "Your 802.1X wireless service"

ii. Click on the "Service" tab and select "Authorization" (if it's not already selected)

iii. Click on the "Authorization" tab

iv. Select "Endpoints Repository" from the "Additional authorization sources..." (if it's not already selected)

v. Click on the "Enforcement" tab

vi. Click on the "Modify" button to the right of the currently selected Enforcement Policy

vii. Click on the "Rules" tab

viii. Click on the "Add Rule" if you do not have a "Tips:Role EQUALS [Machine Authenticated]." 

ix. If you do have a "[Machine Authenticated" rule, click the "Edit Rule" button. Type = "Tips:Role EQUALS : [Machine Authenticated]"

x. Enforcement Profiles > Profile Names > "Enforcement Profile from Step 2" + "An appropriate Aruba User Role"

 

(An aside)

 

The user role that is given in step x. can be a quarantined role that only allows access to DHCP, DNS, and AD. It will take a user authentication for a machine to be given the proper Aruba user role and credentials.

 

(Back to business)

 

xi. Click the "Save" button

xii. Click the next "Save" button

 

An example of a successful configuration will look like the following:

 

 

4. Creating a Clearpass Role for the Endpoint Attribute

 

The next step is to create a Clearpass Role that we will tie to the Endpoint Attribute in Step 5.

 

i. Go to Configuration > Identity > Roles

ii. Click the "+Add" button in the top right-hand corner

iii. Create a role similar to the following screenshot:

 

 

iv. Click the "Save" button

 

5a. Tying together the Clearpass Role, the EndPoint Attribute, and the Enforcement Policy

 

Let's begin by going to the Role Mapping that is being employed by the wireless 802.1X service.

 

i. Go to Configuration > Services > "Your 802.1X wireless service" > Roles

ii. Click on the "Modify" button to the right of the currently selected Role Mapping Policy

iii. Click on the "Mapping Rules" tab

iv. Click on the "Add Role" button

v. Click on "Type" > "Click to add..."

vi. Type = Endpoint : "Attribute from Step #2" : EQUALS : true

vii. Actions > Role Name > "The Clearpass Role created in Step 4"

 

The above steps will look similar to the following screenshot:

 

 

(Aside)

 

You may be wondering what's up on line #12 in the above graphic. A device will receive the default role from a role mapping policy if it does not match any of the conditions. Often, I create a "Deny All" role in Clearpass to anything that does not match. The problem is that a "[Machine Authentication]" is defined in the Enforcement Policy, not in the Role Mapping. By doing something similar to line #12, you'll guarantee that Access Tracker will not set the default role mapping to this connection, on-top of the "[Machine Authentication]"

 

(Back to business)

 

5b. The next step is to tie together everything we've done in the Enforcement Policy definitions.

 

i. Click on the "Enforcement" tab

ii. Click on the "Modify" button to the right of the currently selected Enforcement Policy

iii. Click on the "Rules" tab

iv. Click on the "Edit Rule" on your currently defined 802.1X wireless enforcement profiles.

v. Adding the following to these definitions, Type = Tips : Role EQUALS : "Clearpass Role defined in Step 4"

 

This will look similar to the following screenshot:

 

 

The above definition states that you need to have User credentials AND the device that you're authenticating with must have Machine Authenticated at some point. Make sure to select ALL in the rule definition, rather than ANY. The above should be an "AND", not an "OR."

 

6a. Windows wireless / wired networking settings

 

The first step in deploying this design is to make sure that your Windows clients are configured correctly. They must be setup for Machine (Computer) or User Authentication.

 

i. Either through GPO or a manual configuration, go to the properties of the wireless network:

 

 

ii. Click on the Advanced Settings > 802.1X settings > CHECK "Specify Authentication Mode" > "User or Computer Authentication"

 

 

6b. Rolling out this solution into an enterprise

 

i. The next step is probably the most important to remember about this design - the client MUST Machine Authenticate in order for this design to work. The best way to get this to happen is for a Windows client to reboot and attempt to authenticate to the network as the device itself. This will happen automatically if a Windows client is successfully configured with the above settings.

 

ii. The problem with "rolling this out on the weekend" is that not all of the devices will Machine Authenticate on Monday morning unless they're rebooted. The best thing to do is to give the users a week or two to reboot their machines and populate the Endpoints database.

 

iii. To verify the Endpoints database, go to Configuration > Identity > Endpoints > Filter on "Attribute" > contains > "The attribute from Step 2." You can then compare the hostnames in this section to the Computers OU in your AD directory. This will help you to be proactive with your users and remotely reboot the hostnames that are not in the Endpoints database.

 

iv. Finally, you will enable the Role as part of the decision process, as in step 4.x.

 

7. Troubleshooting and verifying this design

 

i. Here is a screenshot of the design successfully working:

 

 

ii. Let's look at a screenshot of entry #2 in Access Tracker:

 

 

This device is doing [Machine Authentication] and using the "host\" format as the username.

 

The first "Enforcement Profiles" for this connection is the Profile that we created in Step 2.

 

iii. Let's look at a screenshot of the Output tab to see what that Enforcement Profile is doing:

 

 

Under the "RADIUS Response" we see that we are settings the "Endpoint:ToP-Machine-Auth-Device" to equal "true" - this is exactly what we're expecting!

 

iv. Next, let's examine Access Tracker #1 from step 7.1. This occurs when you hit "CTRL+ALT+DELETE" and log in with domain credentials. Let's take a look at this screenshot:

 

 

Here we see that I'm logging in with my AD username in the "DOMAIN\username" format. I'm also now categorized as a "ToP-Domain Device" that we defined in Step 4. The main thing to notice is that the "Enforcement Profiles" for this connection are much different than the last authentication. This allows us to log into this Machine Authenticated domain device AND provide granular user authentication.

 

v. Let's verify that the Endpoint Attribute has been set. Click on Input > Computed Attributes and scroll all the way to the bottom. You will see the Endpoint Attribute set, similar to the following screenshot:

 

 

vi. Finally, click on the Output > RADIUS Response:

 

 

Here we can see that I'm setting an Aruba user role that provides administrator access. This is different than the user role that was set on a Machine Authentication. We're now providing granular user access to this connection.

 

We've designed a solution that provides Machine Authentication AND User Authentication!

 

8. Caveats

 

i. The first caveat to this guide is that it leaves out Apple Mac devices. The enterprises that have wanted this type of configuration have not had large Mac deployments. They have gone into the Endpoint repository, find the specific wireless or wired MAC, and then manually select the Endpoint Attribute.

 

ii. The second caveat is that you may want to purge the Endpoints database every 6 months or so to make sure that all of the devices that are connecting to the network are still valid AD domain machines. One would work through the steps in section 6b., in reverse. First, you would remove the Endpoints Attribute from the decision process in the Enforcement Policy. Then, you would allow a week or so to pass; the domain machines will re-populate the Endpoints database in Clearpass. At that point, you could once again add the Endpoints Attribute to the wireless or wired decision process in the Enforcement Policy.

 

Thanks for taking the time to read through this "How-to." I hope that you were able to get something out of this advanced Clearpass configuration.

 

Let me know if there are any questions or follow-ups - I would love to hear them!

 

Thanks!

 

-Mike

#7005

This was great!

Hi Mike,

Great guide, thank you. Am I correct in assuming you would have to manually set this attribute per client, as they join the wireless network and are profiled? The reason I ask is because, in my environment, we don't have an Aruba Wireless Controller (we use Cisco Meraki APs which pass RADIUS traffic to Aruba CPPM). So, maybe there's a way to do this automatically using Aruba, end-to-end, but not in our scenario.

Also, on line 12 of your screenshot, in step 5a.vii, you have Role listed called "ToP-Machine-Auth". Is this role mapping doing anything, aside from avoiding the "Deny All" role mapping issue that you mentioned in this step?

Lastly, you mention several roles in step 5b.v: ToP-Admins and ToP-Regular-Users. Are these roles mapped within CPPM, or are they somehow passed from the Aruba Wireless Controller?

(Forgive my ignorance with these questions, please. I'm pretty new to CPPM still and have never even seen the GUI for Aruba's Wireless Controller.)

Many thanks for your help in advance.

Hi CrescentWire,

 

No, you do not have to manually set this per client. The magic that makes this work is found in steps 3.IX and 3.X. The logic is as follows:

 

If a endpoint is performing a [Machine Authentication] -> Set an enforcement profile that will sets the attribute from Step 2. 

 

This attribute, in here called ToP-Machine-Auth-Device, is then used as part of the decision process. (btw, ToP stands for "Tower of Power", the tongue-and-cheek name for the lab in my house)

 

The next part of the logic works like this:

 

If the MAC address of an endpoint has the attribute of ToP-Machine-Auth-Device set to True AND the authentication is a [User Authentication] -> Allow them on the network.

 

The logic here is that a user is authenticating with a valid AD account on a machine that has performed machine authentication, because we are checking to see if ToP-Machine-Auth-Device is True. This is a fancy way of saying the user is auth'ing on a domain device. 

 

The ToP-Admins and ToP-Regular-Users are just some things that I came up with on the Role Mapping tab. To be honest, over the past year I've gotten out of this habit. The way this would look now for me would be:

 

ToP-Machine-Auth-Device = TRUE

AND

AD Group = "ClearPass-Admins" (or whatever)

 

On the Role Mapping tab you can a line that states:

 

AD Group = "ClearPass-Admins" -> SET ROLE -> CPPM-ADMINS

 

Then, in the Enforcement Policies, you can have a statement that reads:

 

ToP-Machine-Auth-Device = TRUE

AND

TIPS - ROLE = CPPM-ADMINS

 

The roles in the above would be defined in the Role Mapping tab. I think it's a little more than most people feel comfortable with and it's now easier to put the AD groups in the Enforcement Policy, instead.

 

Let me know if there are any follows up - thanks!

 

-Mike

 

Thanks very much for the detailed response, Mike. I just have two more questions I'm hoping you can shed some light on:

 

Suppose there is a computer that has never joined the network before (it does not have the Boolean Attribute set to "true"). Now, for this computer to successfully join the network, there has to be some "validation" (or check, as it were) that tests some condition in order to grant access (or apply a profile). Given your approach, how would this new computer join the network? It seems that the only way would be to manually set this attribute to "true", so that next time, the role mapping policy assigns the proper role, which assigns the proper profile (via the policy). I fully understand that the profile sets this attribute to "true", but that only permits the same device to join the network in the future based on this attribute being set to "true". If it seems like I'm locked in a mode of circular logic here, well ... it's because I am. I just can't seem to understand how a new device, joining the network for the first time, would successfully receive the right profile (which then, of course, sets the attribute to true).

 

The other question I had relates to identifying a hostname and comparing it to AD. Obviously your guide involves user and machine auth, but suppose we wish to check whether or not an authenticating machine's hostname exists in AD, and is a member of a specific AD group. (If this is true, then the machine is granted access via some profile, combined with a separate "flow" of logic that handles user authentication). In our testing, we've gotten as far as profiling the device and being able to search based on the Microsoft "cn" attribute (for hostname) in Active Directory. But, we haven't found a way to use this "discovered" data in the endpoint profile for performing a lookup in AD to confirm object group membership. I realize this is a pretty advanced scenario, so please don't hesitate to tell me, "talk to support." I'm planning on opening a case with them also. But, since you have a lot of experience with CPPM in this vein, I figured I'd ask you as well.

 

Thanks once again for your assistance. It's greatly appreciated.

 

Hi crescentwire,

 

There are a couple of things that you can do to help onboard a new device. You can use ClearPass' MACTrac feature to whitelist a MAC address for a small space of time. I wrote a piece on it here at this link:

 

http://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/How-To-Advanced-MACTrac-designs-in-ClearPass-November-MHC/m-p/217291/highlight/true#M16687

 

To follow up on the second question, are you trying to see if a device is a Computer object AND is in a specific group? Or, are you looking to just see if a device is in AD? If it's the later, then all you have to do is check to see if is performing a Machine Authentication.

 

-Mike

Hi Mike,

 

Thanks for your response. I'll take a look at the MACTrac feature/article you put together. Many thanks for that.

 

In answer to your question, we are trying to affirm that the Computer (1) exists in AD, AND (2) is a member of a specific AD group. Only then should the computer (along with the user authentication "piece" of this process) be permitted access to join our wireless network. Hopefully this makes sense.

 

Thanks again for your ongoing assistance with this.

Hi crescentwire,

 

The one thing I'm still not sure about is when you say that the Computer must be part of a specific AD group. Have you seen that information as part of the Authorization Attributes in Access Tracker? If so, could you post a screenshot?

Thanks!

 

-Mike

Well, that's just it ... I haven't. And, I'm really not sure how to even pull that information from anywhere. I can fairly-easily fumble my way through comparing that data to a valid entry in AD, as a member of a group, etc, using CPPM's role mapping features, but as far as finding that infromation, up-front ... yes, that's the challenge.

 

The way that I'm approaching this is, if I just had the hostname passed to CPPM (visible somewhere within the Access Tracker's messages), then I could use that as my "test variable" to then see if it resides in AD, in a specifc group. I know that I won't find group membership data within Access Tracker, but at the very least, having a hostname would let me use that as my input variable for checking whether or not the computer exists in AD, and is a member of a specific group.

 

Does that make sense?

The hostname is available during the machine authentication. You'd have to
write that value to the endpoints repository and then use a custom SQL query
to query the machine account's properties during the user authentication.

I think we can accomplish this by using Auth Only Onguard Agent. Set the 1x to authenticate using Machine. Put it in Quarantine. The let OnGuard Agent tied to Windows Logon do the user Auth without do any posturing. The caveat is we will need agent installed in the machine. Anyway, just idea...not even tried by myself.

Mike,

 

I was trying to followthe instructions on setup of Machine Authentication but got lost at Section 3 step viii.   Unable to find role EQUALS :{Machine Authenticated}, using 6.5.5 Cleapass which is a little different.  Can you tell more on how to use this?

Hi James,

 

The editiing of that section was a little messed up - thanks for pointing that out!

 

First, is your ClearPass box joined to an AD domain? If so, can you select a type of Tips from your enforcement policy? If so, you should be able to select Tips - Role - EQUALS - [Machine Authenticated]

 

-Mike

 

Mike,

still could not find the TIPS: action of machine authentication. I picked
these settings.

Hi James, 

 

See this screenshot:

 

Hope it helps!

 

-Mike

Hi Mike, I'm trying to understand the need to set the domain authenticated status of the device in the Endpoints Repository DB. Is it to overcome the cache age out for the Tips Role [Machine Authenticated]?

 

Yes, but now we have an independent machine cache. This article is a bit dated.

Hi Tim, do you have details for this new cache? Can we use it in Enforcement Policy rules?

It's the same TIPS role, it just has an independent lifetime from regular policy cache.  You can configure it under server config, service parameters.

Hi Tim,

I see the max value for the machine authentication timeout is 1000 hours (~41 days). We're currently manually setting endpoint attributes that are valid for 1 week but we'd like to extend that time. Is it very detrimental to Clearpass performance to increase the machine authentication timeout to something like 720 hours (30 days)? This would simplify administration if we could remove the workarounds we are doing to trust devices for longer than 24 hours. Thanks in advance!

No, there are no performance implications.

---

@go_buckeyes wrote:

Hi Tim,

I see the max value for the machine authentication timeout is 1000 hours (~41 days). We're currently manually setting endpoint attributes that are valid for 1 week but we'd like to extend that time. Is it very detrimental to Clearpass performance to increase the machine authentication timeout to something like 720 hours (30 days)? This would simplify administration if we could remove the workarounds we are doing to trust devices for longer than 24 hours. Thanks in advance!

---

Quite frankly, the machine authentication cache on ClearPass is reset every time a user or machine authentication occurs.  If a device machine authenticates successfuly, any time within the cache timeout that a user authenticates successfully resets the cache.  This means that after the initial authentication, any successful authentication for that mac address will reset the cache, not just a machine authentication.  You should not have the need to have a super-long cache, in that circumstance.

 

I was just told that this statement is not true...

This statement is true.

Thanks Tim and Colin. Our main issue now is users that are docked/wired 95% of the time and only undock to go to a meeting (might happen say every 2 weeks). These people may never come into work and be at the logon screen when they're not on the wire. Our thinking and fear was that eventually they would undock to run to an important meeting but no longer be machine authenticated, therefore unable to authenticate successfully - causing frustration. The workaround we implemented (manually setting attributes and expiry times) works but feels kludgy. If we can set machine authentication to 30 days AND that machine authentication gets update everytime they user authenticate (assuming they're in the 30-day period) that sounds amazing.

 

I know how to clear the machine authentication cache via the GUI, however is there a way to view the cache for verification? Thanks again guys you have been very helpful (in this post and many others)!

For those users, their Windows supplicant should be configured for Machine Authentication only.

To be clear, this should be tested in the lab.  The only authentication that will be seen is the user's wireless machine authentication, so that should be allowed full access to the network.

Thanks again, I have tested machine only authentication on a device that doesn't get the normal group policy and it authenticates and is allowed access as anticipated. However, I don't have buy-in to have separate wireless policies for different groups of domain devices. Unfortunately, the problems we face are not always technical in nature.

With the configuration of the Windows wireless "Security type:" is set to "WPA2-Enterprise".  Why is it not set to "802.1x"

 

 

 

 

Hi,

I tried this configuration for the machine and user authentication for wireless 802.1x authentication with ClearPass. It looks like somewhere I did the mistake in the configuration. Can you please look into the configuration which is attached and suggest to achieve both machine and user authentication. Is it required to enable enforce machine authentication on Aruba Controller. Please suggest.

Note: We deployed a group policy to manually connect the wireless network instead of auto-connect to the wireless network.

 

Thanks,

Yugandhar.

This is the best guide on configuring ClearPass on the entire Aruba website. Straight forward and well explained. Great job!