Very proud (again!) to have been selected again to present at Troopers 2024!
Somewhere in the week of June 24th – 28th, I will be challenging the demo gods for a full hour. Let’s just hope everything goes as planned!
Last year at Troopers I presented about the “Best Practices for Resynchronizing AD and Entra ID After Forest Recovery”. This year, I will actually show you how this can be done for real!
————————————————————————————————————————————————————- 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/ ###################
On Friday, June 7th, I will be presenting a session at “European Identity and Cloud Conference 2024”. Very honored to be selected as a speaker and to contribute to helping others.
————————————————————————————————————————————————————- 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/ ###################
On Tuesday, May 21st, I will be presenting a session at “CYBERWISECON EUROPE 2024”. Very honored to be selected as a speaker and to contribute helping others.
————————————————————————————————————————————————————- 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/ ###################
When installing Active Directory (AD), in the first AD domain, the so-called Forest Root AD Domain, an administrator account is created as part of the creation of the AD domain. This also happens in the respective AD domains when adding additional child or tree root AD domains. The (default) administrator account (RID 500) in any AD domain is always a member of the “administrators” group and the “Domain Admins” group in that same AD domain. When it concerns the Forest Root AD domain, it will also be a member of the “Enterprise Admins” group.
As a best practice, the default administrator account should never be used for anything, except:
The initial setup of an AD domain;
Disaster recovery activities for products and/or processes that depend on the usage of the default administrator account;
Service outage when things are so broken that no (other) account can log in.
With this in mind, the default administrator account can be considered a so-called Break-Glass Account. It is not owned by anyone; therefore, it must be heavily secured in such a way that it cannot be used in any way without the correct steps and authorizations. In addition, I also believe that the number of dependencies should be as low as possible, preferably, even no dependencies. The more dependencies exist to use this account, the more things you will have to manage to make it work. In addition, if any of the dependencies fails for whatever reason, that then prevents the usage of the default administrator account, making it useless in an emergency scenario. Also, the default administrator account is also a very special account with certain “features” that no other account has. Those features are:
When global catalogs (GC) are unavailable, broken, not ready, or anything else, the default administrator account is the only account that can log on without issues;
The default administrator account cannot be deleted from the AD domain as it is a built-in account;
Figure 1: The Inability To Delete The Default Administrator Account (Here Renamed To ADM TEC!)
Although the default administrator account can be removed from the “Domain Admins” group as a member, and if applicable the “Enterprise Admins” group, it cannot be removed from the “administrators” group as it is a built-in account;
Figure 2: The Inability To Remove The Default Administrator Account From The Administrators Group
The default administrator account cannot be locked out. Well, to be technically correct, it can be locked out, but as soon as the correct password is provided it will unlock automatically. In addition, it still has the same behavior as other accounts;
Figure 3: The Default Administrator Account Being “Locked Out”
The default administrator account can be disabled, and after certain (special) steps it can still be used, in for example emergency scenario. This will be explained in the next blog post.
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/ ###################
A new version of the SYSVOL/File Replication Convergence Check script has been published containing updates, improvements, and bug fixes. Read more about it, and get the new version of the script, by clicking HERE. Any feedback, or feature requests? Just let me know!
Oh, and I almost forgot to mention it, make sure to read the documentation first and also try it out first in a TEST environment to see how it works, what it does and to see if it meets your needs!
PS: are you still using NTFRS? Please do make sure to move away from it and start using DFSR for it. Read more about that HERE and HERE.
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/ ###################
A new version of the AD Replication Convergence Check script has been published containing updates, improvements, and bug fixes. Read more about it, and get the new version of the script, by clicking HERE. Any feedback, or feature requests? Just let me know!
Oh, and I almost forgot to mention it, make sure to read the documentation first and also try it out first in a TEST environment to see how it works, what it does and to see if it meets your needs!
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/ ###################
Almost 11 years ago, like the other script, I wrote the very first PowerShell script to test SYSVOL Replication Latency/Convergence. Again, the last update to that script was almost 10 years ago.
For some time, i.e. many years, I had several ideas on how to improve and enhance the script so that it could be used in any environment (small, medium, large) as performant as possible with additional features. Think about features like automation, and logging support for any naming context (partition) in the AD forest and not just domain partitions. Because of the amount of work, it would involve due to a full rewrite and because I did not see the need, I never implemented those changes. Until now.
I had received requests from people that I know, friends, and colleagues to include several updates they required. Based on what I heard, I thought it was time to implement all the thoughts that I had to help them and many others using this script for whatever purposes people wanted to use it for. On some regular days, you may just want to know what the latency/convergence is of file replication in any NTFRS/DFRS replicated folder, like e.g. the SYSVOL or any other replica set or replicated folder. Another scenario, which you may want to use this script is right after forest recovery to understand how and if file replication is working as it should be.
Well, wait not longer, as mentioned the day has come for the full rewrite of the script with all kinds of new cool features. For a full description of what the script can do including nice screenshots, click HERE. Any feedback, or feature request? Just let me know!
Oh, and I almost forgot to mention it, make sure to read the documentation first and also try it out first in a TEST environment to see how it works, what it does and to see if it meets your needs!
PS: are you still using NTFRS? Please do make sure to move away from it and start using DFSR for it. Read more about that HERE and HERE.
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/ ###################
Almost 11 years ago, I wrote the very first PowerShell script to test Active Directory (AD) Replication Latency/Convergence. The last update to that script was almost 10 years ago.
For some time, i.e. many years, I had several ideas on how to improve and enhance the script so that it could be used in any environment (small, medium, large) as performant as possible with additional features. Think about features like automation, and logging support for any naming context (partition) in the AD forest and not just domain partitions. Because of the amount of work, it would involve due to a full rewrite and because I did not see the need, I never implemented those changes. Until now.
I had received requests from people that I know, friends, and colleagues to include several updates they required. Based on what I heard, I thought it was time to implement all the thoughts that I had to help them and many others using this script for whatever purposes people wanted to use it for. On some regular days, you may just want to know what the latency/convergence is of the AD replication within a certain naming context (partition). Another scenario, which you may want to use this script is right after forest recovery to understand how and if AD replication is working as it should be.
Well, wait not longer, as mentioned the day has come for the full rewrite of the script with all kinds of new cool features. For a full description of what the script can do including nice screenshots, click HERE. Any feedback, or feature request? Just let me know!
Oh, and I almost forgot to mention it, make sure to read the documentation first and also try it out first in a TEST environment to see how it works, what it does and to see if it meets your needs!
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/ ###################
————————————————————————————————————————————————————- 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/ ###################
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.
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.
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:
————————————————————————————————————————————————————- 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/ ###################
Jorge's Quest For Knowledge! 