Linux Machine account in AD for EAP-TLS

[skozlovs]

Hi,

I have a situation where customer is looking to perform EAP-TLS authentication of Linux machines against corporate AD. We managed to generate and install machine certificates on a test Linux (Ubunty) host and run 802.1X supplicant. We also manually created a machine account in AD with the name matching CN in the certificate. However, when ISE trying to perform lookup for the host in AD, it returns ERROR_NO_SUCH_USER.

It looks like the machine object that we created in AD is just a placeholder, not a proper account, so the question: is it possible to manually create a proper machine account? If yes, then what it involves?

If there is no way to create an account manually, what are the other options?

Thanks.

Stan

[Jason Kunst]

Can you please explain your intent? Why do you need an account in AD?

Are you using the internal CA On ISE and the client provisioning portal to issue the certificate? If not why are you using external ca and not ISE?

I think it’s fine to install a machine certificate on the Linux machine and present this to ISE for certificate authentication

[hslai]

Please check what certificate field is selected in the drop-down "Use Identity From" in the Certificate Authentication profile for such authenticate requests. Then, use "Test User" function in the AD join point to perform the lookup test. Also check the subject principal name (SPN) attribute set for the computers.

If you registered in the community as a partner, then you may also check out [ISE Lab Guide] ISE Active Directory Integration, which gives an example how the certificate fields matter for EAP-TLS.

[Craig Hyps]

First point of clarification:  Client does not authenticate against AD when performing EAP-TLS, but against PKI and certificates.  There are cases where authentication is also based on cert comparison stored in id store, but I don't think you are looking at that.

I expect the part you are interested in is the authorization of the machine based on its presence in AD, or membership in group or other attributes.  For this use case, I would consider simply adding into AD for access based on LDAP.  The requirements to join a Linux client to AD are quite involved, so if just looking to validate existence or attribs, LDAP likeliest the easiest path.

And yes, per Hsing's point, need to make sure Cert Auth Profile is matching on correct field for lookups into AD (or LDAP).

Craig

[skozlovs]

"authorization of the machine based on its presence in AD, or membership in group" - that is exactly the use case.

Clarification on some of the points:

• External CA (integrated with AD) is used to issues Win certificates and sign Lunix machine certs.
• There is no intent to do cert binary comparison.

Here is what we've done:

"Test User" function for test Machine account returns FAIL with "ERROR_NO_SUCH_USER", but test User account with the same name returns SUCCESS.

In The Cert Auth Profile we tried to use all possible attributes i.e. CN, SAN, Subject, no luck. Also, I'm unable to find "subject principal name (SPN) attribute" in the AD computers. There is userPrincipalName, but no "subject"... Is this correct attribute or I missed something?

We also tried to use LDAP as identity store in Cert Auth Profile, however it has Binary Comparison always ON (no option to untick it) that makes things even more complicated. In this case we receive error: "Cannot retrieve user's certificate" even if the certificate is loaded into subject's AD account.

"adding into AD for access based on LDAP" - We've setup ISE to do LDAP search in the root container (Directory Organization),

Any other suggestions?

Regards,

Stan

[hslai]

Please provide the info of CN, SAN, and Subject from a sample certificate. And, the identity field shown in live logs and auth detail report.

Attached are two screen captures to show how to get the SPN of a computer; one via "Test User" and the other via Active Directory. For computers, ISE looks them up by sAMSAccountName (e.g. tt-corp$), the SPN values with prefix host/ (e.g. host/tt-corp), UPN (e.g. tt-corp$@demo.local) and also the distigneshedName (e.g. CN=TT-CORP,CN=Computers,DC=demo,DC=local).

Please do check out the lab guide I mentioned as it has info how to configure a certificate template to issue certificates for computers and users.

Video Link : 17054 Video Link : 17055

[skozlovs]

Finally have some progress. After we added SPN to the computer object ISE is able to do lookup in AD and Win machine can authenticate with GPO generated certificate. However, Linux machine certificate FAILED with the same "ERROR_NO_SUCH_USER"

So the problem now is in the Linux cert. One thing I noted in the Radius logs is that the usernames in successful authentications appears like: host12345$@domain.xxx.xx, but failed one are like: host54321.domain.xx.xx. I guess $ and @ are used to construct the Username from some of the cert objects..... What objects are used?

In the Linux cert we don't use SAN, my understanding it shouldn't matter as long as CN is matching SPN in AD object.

Regards,

Stan

[hslai]

I will contact you offline to get a better understanding.

[skozlovs · Accepted solution]

Finally we resolved this issue. Steps required:

1. In AD create a computer object with name identical to the Linux/Unix host name.

2. In the object properties add servicePrincipalName (SPN) values with prefix host/ (e.g. host/[name] or host/[name].[domain]).

3. In the Linux/Unix machine certificate add SAN equal to SPN. Could be short name (e.g. host/[name]) or FQDN (e.g. host/[name].[domain]). Prefix host/ is a must.

We tested sAMSAccountName, UPN, distigneshedName and some other field, but none of them seems to be used for the authentication/authorization.

[hslai]

Thanks for the update. I think it could be due to some hardening or other restrictions in the AD infrastructure so that other fields not working for lookups.

[Craig Hyps]

Don't forget that you have identity rewrite or prefix/suffix stripping logic to help normalize the lookups to something like sAMAccountName.  Also, I find LDAP simpler to use sometimes if focus is on authorization since you can define the schema.

[hslai]

If the hostname shown as mixed cases (e.g. Alex-Jr-Corp1) in the SPN HOST entries, the lookup might fail.