Tonight I was reading Dirk-Jan’s post on how Cloud Kerberos Trust, in use by Azure AD Passwordless AuthN, could be used to attack the Active Directory. Very interesting read! For all the details, please see: Obtaining Domain Admin from Azure AD by abusing Cloud Kerberos Trust
This is interesting as normally Active Directory is being used to attack Azure AD. Now it is the other way around, using Azure AD to attack Active Directory. Dirk-Jan explains all the details in his blog post, so please make sure to read that too!
So, after configuring Cloud Kerberos Trust in your AD as explained in Cloud Kerberos trust deployment, you will end up with 2 special objects in AD to support that:
- The RODC computer account “AzureADKerberos$”, by default in the Domain Controllers OU;
- An additional RODC-like KrbTgt account named krbtgt_AzureAD. This account contains the Kerberos keys used for tickets that Azure AD creates.
The RODC computer account has an additional configuration, being the Password Replication Policy (PRP). For a real RODC, the PRP looks like the following.
REMARK: The 2 groups starting with “GRP” are custom and were added by me to this PRP.
Analyzing it
- 1 default ALLOW group that by default is empty
- 5 default DENY groups with other high-privileged groups or accounts as members
After configuring Cloud Kerberos Trust in the AD, you will see an RODC-like computer account called AzureADKerberos (=CN), and its password replication policy looks like the following.
Analyzing it:
- 1 default ALLOW group that by default contains ALL users in the AD domain
- 9 default DENY groups with other high-privileged groups or accounts as members
So looking at this, the end result will be that all users in the AD domain, except for high-privileged accounts in the specified high-privileged groups, will be able to use Passwordless Authentication. Those same accounts are subject to an attack, but there is no need to worry as it does not contain high-privileged accounts, right? Wrong!
There may be many accounts in AD, that may not be a member in any of the 9 default DENY group, but still have very high privileges for some (valid) reason. A few that come to mind are the accounts in use by Azure AD Connect Sync (MSOL_* or custom) and Azure AD Cloud Sync (pGMSA_*) to connect to AD and retrieve data from or write data to AD. Those accounts most likely have “Replicating Directory Changes” and “Replicating Directory Changes All” control access right (CAR). Any account with those powers is able to perform DC Sync and get the password hashes of other accounts like the default domain administrator, and the KrbTgt account. But is that enough? Heck no! On the domain NC, you may have accounts with all kinds of exotic permissions that after a few steps allow you to still perform DC Sync. Think about accounts, or even groups configured on the domain NC with other permissions like “Full Control” (allows to perform DC Sync), or “Write DACL” (allows to change the permissions and assign “Replicating Directory Changes” and “Replicating Directory Changes All” control access right, and then perform CD sync), or “Write Owner” (allows to change the permissions and assign “Replicating Directory Changes” and “Replicating Directory Changes All” control access right, and then perform CD sync). As you can see lots of ways to get the required permissions for follow-up attacks. So how would you solve this?
There are 2 ways to solve this problem, and it depends on what you prefer to manage.
If you prefer to manage the Password Replication Policy of the AzureADKerberos RODC-like computer account, then:
- 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”, in the DENY part of the Password Replication Policy
If you prefer to manage group membership, while at the same time also protecting/preventing explicitly accounts/groups from having the password of the accounts being replicated to other RODCs if in place, then:
- 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”
The second and last option would be my personal preferred way of configuring this.
Some additional comments I would like to make:
In Cloud Kerberos trust deployment, the following NOTE is displayed halfway through the page:
The note is a weird statement, as when you look at Figure 2, it is not even listed by default, while it should be. My guess is that a mistake was made when the default ALLOW group was replaced by the Domain Users group, they also removed the default DENY group, which should not have happened.
In Cloud Kerberos trust deployment, the following NOTE is displayed at the end of the page:
Looking at what Dirk-Jan has described, I would NOT recommend in relaxing the Password Replication Policy of the AzureADKerberos Computer Account. Better yet, I would harden it as described Dirk-Jan in his post and by me in this post.
For both NOTES I will try to contact Microsoft to have those statements updated if possible.
You may also want to check out the contributions from Elad Shamir:
- https://www.youtube.com/watch?v=JCphc30kFSw&t=25886s
- https://www.youtube.com/watch?v=cs8ATpuIuzw
- https://eladshamir.com/uploads/fwdcloudsec2023/Slides.pdf
Cheers,
Jorge
————————————————————————————————————————————————————-
This posting is provided “AS IS” with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### IAMTEC | Jorge’s Quest For Knowledge ##########################
#################### https://jorgequestforknowledge.wordpress.com/ ###################
————————————————————————————————————————————————————
Identity | Security | Recovery
————————————————————————————————————————————————————-
Jorge's Quest For Knowledge! 