Security

Hey Airheads,

I've run into a bit of a pickle and wanted to run it by everyone since I can't seem to find anything that'll help me.

Two things:

1. The client I'm currently working with would like to have a 3rd party cert installed on ClearPass for EAP-TLS. The cert has already been pushed to all clients via GPO, and the server, intermediate, and root certs have been imported and trusted in ClearPass, but we're finding that unless we include, as an Authentication source, an AD forest, the EAP transaction doesn't take place. If I put the AD source back into the Authentication section, auth works. They'd like it to only be referenced on ClearPass so that their AD forest doesn't take a beating when doing authentications. I can't seem to find where I can simply have the cert referenced and validated just on ClearPass without including AD. Any ideas?

2. Also, is there a way to setup a ClearPass role that'll only allow a client to pass authentication if the mutual cert is "Trusted"? If ClearPass is receiving a CRL on an untrusted cert, we'd like to disable that. Or is that something that's just simply done automatically and ClearPass won't authenticate a user if they're attempting to authenticate using an untrusted cert?

I'm new to the whole cert thing, so any help would be appreciated. I'm thinking that ClearPass itself would need to issue a self-signed cert and then have that cert pushed out via GPO to all connecting devices to facilitate the requirement of only checking a cert that resides on ClearPass, but I'm not sure if that's the way to go, and I'm not sure what I would use for Authentication.

Any advice would be appreciated. Thank you!

For situation#1, you need to create a new EAP-TLS authentication method and make sure authorization is required is unchecked.  Use that new EAP-TLS authenticaton method in your service instead of the built in [EAP-TLS] authentication method.

For Situation #2, what CA is issuing your client-side EAP-TLS certificates?  That will determine what we can do.

EDIT:  Honestly, if ClearPass does not have the CA that issued the EAP-TLS certificate in its trusted Certificate Authorities, EAP-TLS "Authentication" will not occur.  If you only want certificates from a single certificate authority to be trusted, just disable all of those except for the one which issued the certificates you want to successfully authenticate..

Thanks. Is that secure? This company is very strict on security.

It's from Digicert.

Is what secure?  You need to probably get a consultant for specific security questions.  I am only answering general questions based on the limited information you give me.

 EDIT:

Authorization checks the username on the certificate against AD.  No AD account, EAP-TLS does not work.  Great for when you disable someone's AD account and you don't want their certificates to work.

EAP-TLS is one of the most secure mechanisms used on wireless.  How secure it is depends on the implementation.  If you limit the certificate trust list, do authorization checks against AD and enable a protocol like OCSP to check revocation of certificates, you will increase the security quite a bit.  You will also need a reliable process to distribute and revoke certificates.

Again, I am just answering general questions you might have about your deployment.  A security consultant is the best route to determine if your network is a secure as it could be.  Please look at the older security policy paper here:  

WP_BUILDING GLOBAL SECURITY POLICIES[1].pdf - Aruba Networks

Colin,

I was just suggesting if disabling the verification check for EAP-TLS is secure in regards to whether or not the cert is actually being checked. I understand that a certificate checks against AD for u/p credentials, but I'm simply looking for a way to validate that a client has the cert I want installed on their computer, and that that cert also exists on ClearPass, and is verified and trusted. Minus the EAP-TLS modification, I was attempting to do that today, but I didn't see the options within ClearPass while I was building out the CPPM roles that would allow me to check even if a cert was verified.

