Security

Hello,

 

I'm currently working on setting up user and machine authentication for a customer following this post:

http://community.arubanetworks.com/t5/Security/How-to-MACHINE-AND-USER-AUTHENTICATION-IN-WINDOWS-WITH-CLEARPASS/td-p/227580

 

I'm confused with some of the components that are mentioned which I can't find in the documentation:

 

• What is the logic behind CPPM assigning [Machine Authenticated ] and [User Authenticated] roles? What does CPPM check and how does it decide to assign these roles in an incoming RADIUS request?

The [Machine Authentication] role is pre-defined and will be mapped when a
computer account successfully authenticates to the domain.

Thanks Cappalli,

 

I'm also trying to understand the enforcement profile which checks for both [machinie auth] and [user auth] roles to be assigned to the requests. I've tested this with domain/useraccount and it works OK (I can see both roles assigned in access tracker), I just don't understand how this works. Shouldn't the [user authenticated] role be returned by itself when user credenitals are authenticated to the domain? Why is the [machine auth] role also returned?

The [user authenticated] built-in role is returned when the current authentication being handled is passed.  [Machine Authenticated] is also returned if a device with the same mac address passed machine authentication within the "Machine Authentication Cache Timeout Period" shown below (24 hours).  Another wrinkle to this is that every time a device that has passed machine authentication passes user authentication, the cache is reset to another 24 hours or whatever the parameter is below:

You can test this by clearing the machine authentication cache to reset all devices:

 

To recap and in more detail:

Domain machines attempt machine authentication with a username of host/<machine fqdn>.  If clearpass sees a device pass authentication with that username it assumes it is a domain machine that has authenticated and adds the mac address of that device to the machine authentication cache for 24 hours or whatever that parameter is.  It also returns the built-in role of [machine authenticated].  If a user on that machine authenticates successfully via 802.1x, clearpass returns [user authenticated] and [machine authenticated] if it is within that 24 hours, every time that user authenticates.  Every time a user successfuly authenticates on a machine that is in the machine authentication cache, the 24 hours is extended.

 

It is designed this way, because by default machines only machine authenticate when they are at the ctrl-alt-delete prompt and logged out.  It is possible that a user locks his machine, and comes back 36 hours later the machine will be removed from the cache and the next user authentication will no longer have the [machine authenticated] role, because it expired.  Extending the cache for any successful 802.1x authentication with that mac address eliminates the need for a user to reboot his computer just to reflect that it is a domain machine..

 

I hope that helps...

Thanks for the detailed explanation. You say "by default machines only machine authenticate when they are at the ctrl-alt-delete prompt and logged out." Does that imply there are means/methods to alter that behavior? For example, would there be a way to force a machine to periodically reauth while a user is logged in and working? We're in the middle of testing machine+user auth but, what we're seeing is that users don't, in fact, shut down or log out without regularity and they're irked that that they can no longer sleep a device indefinitely and, instead, have to shut down all their apps to either log out or reboot. How do people typically approach this problem during a rollout? Is there a more elgant, invisible (to the user) way of handling machine auth? 

---

@asdfjkl; wrote:

Thanks for the detailed explanation. You say "by default machines only machine authenticate when they are at the ctrl-alt-delete prompt and logged out." Does that imply there are means/methods to alter that behavior?

The Windows supplicant allows you to configure it for machine authentication only (no user authentication).

For example, would there be a way to force a machine to periodically reauth while a user is logged in and working? Not with the Windows supplicant.  What is the use case?

