2

I have a Windows Server 2012 AD/CA and domain joined computers automatically receive the CA public cert and also get a computer certificate generated and pushed using GPO auto-enrollment. All of this is used for 802.1X and works fine.

Now I need to generate a certificate for a non-domain joined win10 computer, so that it can also authenticate via 802.1X.

This is proving quite difficult. I've come across this post that describes two ways to accomplish this:

option 1

Export the certificate from a domain joined computer. I've tested and this works, but as explained in that post the drawback is that all the non-domain joined computers will share the same certificate.

option 2 (preferred)

  1. Create an account in AD
  2. Issue a certificate from a template that allows the private key to be exported
  3. Using name mappings, attach the certificate to the account
  4. Create an SPN that matches the SAN on the certificate..i.e. if the SAN is computer.domain.com, you need to create a SPN on the account host/computer.domain.com
  5. Install certificate on to target workstation/device

This follow-up comment seems to suggest that the five steps above can be reduced to the following:

  1. Create computer AD account
  2. Issue a computer certificate for the non-domain computer adding SAN:UPN=<hostname>$@<domain.tld>
  3. Install computer certificate on client

You can make the hard option a little easier and reduce a couple of the steps by using a SAN entry in the certificate with a format of SAN:UPN=<hostname>$@<domain.tld>. This results in a certificate that has an NT Principle Name of <hostname>$@<domain.tld> in the SAN field which is then appropriate for authentication to the NPS as a pure computer object. The only dependency is then the creation of a computer account in Active Directory and adding it to the respective groups for AuthZ.

I’ve created a Computer AD account with the hostname win10test but I don’t understand how to generate the certificate and how to add the SAN:UPN=<hostname>$@<domain.tld> to the certificate.

Do I need to create a CSR on the non-domain computer?

Can someone please elaborate on the instructions from the MS forum post. Thank you.

UPDATE

I created a csr request.inf that looks like this:

[NewRequest]
Subject="CN=win10test"
KeyLength=2048
KeySpec=1
MachineKeySet=TRUE
SMIME = FALSE

[RequestAttributes]
CertificateTemplate="NonDomainWorkstations"
SAN="upn=win10test@test.local"

I then copied it to the CA and submitted the request. The cert for win10test was issued but it doesn’t contain the SAN field. I don’t understand why.

UPDATE 2

New CSR request with correct SAN attribute as Crypt32 pointed out.

[NewRequest]
Subject="CN=win10test"
KeyLength=2048
KeySpec=1
MachineKeySet=TRUE
SMIME = FALSE

[Extensions]
2.5.29.17 = "{text}"
_continue_ = "upn=win10test@test.local"

[RequestAttributes]
CertificateTemplate="NonDomainWorkstations"

The issue that remains is that the cert above does not seem to associate with the win10test AD computer account.

UPDATE 3

  1. Created AD computer account win10test
  2. Modified dNSHostname to win10test.test.local
  3. Creat CSR on win10test using the following request.inf:
[NewRequest]
Subject="CN=win10test"
KeyLength=2048
KeySpec=1
MachineKeySet=TRUE
SMIME = FALSE

[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=win10test.test.local"

[RequestAttributes]
CertificateTemplate="NonDomainWorkstations"
  1. Run certreq -new request.inf win10test.req on win10test
  2. Copy win10test.req to CA server and submit request
  3. Copy win10test.cer to win10test and install to local machine.

Can’t 802.1x auth. Get the following error in NPS:

Event 6273
host/win10test.test.local
TEST
TEST\host/win10test.test.local

The specified user account does not exist.
Community
  • 1
user355031
  • 41
  • 1
  • 1
  • 5
  • Why is option 2 preferred? You should be able to use certreq.exe with an .inf template to create a CSR, and process that CSR on your issuing CA. https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/certreq_1 – Greg Askew May 15 '19 at 17:08

2 Answers2

0

I answered a ServerFault question similar to this based on the second link in the answer from @Crypt32

I don't know if this answer satisfies the OP because it looks like they are aiming for manual creation of certificate requests using the certutil/certreq utilities. If you have Active Directory and it's accessible through the network from a non-domain joined computer, IMO this question provides the simplest method.

Slogmeister Extraordinaire
  • 411
  • 5
  • 8
0

Neither of OP-suggested solutions are good.

If there is only one or very little number of workgroup computers (which are not part of AD forest), then it may be reasonable to enroll and renew client certificates manually:

  1. You generate a CSR (certificate request) on workgroup computer
  2. Copy CSR to CA (or admin PC) and submit request to CA
  3. issue signed certificate and copy it back to client
  4. install certificate on client.

If the number of workgroup is relatively large, you can invest into ADCS Web Services. Here is a simplified version on AskDS blog: Enabling CEP and CES for enrolling non-domain joined computers for certificates

Crypt32
  • 6,639
  • 1
  • 15
  • 33
  • Hi I’ve updated my OP with details of the CSR inf request I attempted and that the SAN field is missing. – user355031 May 15 '19 at 17:36
  • The SAN extension in INF file has incorrect syntax. Check this article for proper one: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff625722(v=ws.10)#to-create-a-requestpolicyinf-file – Crypt32 May 15 '19 at 17:40
  • Thank you I changed the syntax for SAN but when I try to authenticate the computer I see an error in the NPS logs that the “specified user account does not exist”. So the AD computer account win10test is not associating with the certificate SAN UPN win10test@test.local. – user355031 May 15 '19 at 19:42
  • IIRC, UPNs are used only for user accounts. Computer accounts are identified by their `dNSName` attrbiute. Create computer account and add `dns` SAN entry in the CSR. – Crypt32 May 15 '19 at 19:47
  • Ok I was just following the advice in that MS forum post. I’ll try your way instead. – user355031 May 15 '19 at 19:49
  • in `dns` entry specify the FQDN of the computer account in Active Directory. – Crypt32 May 15 '19 at 19:49
  • I changed from upn to dns and set it to FQDN win10test@test.local and same for subject but it says now that the domain does not exist when trying to authenticate. Before it was that the user account did not exist. – user355031 May 15 '19 at 20:49
  • FQDN doesn't include `@` character. Take a look at `dNSHostName` attrbute for computer account in AD. It should be `win10test.test.local`. The same name must be included in `dns` SAN name in CSR. – Crypt32 May 15 '19 at 20:54
  • I’m still getting the error the account does not exist. Have you gone through this process yourself and it has worked for 802.1x computer auth for non domain joined computer? – user355031 May 15 '19 at 21:35
  • Yes, I did and it should work. I can't tell what is wrong in your environment. Basically, RADIUS gets the certificate supplied by client and attempts to map it to an account in AD. – Crypt32 May 15 '19 at 22:00
  • Can you please look at my UPDATE 3 in OP. Am I doing something wrong? – user355031 May 15 '19 at 22:19
  • Hello Crypt32. I had the same question and I have been reading up on CEP/CES and it looks very promising. We however also have linux systems and for that i've been reading NDES. Now I am wondering, if you use NDES can that also be leveraged for non-domain joined windows servers, as apposed to having multiple components do the same thing? – kevin rennenberg Apr 02 '20 at 07:36
  • No. Windows clients don't implement SCEP client. – Crypt32 Apr 02 '20 at 07:38
  • Ok, thank you for the quick reply! I will research implementing both NDES & CES/CEP then. – kevin rennenberg Apr 02 '20 at 07:54