cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.

3114
Views
0
Helpful
6
Replies
BTinNC
Beginner

Where does the AD member check come in to dot1x auth?

I have an AuthC rule that says If Wired_802.1x, use "Corp_dot1x_user_sequence".

The Corp_dot1x_user_sequence Identity Source Sequence says to select the Cert profile from "Corp_Cert_Profile" and use the "CorpAD" Auth Search List.

The "Corp_Cert_Profile" says to use the CorpAD Identity Store and use the identity from the Common Name in the cert. For matching client cert against the identity store, the option is "only to resolve identity ambiguity".

The CorpAD identity source is configured to look at all of our AD domains. Under Advanced settings, the options selected are:

Enable Password change

Enable Machine Authentication

Enable Machine Access Restrictions

I would like to issue certs from our internal CA to non domain joined computers and have them authenticate with dot1x. The CA is imported in the cert list. When I try to run dot1x now, it fails saying it is not a member of the domain. What option do I change in order to allow the non domain computers to authenticate without breaking dot1x for everything else?

I am running ISE 1.4

2 ACCEPTED SOLUTIONS

Accepted Solutions
Thomas Wall
Cisco Employee

If you issue non-domain clients a certificate and the supplicant is configured to use that certificate for authentication, you can set the Cert Profile to just validate it's a certificate and not check an ID store. Under the CAP profile, set the option under Match Client Certificate Against Certificate in Identity Store to never.  This would affect your existing settings with domain clients but we may be able to modify your policies to check multiple CAPs depending on set conditions. 

Are domain and non-domain host connecting from the same NAD?

View solution in original post

Brian,

There is a note listed below the continue options which reads "Authentications using EAP-TLS is not possible to continue processing when authentication fails or user is not found".  Also your "NEVER" option is greyed out because you have selected an identity store, change this to [not applicable] and NEVER will be the only option you can choose.

I would do what Thomas suggested and create a new cert profile using the Subject CN and select identity store to never.

Add a sub policy that does 802.1x and add another condition "CERTIFICATE > Issuer = OR Issuer Common Name" and match that to the Root CA of your ISE server.  Put this above your corporate policy and you should be fine.

Good luck.

-Ryan

View solution in original post

6 REPLIES 6
Thomas Wall
Cisco Employee

If you issue non-domain clients a certificate and the supplicant is configured to use that certificate for authentication, you can set the Cert Profile to just validate it's a certificate and not check an ID store. Under the CAP profile, set the option under Match Client Certificate Against Certificate in Identity Store to never.  This would affect your existing settings with domain clients but we may be able to modify your policies to check multiple CAPs depending on set conditions. 

Are domain and non-domain host connecting from the same NAD?

View solution in original post

We do have the domain/non-domain hosts connecting to the same switches around the company.

When I look at the Certificate Auth Profile, Never is grayed out.

I spoke to Cisco TAC and the TAC engineer said what I wanted to do was go to the Authentication profile, go to the AuthC rule, select Edit > Actions, and modify the "Corp_dot1x_user_sequence" options. He said the Option for "If user not found" should be changed from Reject to Continue.

He said that will push the host to the Authorization profile where it will be matched against one of those rules.

I was not very clear on whether that would make it so that a cert would have to come from the trusted root, but the user check would not be performed. 

Has anyone used this option or aware of any negative impact it will cause?

This is the error message that shows up in ISE showing the machine is not in the domain.

Cisco Identity Services Engine

  22072 Selected identity source sequence - Corp_dot1x_user_sequence
  22070 Identity name is taken from certificate attribute
  15013 Selected Identity Source - CorpAD
  24433 Looking up machine in Active Directory - CorpAD
  24325 Resolving identity - host123.mycompany.biz
  24313 Search for matching accounts at join point - mycompany.biz
  24318 No matching account found in forest - mycompany.biz
  24322 Identity resolution detected no matching account
  24352 Identity resolution failed - ERROR_NO_SUCH_USER
  24437 Machine not found in Active Directory - CorpAD
  22056 Subject not found in the applicable identity store(s)
  22058 The advanced option that is configured for an unknown user is used
  22061 The 'Reject' advanced option is configured in case of a failed authentication request
  12507 EAP-TLS authentication failed
  11504 Prepared EAP-Failure
  11003 Returned RADIUS Access-Reject

Brian,

There is a note listed below the continue options which reads "Authentications using EAP-TLS is not possible to continue processing when authentication fails or user is not found".  Also your "NEVER" option is greyed out because you have selected an identity store, change this to [not applicable] and NEVER will be the only option you can choose.

I would do what Thomas suggested and create a new cert profile using the Subject CN and select identity store to never.

Add a sub policy that does 802.1x and add another condition "CERTIFICATE > Issuer = OR Issuer Common Name" and match that to the Root CA of your ISE server.  Put this above your corporate policy and you should be fine.

Good luck.

-Ryan

View solution in original post

If I create a policy above the corporate policy and do as you suggest by having it check the CN of the cert to look for the domain name, will it still check to make sure that the cert was signed by the root CA that is in the Trusted Certificates?

Our existing certificate profile checks for CN already, and if I were to create another policy which did the same thing but without the check for the ID store, wouldnt all devices with a cert now match against that one? 

My biggest concern is to make sure that the cert that is being checked is signed by the Windows CA and not accidentally allow a lot of devices to connect that would not otherwise be allowed to do so.

It will definitely check that it was signed by the Root CA and the public key must be inside the Trusted Certificate store with a check next to "Trust for authentication within ISE"

All devices would match against the policy that is why I mentioned adding an additional condition that would not match for Corp machines but match for these non domain devices.  My example was add a condition that matches the issuer OR issuer CN = which would be your other CA (I'm assuming ISE is your internal CA)  So example issuer would be "Certificate Services Root CA - ISE-NODE"  This could be contains or equals the exact field.

Hopefully that makes sense.

-Ryan

The Windows Server CA was going to be the issuing CA for the certs for the domain and non-domain joined computers, and the original corporate policy checks for CN in the authz policy now, so I am pretty sure that policy would be the only one used.

As an alternative I could try to find something else to generate the certs and use it as the trusted root. I didnt realize that ISE could serve as a CA for computers. I will do a little more reading on that.

Thank you for your help!

Content for Community-Ad