We're in the middle of testing machine+user auth but, what we're seeing is that users don't, in fact, shut down or log out without regularity and they're irked that that they can no longer sleep a device indefinitely and, instead, have to shut down all their apps to either log out or reboot. How do people typically approach this problem during a rollout? Is there a more elgant, invisible (to the user) way of handling machine auth? They can simply extend the machine authentication parameter or store the machine authentication status in the endpoint database for later comparison (@boston1630 wrote an article about it here:  https://community.arubanetworks.com/t5/Security/How-to-Machine-AND-User-Authentication-in-Windows-with-Clearpass/m-p/208471#M15856).  Please remember that storing the machine authentication status by tying it to a mac address is something that can be spoofed.  The most secure companies use EAP-TLS with machine-only authentication without storing the machine authentication status anywhere.

---

 

Thanks @cjoseph.

Eh, frankly, most of our 'problems' ultimately stem from plunging headlong into this testing without a deep and thorough understanding of 802.1x/eap-tls at either a theoretical or practical implementation level at the Clearpass, network (wired and wireless), and endpoint levels. And some of the things we're running into are more a product of assuming something should act in a particular way without having done the research to realize otherwise beforehand. Go figure. :) 

 

But, going back to machine authentication. Yes, we're caching the machine auth for 3 days currently. Ideally, we'd like to tune that down to a shorter duration. Until now, the vast majority of our users didn't shutdown/logout daily. They'd just lock/sleep the machine indefinitely (until we push a patch/update, etc. where we might force a reboot). Admittedly, it's a hassle to shut down all your apps/programs every day in order to force the machine auth. We're a small company but, even so, if it takes even 2 minutes to fully shutdown, logout or reboot, and reopen all your apps, (and I think that's a conservative estimate) that's over 13 hours a day of idle/unproductive time across a user population of only 400 employees (2 min * 400 users = 800 min >> 13.33 hours/day). I had just assumed that Windows would perform periodic machine auths while connected to the network after a user login and perpertually refresh/extend the Clearpass machine auth timer and avoid this login 'tax'. 

 

And, not to conflate issues, we're also seeing where a user will boot up a machine while docked (i.e., connected to the wired network) and successfully perform a wired machine+user auth. However, the machine would not have performed a wireless machine auth. So, if that user undocks to, say, run off to a meeting, the machine won't connect to wireless b/c we haven't seen the wireless machine auth. So, again, they have to logoff/on or reboot. Maybe that's a GPO setting we can tweak but we have not tread down that rabbit hole yet.

 

Ultimately, we need to step back and take a more thorough assessment of what we're trying to do, get some actual training, do more research and testing but I just wouldn't have assumed things acted like this at the outset.

 

Thanks again for your input and expertise!

Are your employees a 1:1 relationship between laptops and users?  If yes, you can just make your authentication machine-only (configured in the Windows supplicant) and only have the machine login.  This will work with PEAP-mschapv2 (now insecure) and EAP-TLS.  The user can always login to the machine based on whether or not Windows allows the user to login, but the user's authentication will not go through clearpass...just the machine's authentication.  The device will never "lose" machine authentication if it only authenticates with machine credentials.  I hope that makes sense.

 

On a separate secure note, all domain computers can receive EAP-TLS certificates automatically by setting up an "autoenrollment" group policy in Microsoft Windows AD.

Thanks for the detailed explenations @cjospeh, really helped with understanding the inner workings for Clearpass back when I created this post.

 

Reading the new part of the thread some new questions have popped up in relation to the above:

 

1. When you mentioned PEAP-MSCHAP is "unsecure", is that only refering to the situation where the Windows 802.1x supplicant is not configured to validate the server certificate and isn't locked down to accept only a specific radius CN and root CA certificate? If those are all configured correctly there is no vunderability correct?

2. With EAP-TLS machine only authentication, is the only downside that CP will not have any user identitiy context during authetnicaiton? Is this circumvented by adding a username/email attirbute into the machine certificate so that it can be used for Authroization and CP can assign differnet access rights based of AD securty groups etc.? Can this be automated by GPO (to add username attirbute into computer certificate)?

3. With EAP-TLS machine and user authenitcaiton - I understand the issue is that if a user roams to a laptop that they havn't logged in before their user certificiate won't be in the laptops user certificate store and they won't be able to complete user auth. Can we use the same concept as with EAP-PEAP to give full network access to user if they complete machine authentication so they can get network 'dial-tone' and let them run login scripts, build their user profile, get their user certificate via GPO etc? Does the same MAC caching conecpt apply as with EAP-PEAP to cache the 'machine auth' status in EAP-TLS user+mach auth? Do we need to setup something else like Onboard as a intermediate CA for the Windows PKI to provide the user certificates via captive portal?

4. Finally if the network clients had the Anyconnect client isntalled to supplement the native Winodws 802.1x supplicant, would Clearpass support EAP-Chaining to combine EAP-TLS machine authentication with EAP-PEAP/MSCHAPv2 user authentication (and re-authentication) in one go?

 

Thanks in advance

1.  A misconfigured client that does not lock down which Server Certificates are Validated is the primary vector.  You should speak to your security team to ensure there are not more specific security concerns with regards to your network.  EDIT: but allowing EAP-PEAP wireless authentication means that you are allowing unmanaged clients like mobile devices also attempt to connect to the network, and have their passwords stolen, meaning there is still an attack vector that is out of your hands if you are supporting EAP-PEAP.

2.  I am not aware of a way to add a user's name to a certificate automatically.  Computers can be placed into AD groups however and that can be used to provide differing access if you need it.  A EAP-TLS computer doing machine-only authentication is the functional equivalent of having a wired computer that multiple users would login to.  If their username/password is not valid, they will not be able to get into the computer.  Group policies are applied and will work just like a wired computer.

3.  Incorrect.  With EAP-TLS machine only authentication, new users can login, because the machine gets an ip address and is connected to the domain at the command prompt.  It is functionally the same as a wired computer.  The computer has a "dial tone" at the command prompt ctrl-alt-delete screen and can be managed like a wired computer at the ctrl-alt-delete screen because it is on the network and authenticated using a machine certificate.  A user needs valid domain credentials to do anything with the machine, however.  Users will get login scripts and new users will be able to authenticate.  The chicken-and-the-egg situation would with new users not being able to login is if you use user authentication with EAP-TLS, because their certificates are not on the machine if they have never logged in.  Machine-only authentication with EAP-TLS avoids that.  If you use machine-only authentication with EAP-TLS you don't need to use mac caching because you would only be allowing access to machines that do machine authentication using EAP-TLS.  Onboard is only  intended for non-domain machines (unmanaged devices) that you want to authenticate to the network via eap-tls, really.  Domain machines can obtain certificates via autoenrollment and be configured automatically via group policy to do machine-only authentication on the wireless using the EAP-TLS certificates that are distributed.

4.  I am not an AnyConnect expert, so I would not know specifics.  Assuming anyconnect is a VPN client, a user remotely would login to their machine using cached credentials and have access to their desktop.  They can launch the anyconnect client and enter their username and password for authentication.  EAP-TLS would not come into play in that scenario.