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

[BTinNC]

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

[Thomas Wall · Accepted solution]

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?

[BTinNC]

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

[Ryan Coombs · Accepted solution]

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

[BTinNC]

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.

[Ryan Coombs]

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

[BTinNC]

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!