# P-RODCNeverReveal should ignore "AzureADKerberos" **URL:** \ **Category:** PingCastle Discussions & Questions\ **Tags:** pingcastle, question\ **Created:** [September 4, 2025, 9:41am UTC](https://community.netwrix.com/t/p-rodcneverreveal-should-ignore-azureadkerberos/113470 "2025-09-04T09:41:44Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Andreas.Rinner](https://yyz1.discourse-cdn.com/netwrix/user_avatar/community.netwrix.com/andreas.rinner/32/2929_2.png) [@Andreas.Rinner](https://community.netwrix.com/u/Andreas.Rinner)\ **Post date:** [September 4, 2025, 9:41am UTC](https://community.netwrix.com/t/p-rodcneverreveal-should-ignore-azureadkerberos/113470/1 "2025-09-04T09:41:44Z")
“P-RODCNeverReveal" (“Check if the protection against revealing privileged group is active“) reports “AzureADKerberos” but it is just an RODC object without a RODC Server. The Attribute “msDS-KrbTgtLink“ has the DN of a “krbtgt\_AzureAD“ object. That is a unique name and would help to filter out these objects. I’m not aware of any better detections. Example: msDS-KrbTgtLink: CN=krbtgt\_AzureAD,CN=Users,DC=example,DC=local ---
**Author:** ![joe.dibley](https://yyz1.discourse-cdn.com/netwrix/user_avatar/community.netwrix.com/joe.dibley/32/165_2.png) [@joe.dibley](https://community.netwrix.com/u/joe.dibley)\ **Post date:** [September 4, 2025, 10:42am UTC](https://community.netwrix.com/t/p-rodcneverreveal-should-ignore-azureadkerberos/113470/2 "2025-09-04T10:42:58Z")
Hi there Andreas, Whilst the account is indeed not a real server, I believe the finding is still valid. The Cloud Kerberos Trust documentation also states that the RODC restrictions should not be lifted due to Entra ID → On Prem attack paths as well as those restriction controlling who it can issue TGTs for. You can see this on the two notes in this specific section. > **[Windows Hello for Business cloud Kerberos trust deployment guide](https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust?tabs=intune#microsoft-entra-kerberos-and-cloud-kerberos-trust-authentication)** > > Learn how to deploy Windows Hello for Business in a cloud Kerberos trust scenario. I hope this helps understand this better and why I believe this should remain as is. ---
**Author:** ![Andreas.Rinner](https://yyz1.discourse-cdn.com/netwrix/user_avatar/community.netwrix.com/andreas.rinner/32/2929_2.png) [@Andreas.Rinner](https://community.netwrix.com/u/Andreas.Rinner)\ **Post date:** [September 5, 2025, 9:12am UTC](https://community.netwrix.com/t/p-rodcneverreveal-should-ignore-azureadkerberos/113470/3 "2025-09-05T09:12:10Z")
Hi Joe, thank you for your quick reply. So the following is what i did not know in detail, but was well described in MS documentation as linked by you: > The default _Password Replication Policy_ configured on the AzureADKerberos computer object doesn’t allow to sign high privilege accounts on to on-premises resources with cloud Kerberos trust or FIDO2 security keys. > > Due to possible attack vectors from Microsoft Entra ID to Active Directory, it’s not recommended to unblock these accounts by relaxing the Password Replication Policy of the computer object `CN=AzureADKerberos,OU=Domain Controllers,`. But I still was wondering why in multiple environments I found the “Denied RODC…” group is missing by default in the “AzureADKerberos” object in the “msDS-NeverRevealGroup“ list. So I searched and found this good additional information from Jorge (aka “zjorz” aka “Jorge de Almeida Pinto”) I would like to share here: > - Configure the default “Denied RODC Password Replication Group” (objectSID = domainSID-572) in the DENY part of the Password Replication Policy > - Configure all accounts and groups, configured on the domain NC, with explicit permissions for “Replicating Directory Changes” and “Replicating Directory Changes All” control access right (CAR), or “Full Control”, or “Write DACL” or “Write Owner”, as members of that default “Denied RODC Password Replication Group” [(2023-06-14) Securing Or Attacking Your Active Directory With Azure AD Passwordless Authentication? That IS The Question! « Jorge’s Quest For Knowledge!](https://jorgequestforknowledge.wordpress.com/2023/06/14/securing-or-attacking-your-active-directory-with-azure-ad-passwordless-authentication-that-is-the-question/) ---
**Author:** ![joe.dibley](https://yyz1.discourse-cdn.com/netwrix/user_avatar/community.netwrix.com/joe.dibley/32/165_2.png) [@joe.dibley](https://community.netwrix.com/u/joe.dibley)\ **Post date:** [September 5, 2025, 9:50am UTC](https://community.netwrix.com/t/p-rodcneverreveal-should-ignore-azureadkerberos/113470/4 "2025-09-05T09:50:25Z")
Awesome stuff Andreas. It is definitely a confusing one but your linked post definitely clears up the confusion. For some reason I initially thought Microsoft changed the PRP but that doesn’t seem to be the case after checking the version history. ---
**Author:** ![system](https://yyz1.discourse-cdn.com/netwrix/user_avatar/community.netwrix.com/system/32/3102_2.png) [@system](https://community.netwrix.com/u/system)\ **Post date:** [November 4, 2025, 9:51am UTC](https://community.netwrix.com/t/p-rodcneverreveal-should-ignore-azureadkerberos/113470/5 "2025-11-04T09:51:25Z")
Closed on November 4, 2025, 9:51am UTC This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.