Machine Authentication using ISE with no ID store

[raksec]

Hello Experts,

I have a customer where they are using AD, but there is no identity store for machine credentials. So based on that I have different questions for machine authentication.

1. Machine supports dot1x supplicant, so how ISE can differentiate between corporate and non-corporate or personal machines?

2. Machine doesn't support supplicant, so how ISE can differentiate between corporate and personal machines?

3. If they have a CA server and machines are having certificates, can ISE query CA server to validate machine's credentials?

Thanks,

Rakesh Kumar

[Mike.Cifelli]

Available options are in line:
1. Machine supports dot1x supplicant, so how ISE can differentiate between corporate and non-corporate or personal machines?
Leverage AD security groups for the comp objects. Setup authz conditions to map clients to specific groups and push policy this way. Then if no match (personal machine) push whatever you intend for them to have access to via personal client.

2. Machine doesn't support supplicant, so how ISE can differentiate between corporate and personal machines?
You have a couple of options. If the customer has plus licensing your quickest way would probably be to profile machines utilizing the AD probe and target the AD Host Exists condition, and then utilize the profiled endpoint group in your authz policy. Another option would be to utilize posture checks, and perform check/s that would identify a corp machine versus personal. Options here could be certain reg checks, file checks, software checks, etc. However, this introduces additional config and management.

3. If they have a CA server and machines are having certificates, can ISE query CA server to validate machine's credentials?
Yes. You can setup an OCSP responder for this. In ISE you would setup an OCSP profile where you can configure how you want ISE to cache and handle responses, etc. This is found under Administration->System->Certificates->OCSP Client Profile. Make sure you setup the intermediate cert in your respective chain to validate against the OCSP service (the profile you made in ISE). Here you can configure ISE to reject client certs if OCSP returns unknown status, etc.

IMO there are other options available. Are these questions geared towards wired, wireless, or both?

[raksec]

Thanks Mike.

As I mentioned before, machine credentials are not in AD. It means there is no ID store for machines. So I cannot validate machine credentials with AD. This applies to Q1 and Q2. So what are the possibilities now?

This is for both, wired and wireless.

[Arne Bier · Accepted solution]

Hello @raksec 

Are you saying that the customer is using AD, but ISE will not be given access to their AD environment for AuthN/AuthZ purposes? Wow that's not great. What's the point of that? If you wanted to authenticate a network user with their AD creds then what better place to check than with AD ... failing that, what hope is there? None.

You could ask the customer to create you an Identity Database (e.g. a daily sync of the AD User tree and copy it into a standalone LDAP directory - this will shield the customer's AD from ISE. ISE simply uses LDAP - however, this is also fraught with issues because password authentication to LDAP won't work - but if the LDAP Store is done right, then you could use it to perform an AD Group lookup (you have to of course copy all the AD Group membership details from AD to LDAP for each account).  But beware that password authentication is not possible - you may have to simple perform Authorization only.

As for option #3, a CA server is not an authentication server and it cannot be used to validate credentials - that's the AD Domain Controller's job. Why would your customer give you network access to CA, but not to the AD Domain Controllers themselves. As @Mike.Cifelli mentioned, you interface with a CA for OSCP - but that's it. The OSCP response might only tell you that this client cert has not been revoked. But no details about AD membership.

[raksec]

Hi Arne.

Sorry for the confusion here.

Customer is giving access to AD. But they are saying that in AD they have only user credentials, not machine credentials. So we won't have any problem validating user's credentials. That's why my questions are just to validate machine credentials and differentiate between corporate and personal machines. The machines could be dot1x or non-dot1x.

[Arne Bier]

Hi @raksec 

I am no AD guru, but I know that if a Windows machine is Domain Joined, then this means (and it HAS to mean) that during the joining of the AD Domain, the AD controller creates a machine account for the machine. You can search for the machine's hostname in AD and you'll find it.

if the machines are not domain joined, then I don't know what you mean by "machine credentials".  In that case we're no longer talking about Microsoft Active Directory and Machine Authentication.

Some confusion ... needs clarity.

[raksec]

Hi Arne,

What you are saying that makes sense. I will double check with customer on AD and machine name.

Thanks.