(2023-06-14) Securing Or Attacking Your Active Directory With Azure AD Passwordless Authentication? That IS The Question!

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

Figure 1: The Password Replication Policy Of A Read-Only Domain Controller

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

Figure 2: The Password Replication Policy Of The RODC Like Computer Account For The Cloud Kerberos Trust

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:

Figure 3: A Note About The Configuration Of The Group “Denied RODC Password Replication Group”

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:

Figure 4: A Note About Relaxing The Password Replication Policy Of The AzureADKerberos Computer Account

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/ ###################

————————————————————————————————————————————————————

IAMTEC

Identity | Security | Recovery

————————————————————————————————————————————————————-

(2020-03-30) Resetting The Password Of The Special Purpose KrbTgt Account For Azure AD

To reset the password of krbtgt accounts in the AD domain I have written a script that helps you with that.

More information can be found through the following links:

• (2018-12-30) PowerShell Script To Reset The KrbTgt Account Password/Keys For Both RWDCs And RODCs
• (2019-02-12) PowerShell Script To Reset The KrbTgt Account Password/Keys For Both RWDCs And RODCs (Update 1)
• (2019-02-25) PowerShell Script To Reset The KrbTgt Account Password/Keys For Both RWDCs And RODCs (Update 2)
• (2020-02-10) PowerShell Script To Reset The KrbTgt Account Password/Keys For Both RWDCs And RODCs (Update 3)
• (2020-02-18) PowerShell Script To Reset The KrbTgt Account Password/Keys For Both RWDCs And RODCs (Update 4)

–

The script itself can be downloaded through the following link: Reset The KrbTgt Account Password/Keys For RWDCs/RODCs

–

With the passwordless investments made by Microsoft, a preview currently is available to also use passwordless authentication using security keys against the on-premises AD. You can read more about it through the following link:

• Enable passwordless security key sign-in to on-premises resources with Azure Active Directory (preview)

–

To achieve the goal of passwordless authentication using security keys against AD, a special krbtgt account (‘Krbtgt_AzureAD’) is created in every single AD domain where that is required. That krbtgt account is very similar to a krbtgt account for an RODC and represents Azure AD for a specific AD domain. Like any other krbtgt account, that krbtgt account also requires to have its password reset and keys rotated. Very important to note here, is the password reset should not be done like any other regular password reset, but instead a special procedure should be followed. The PowerShell script that I mention above DOES NOT impact that special krbtgt account. Including with other updates, I will update the PowerShell script to warn you if it finds that special krbtgt account in the AD domain, and also include the method and steps to officially reset the password and rotate the keys.

–

To officially officially reset the password and rotate the keys, use the following steps:

• Go to an Azure AD Connect server (v1.4.32.0 or later)
• Open a PowerShell Command Prompt window
• In that window execute the following commands:

# Import The PowerShell Module For Azure AD Kerberos Server
Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AzureADKerberos\AzureAdKerberos.psd1"

# AD Domain FQDN To Target
$adDdomainFQDN = Read-Host "AD Domain FQDN To Target"

# AD Domain/Enterprise Admin Credentials
$adDomainAdminAccount = Read-Host "AD Admin Account"
$adDomainAdminPassword = Read-Host "AD Admin Account Password" -AsSecureString
$secureAdDomainAdminPassword = ConvertTo-SecureString $adDomainAdminPassword -AsPlainText -Force
$adDomainAdminCreds = New-Object System.Management.Automation.PSCredential $adDomainAdminAccount, $secureAdDomainAdminPassword

# Azure AD Global Admin Credentials
$aadDomainAdminAccount = Read-Host "Azure AD Admin Account"
$aadDomainAdminPassword = Read-Host "Azure AD Admin Account Password" -AsSecureString
[string]$aadDomainAdminPassword = [Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($aadDomainAdminPassword))
$secureAadDomainAdminPassword = ConvertTo-SecureString $aadDomainAdminPassword -AsPlainText -Force
$aadDomainAdminCreds = New-Object System.Management.Automation.PSCredential $aadDomainAdminAccount, $secureAadDomainAdminPassword

# Check the CURRENT status of the Azure AD Kerberos Server object in Active Directory
Get-AzureADKerberosServer -Domain $adDdomainFQDN -DomainCredential $adDomainAdminCreds -CloudCredential $aadDomainAdminCreds

# Reset the password and rotate the keys
Set-AzureADKerberosServer -Domain $adDdomainFQDN -DomainCredential $adDomainAdminCreds -CloudCredential $aadDomainAdminCreds -RotateServerKey

# Check the NEW status of the Azure AD Kerberos Server object in Active Directory
Get-AzureADKerberosServer -Domain $adDdomainFQDN -DomainCredential $adDomainAdminCreds -CloudCredential $aadDomainAdminCreds

REMARKS:

• For AD, domain or enterprise admin credentials are required
• For AAD, global admin credentials are required (accounts with MFA are supported!)
• Make sure the ‘KeyVersion’ value matches the ‘CloudKeyVersion’ value and the ‘KeyUpdatedOn’ value matches the ‘CloudKeyUpdatedOn’ value!

–

Figure 1A: The Popup You Will Get When The AAD Global Admin Account Is MFA Enabled Or Is Targeted Through Conditional Access For MFA

–

Figure 1B: The Popup You Will Get When The AAD Global Admin Account Is MFA Enabled Or Is Targeted Through Conditional Access For MFA

–

Figure 2: When Having The Correct Version Of Azure AD Connect And The KrbTgt Account Does Not Yet Exist

–

Figure 3: The Initial Creation Of The KrbTgt Account For Azure AD

–

Figure 4: How The KrbTgt Account Looks Like Under The Hood

–

Figure 5A: The Placeholder RODC Computer Account For The KrbTgt Account

–

Figure 5B: The Placeholder RODC Computer Account For The KrbTgt Account

–

Figure 6: Result After Resetting The Password Of The KrbTgt Account Like Any Other KrbTgt Account (DO NOT Do This!)

–

Fixing regular reset: Set-AzureADKerberosServer -Domain <AD Domain FQDN> -DomainCredential <AD Domain Admin Creds> -CloudCredential <AAD Global Admin Creds> –RotateServerKey

Official reset: Set-AzureADKerberosServer -Domain <AD Domain FQDN> -DomainCredential <AD Domain Admin Creds> -CloudCredential <AAD Global Admin Creds> -RotateServerKey

Figure 7: Fixing A Regular Reset And Officially Resetting The Passwords

–

Figure 8: Too Frequent (Within 24 Hours) Password Resets Generates A Warning

–

Set-AzureADKerberosServer : You must wait 24 hours in between rolling the Azure AD Kerberos Server keys. Rolling keys too frequently may result in service disruption. You may use the Force option to ignore this warning.
At line:1 char:1
+ Set-AzureADKerberosServer -Domain $adDomainFQDN -DomainCredential $ad …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Set-AzureADKerberosServer], InvalidOperationException
    + FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.AzureAD.Kdc.Management.SetAzureADKerberosServer

–

Have fun!

–

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/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-