Since this client wants two-factor auth, they're just wanting to validate whether or not a client cert is valid, but not check against AD. Using the EAP-TLS modification, it seems as though CPPM will in fact check to see if the cert is on the client's machine, but it won't check AD. That's good. When I asked if it was secure or not, I was just remarking that now CPPM is the "trusted" root, of sorts. In summation, I just want the client to believe that CPPM has the root cert, and I don't want CPPM to have to do an LDAP query to AD to verify anything. The client's AD (quite a complicated setup actually, but I can't actually give anything away about it, unfortunately) shouldn't be queried if a client cert is being validated. So, something like simply having CPPM verify that the Issuer DN is the same, or some other validation of that nature, would suffice. Or maybe something else that just compares some info in the root CA on CPPM against some info on the client cert, and verifies that they match. Something like that. I tried doing that today with just the Issuer DN, but it failed because it still needed to reach out to AD, and the client doesn't want that.

The complete auth chain goes something like this:

1. CPPM and the client verify each other's common certs using EAP-TLS.

2. The client is then placed into a captive portal and authenticates against an additional database.

3. The client is then granted full access to the network.

Hopefully that clears up a few things. I'm sorry that I can't share more, but I'm not willing to give up anything else about the client. Judging from your responses, I detect that you might be a little frustrated at the lack of information that I'm presenting and then expecting a clear and concise response, but I'm not really looking for that so don't sweat it.

As far as the security professional is concerned, I'm basically that guy. I've got all of the controller and CPPM logic licked and am about 80% there, it's just that these requirements are a little stringent and don't really conform to any standard that I'm aware of.

Anyway, thanks for reading the wall. If you've got anything else that I might be able to learn from, I'd appreciate it. Thanks!

Quick addition to this: CPPM has the intermediate and root ca certs trusted and enabled. I'm going to modify the stock EAP-TLS authentication option with the one you suggested (with and without Certificate Comparison enabled) and remove AD as an authorization source, check for Issuer DN to match what's on the intermediate cert, and see what happens. I'll report back what I find.

Signal Forest,

No problem;  it is just a disclaimer that we can only give you information and ideas but not guarantee that you are secure.  The security is in the implementation, and depending on how that is configured, it might not be secure..

What is CA issuing the client certificates?  If the customer already has AD, and they are using company domain devices, they should have their own AD issue certificates using autoenrollment, because it is easy, inexpensive and they would have complete control over the process:  https://blogs.technet.microsoft.com/networking/2012/05/30/creating-a-secure-802-1x-wireless-infrastructure-using-microsoft-windows/  If they are not using domain machines, it is still suggested to use their own active directory to at least generate certificates, because, once again, they have control over the process.  In addition, you would be able to use OCSP on the CA and ClearPass would be able to use that to check to see if certificates are revoked.

"I'm simply looking for a way to validate that a client has the cert I want installed on their computer, and that that cert also exists on ClearPass, and is verified and trusted. Minus the EAP-TLS modification, I was attempting to do that today, but I didn't see the options within ClearPass while I was building out the CPPM roles that would allow me to check even if a cert was verified." - You should not be issuing certificates to clients that you don't want to have certificates.  If there is a client that you issued a certificate to and you no longer want that client to have it, you can revoke it in your AD CA.  ClearPass can check for that revocation using OCSP.  If you only have your CA's certificate in the Trust list in  ClearPass, only client-side certificates that you issue will be allowed to authenticate.  Authorizing against AD only checks that the account with the username on the certificate is valid:  It does not check the password.

Colin,

Just a small update for you. Because of the nature of their network, I persuaded them to simply allow AD to be used to check against the machine cert. They were ok with it after we validated many other pieces of the cert, including a directory group in AD.

Now I have to figure out how I can authenticate a user without having CPPM joined to their root domain (because they don't have one) using EAP-TLS. I don't think it's possible. They currently have a captive portal that authenticates against another database with a separate username and password and that passes authentication ok, but I'd much rather have them be able to authenticate against that source from simply pushing user authentication via Windows (without pulling their Windows credentials).

Any thoughts about this crazy setup?

Offline AD root.

Would say that if a person is issued a certificate, they are authorized to connect to the network?  If yes, that is all they should need, right?

Typically, but they're doing two-factor authentication.

So, what more would you like to check, besides the fact that the certificate was issued by your CA?

If you want to check that the username is valid, you would need to turn on authorization.  If you want to check revocation status, your CA would need to be online and enable OCSP.

The first check is from A source, and that's for the machine cert. Also, I'm checking a directory in an AD location, but I'm not actually bound to that forest. They're using something else to ask AD for verification.

The second check is from B source, which just does a username and password check. But again, not bound to AD. Something else is bound to the AD forest, and they use that to do lookups since they don't have a root (centralized) forest. Since they can't do 802.1x directly to that source, they use Captive Portal to do a check against B source, and when that returns accept/deny, the client is derivated to another role within CPPM, etc. etc.