RODC denied by Policy Module in attempt to enroll for KerberosAuthentication certificate

We have an RODC in a DMZ that is unable to request a KerberosAuthentication certificate.  The request is made, but denied :

	Log Name:      Application
	Source:        Microsoft-Windows-CertificationAuthority
	Date:          5/20/2019 4:14:45 PM
	Event ID:      53
	Task Category: None
	Level:         Warning
	User:          SYSTEM
	Computer:      CA-ISSUE.<domain>.com
Active Directory Certificate Services denied request 46875 because The RPC server is unavailable. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE).  The request was for <domain>\RODC$.  Additional information: Denied by Policy Module

Open in new window

Our issuing CA is a member server inside the domain.  Everyone is running W2K12 R2.

Our DC's on the internal network have been issued KerberosAuthentication certificates.  It's only the RODC's on the DMZ that are getting "Denied by Policy Module".

Our RODC's do have two other certificates (that have both auto-renewed since originally issued from this same CA).  So I don't "think" it's a firewall issue.

I've found some discussions where it was recommended to update the membership of "CERTSVC_DCOM_ACCESS" on the CA .  I've not changed anything yet, since none of our DC's are in that local group.  It's only member is "NT AUTHORITY\Authenticated Users".

In those same discussions, there was a suggestion to check DCOM permissions on the CA.  Our permissions match what was described.  So strike #2.

Does anyone have any other suggestions of where things could be amiss?

I'm waiting to hear from our network engineer to make sure there's not a firewall issue I'm not aware of.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Jeff GloverSr. Systems AdministratorCommented:
The only thing I can point to is the statement "RPC server is unavailable" This means DNS. So, I would look to make sure of a couple of things. First that you have the proper ports open in your firewall. The ability to issue other certificates does not mean there is not an issue. Make sure your RODC can reach a main DC via DNS ports (tcp and udp) and can reach the CA via http/https). Second, make sure the RODC properly registered in DNS.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
RhoSysAdminAuthor Commented:
Forgive me if I go down a DNS rabbit hole here.  

Our RODC has a wide open connection to the local DC (which is on the internal network, not in the DMZ).  The RODC has a statically assigned IP address, but the "A" and "PTR" records were NOT listed with "static" in the timestamp column.  I manually recreated the "A" and "PTR" records as static records.  

I'm waiting to make sure these DNS updates replicate to the DC that's local to the RODC.
Jeff GloverSr. Systems AdministratorCommented:
Static just mean you created them. When you installed The RODC, I assume you gave it a static address. The Server then registered its IP with DNS. This is all it means. If the PTR records are not replicating, perhaps you have not integrated the reverse look up zone.
  If your RODC is a member of the Read Only Domain Controllers group it should be allowed to get the cert.

Also, make sure the SRV records exist for the RODC.
OWASP: Avoiding Hacker Tricks

Learn to build secure applications from the mindset of the hacker and avoid being exploited.

RhoSysAdminAuthor Commented:
I confirmed the reverse lookup zone is AD integrated.

All the proper SRV records are there for the RODC.

The RODC is a member of the Read Only Controllers group.

These failed requests have been occurring daily in bunches (no pattern in the timestamps that I can easily tell) since I created this RODC - going back 18 months.
Jeff GloverSr. Systems AdministratorCommented:
Grasping at straws here. is the DMZ subnet part of a Site? In sites and services?
RhoSysAdminAuthor Commented:
Yes, the dmz subnet is part of a "DMZ" site.  The RODC is listed as a server in the "DMZ" site.  In NTDS Settings, there's a connection to the R/W DC in the neighboring "VPN" site.

I looked back at a temporary "test" RODC I created on our internal network, and it was issued a KerberosAuthentication certificate.

Our network engineer has opened everything up b/t the DMZ RODC and it's writable DC, as well as the CA to the RODC.
RhoSysAdminAuthor Commented:
So our RODC finally got its Kerberos Authentication certificate the night before last.  Unfortunately, two changes were made.  So I'm not sure which one was the actual fix.

1. I replaced the A and PTR records for the RODC with static records and confirmed they replicated properly to all writable DC's.

2. Our network engineer added a explicit firewall rule to allow all communication FROM our internal issuing CA to the RODC on the DMZ.  The rule he created was temporary and expired at midnight that night.  

If the DNS records are not really the issue, since they were there before and just not "static", then I guess we had a firewall problem.  

Would anyone out there happen to know a resource that would spell out the firewall rules needed to allow for auto-enrollment of certificates b/t an RODC on a DMZ and an issuing CA on the internal network?  We clearly can't open the flood gates b/t the two in either direction.
Jeff GloverSr. Systems AdministratorCommented:
TCP 464, LDAP and LDAPS from CA to DC. This article covers some Firewall rules
RhoSysAdminAuthor Commented:
Once we opened up everything on the firewall from CA to RODC, the cert was issued.  Will use link you referenced to determine how to properly tighten the firewall back up.

Thanks for helping me rule out all the things that were NOT the cause of our issue!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
certificate services

From novice to tech pro — start learning today.