Forum Discussion
Deleted
Nov 16, 2022Two Tier PKI AutoEnrollment & CertEnroll Errors
Hi,
I have a two tier PKI certificate system setup on windows server 2022.
All Windows 10/11 clients and domain controllers get the following errors in event viewer:
1) Automatic certificate enrollment for local system failed (0x800706ba) The RPC server is unavailable.
2) Certificate enrollment for Local system failed to enroll for a ComputerCertificate certificate with request ID N/A from Vxxx-xxx.xxx.com\xxx-Vxxx-xxx-CA (The RPC server is unavailable. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)).
3) Certificate enrollment for Local system failed in authentication to all urls for enrollment server associated with policy id: {59CE2990-AF3C-432A-A309-0CA7E3598B5C} (The RPC server is unavailable. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)). Failed to enroll for template: ComputerCertificate
On my domain controllers, I get these additional errors:
1) Certificate enrollment for Local system failed to enroll for a KerberosAuthentication certificate with request ID N/A from Vxxx-xxx.xxx.com\xxx-Vxxx-xxx-CA (The RPC server is unavailable. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)).
2) Certificate enrollment for Local system failed in authentication to all urls for enrollment server associated with policy id: {59CE2990-AF3C-432A-A309-0CA7E3598B5C} (The RPC server is unavailable. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)). Failed to enroll for template: KerberosAuthentication
3) Certificate enrollment for Local system failed to enroll for a DomainControllerAuthentication certificate with request ID N/A from Vxxx-xxx.xxx.com\xxx-Vxxx-xxx-CA (The RPC server is unavailable. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)).
4) Certificate enrollment for Local system failed in authentication to all urls for enrollment server associated with policy id: {59CE2990-AF3C-432A-A309-0CA7E3598B5C} (The RPC server is unavailable. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)). Failed to enroll for template: DomainControllerAuthentication
No computers are getting the subordinateCA cert under their local computer certificates -> Personal -> Certificates
I distributed the standalone root CA to all computers via group policy under "Trusted root certification authorities -> Certificates"
Weirdly, all computers under local certificates: Intermediate Certification Authorities -> Certificates seem to be receiving the subordinateCA certificate under there.
I've disabled all windows firewalls via GPO for testing.
my network firewall has all ports open from subordinateCA to domain controllers for testing
all workstations have ports open for subordinateCA for testing
Any help is greatly appreciated. Tried looking for solutions online to no success.
Thanks
- LainRobertsonSilver Contributor
Deleted
Howdy.
Error 1722 is pretty unambiguous.
The RPC endpoint mapper listens on TCP 135, and error 1722 only gets thrown if the source computer cannot reach TCP 135 on the target computer.
Disabling the Windows Firewall isn't the answer - not even for testing. It's straight-up dangerous in this current era, too.
Enable your firewall and ensure the following four ALLOW rules (boxed in green) are enabled. If they are missing or disabled then that's something you'd need to fix regardless.
Additionally, ensure there are no BLOCK rules preventing access to TCP 135, as BLOCK rules will take precedence over ALLOW.
Next, download Microsoft's PortQry tool:
As you will need this for end-to-end testing. The portqry.exe will need to reside on the client from where you are doing your testing and are seeing error 1722.
Ensure the Certificate Services service us running
On your root (if it's not an offline root) and intermediate authorities, ensure the relevant service is running.
Verifying if the RPC endpoint mapper is reachable
Using PortQry.exe (shows some returned output here, too) - obviously use your FQDN or IP address:
I'd expect you will still be getting error 1722 at this stage though, but this is how you can prove end-to-end RPC connectivity (thereby proving you're past the error 1722 stage.)
A useful cross-reference is testing using PortQry from a host that lives on the same switch (physical or virtual) as the Certificate Services host. If that still fails, then I'd be going back and checking that the certsvc service is running, the Windows Firewall rules have been created and enabled, and that there are no Windows Firewall BLOCK rules overriding the ALLOW rules.
Assuming those checks come up fine, then despite what you said about the network firewall having all ports open to the domain controllers (which won't help your other clients, if you're looking to enrol certificates on those), something is blocking TCP 135 as it's basically in the "not possible" category that the endpoint mapper service isn't running. Even the most basic fresh installation of something like Server Core will still be running upwards of perhaps 60 RPC services through the endpoint mapper.
It's important to note that all clients (domain controllers, member servers, workstations, etc.) get their enterprise CA configuration from AD but they do the enrolment and get the certificates from the intermediate itself, meaning TCP 135 needs to be reachable from anywhere you expect a client needing a certificate might live, not just from the domain controllers themselves.
Additional note
Once you resolve the error 1722 RPC issue, also be sure that your CRL publication location is reachable. If this only contains the LDAP distribution point then you won't need to check this but as it's quite common (if not necessary) to run a HTTP publication point, you want to be sure clients can hit this from anywhere relevant or you'll run into more issues.
Cheers,
Lain
- Deleted
Hi Lain,
Thank you for your detailed response! I am starting to go through your post right now.
So far, I noticed that my subordinate/intermediate issuing CA has the four allow in-bound firewall rules enabled (the Certification authority enrollment and management protocol rules).
However, they do not exist on domain controllers or any workstations. Should they be there too? It seems my domain controllers don't even have those pre-defined rules to add on the firewalls. Or does my domain controller need to have certificate authority service installed?P.S: thank you, I have re-enabled firewall across the domain
- LainRobertsonSilver Contributor
Deleted
Hi,
Those four rules only exist and are enabled on the hosts running Certificate Services (which should not be the domain controllers - they should only ever run just one thing: Active Directory.)
What those four rules do is allow inbound traffic from other hosts to reach Certificate Services via RPC.
Given the four rules are there and enabled, I'd:
- Ensure the Certificate Services service (certsvc) is running on the Certificate Services host;
- Run a PortQry check from another host on the same subnet/virtual switch to see if it can access the Certificate Services host;
- If it can then you know you something is blocking traffic from other more remote hosts from reaching your Certificate Services host;
- If it cannot then the problem exists on the Certificate Services host itself.
Do you know if you have had Certificate Services installed within the forest ever before? If you have, it may be the case that you have a non-existent host reference lingering in your configuration - but this is an outside possibility.
Here's some commands you can use to check if you've ever had another certificate authority:
# This command lists all defined certificate authorities. Get-ADObject -Filter { (objectClass -eq "certificationAuthority") } -SearchBase "CN=Certification Authorities,CN=Public Key Services,CN=Services,$((Get-ADRootDSE).configurationNamingContext)" -SearchScope OneLevel | Format-Table -AutoSize objectGUID, objectClass, name # This command lists all enrolment service points (aka servers running Certificate Services.) Get-ADObject -Filter { (objectClass -eq "pKIEnrollmentService") } -SearchBase "CN=Enrollment Services,CN=Public Key Services,CN=Services,$((Get-ADRootDSE).configurationNamingContext)" -SearchScope OneLevel -Properties dNSHostName | Format-Table -AutoSize objectGUID, objectClass, name, dNSHostName
Hopefully you only see entries that you know about. If you see strays that you didn't know existed (particularly from the second command) then you may have some long-lost things to clean up (aka delete.)
Cheers,
Lain