ISE EAP-TLS certificate only check

[KevinR99]

Hi

I wonder if someone could help me in how to create a policy in ISE to do EAP-TLS based only on the user having a certificate issued by a trusted CA.  I don't want to integrate with any external identity source such as AD or LDAP.  I just want to look at the client cert and if it is from a trusted source accept it and let them on.

I tried to do this by setting up a Certificate Authentication Profile with no Identity source selected.  I then created a policy to check the Issuer CN in the certificate.  However, my authentication rule was never matched.

Anyone have any experience of this?

Thanks, Kev.

[Greg Gibbs]

What version of ISE are you using?

This should definitely be possible using a CAP with no Identity Store and an AuthC Policy matching on the 'Issuer - Common Name' value, as long as the client trusts the ISE EAP certificate and the Subject Issuer CN value is the same as what is in the certificate that the client is presenting to ISE.

I've had a customer use a similar configuration for authenticating their managed MacBooks and I've done matches on other certificate values like Subject OU for Linux endpoints.

Have a look at the live log details for the session to see what certificate values ISE is receiving, verify that the client is configured to send the correct certificate (especially if there is more than one cert in the client store), etc.

[KevinR99]

Greg

Thank you for the reply.  We are on version 3.0.0.458 patch 2.

I created a couple of rules and it matched the authentication rule that references the CAP with no identity store.  When it then moves onto authorization I created a simple rule that says match Certificate Issuer CN = MyCA

The authorization didn't match on that rule though and fell through to a lower priority rule.  When I looked at the log for that process I can see it does indeed pick up that the Certificate Issuer CN = MyCA but the rule wasn't matched. 

Are there any possible replication processes going on here because my primary ISE, where the rule change is obviously made, is not the authenticating ISE?  The secondary does the authentication for this session because the WLC that is requesting the authentication is in the same DC as the secondary.

Thank you again for your input.

[ComputerRick]

Do you have a specific issuer that you're looking for and is that certificate chain in the Trust Store on ISE, with the "Trust for client authentication" checked on it?

Did you specify in the condition the issuer of the certs that you're using?

[Greg Gibbs]

If there are replication issues, you should see alarms for them and you would likely see the PSN showing as out-of-sync on the Administration > System > Deployment page.

Can you share some screenshots of your authC/authZ policies?

Are you matching on the Issuer CN in the AuthC Policy, but then the same condition match fails in the AuthZ Policy? Are there other matching conditions in the same AuthZ Policy that could be the issue?

I just tested my 3.0 (p4) policies again with a RHEL endpoint and both the AuthC and AuthZ policies match correctly using Issuer CN (in addition to other conditions), so this should work as expected.

My policy examples:

[KevinR99]

Thanks for that output Greg. 

That's pretty much what I am doing.  I'll delete the rules and start again to see if it makes any difference.  Out of interest in the CAP part where it says Match client Certificate against Certificate Identity store which option do you use?  I only want to ensure the cert is issued by a root CA in my trusted store on ISE.  So I select Never in that area.

Kev.

[Greg Gibbs]

My CAP is also set to Never for that option. That function is irrelevant anyway when the Identity Store setting is set to [not applicable], as this CAP would need to be to avoid checking the identity from the cert against an external ID store.

The check against the certificate trust chain is done automatically by ISE in the AuthC process, so there is nothing to configure for that.

[avatar8886]

I appreciate this is an older post but would the same be relavant for EAP-TEAP if i'm using EAP-TLS inner to check. I'd like to further validate by binding an OSCP responder or CRL to the trusted issuing CA certificate that goes in ISE trusted certificates.

To me by setting binary comparions to never just means that whatever attributes ISE gets from the certificate, ISE just doesn't actually do anything with it and authenticates purely on certificate trust. You could then use the authorisation logic as per Kevin's comments.