Jorge's Quest For Knowledge!

(2024-04-23) Breaking The Glass Of Your “Get-Out-Of-Jail-For-Free” AD Account – Introduction (Part 1)

Posted by Jorge on 2024-04-23

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

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

IAMTEC

Identity | Security | Recovery

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

Posted in Active Directory Domain Services (ADDS), Security | Tagged: Active Directory, cybersecurity, Default Administrator Account, Microsoft, Security, windows | Leave a Comment »

(2024-02-07) Testing SYSVOL/File Replication Latency/Convergence Through PowerShell (Update 5)

Posted by Jorge on 2024-02-07

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

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

IAMTEC

Identity | Security | Recovery

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

Posted in Active Directory Domain Services (ADDS), Forest Recovery, PowerShell, Replication, SYSVOL, Tooling/Scripting | Tagged: Active Directory, DFSR, Disaster Recovery, FILE REPLICATION, NTFRS, PowerShell, Replication Convergence, SYSVOL, Tooling/Scripting | 2 Comments »

(2024-02-07) Testing Active Directory Replication Latency/Convergence Through PowerShell (Update 5)

Posted by Jorge on 2024-02-07

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

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

IAMTEC

Identity | Security | Recovery

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

Posted in Active Directory Domain Services (ADDS), Forest Recovery, PowerShell, Replication, Tooling/Scripting | Tagged: Active Directory, Disaster Recovery, PowerShell, Replication Convergence, Tooling/Scripting | Leave a Comment »

(2024-01-31) Testing SYSVOL/File Replication Latency/Convergence Through PowerShell (Update 4)

Posted by Jorge on 2024-01-31

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

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

IAMTEC

Identity | Security | Recovery

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

(2024-01-29) Testing Active Directory Replication Latency/Convergence Through PowerShell (Update 4)

Posted by Jorge on 2024-01-29

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.

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.

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

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

IAMTEC

Identity | Security | Recovery

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

(2023-06-16) Presenting At Troopers 2023

Posted by Jorge on 2023-06-16

https://troopers.de/

https://troopers.de/troopers23/talks/fegbvs/

Cheers,

Jorge

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

IAMTEC

Identity | Security | Recovery

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

Posted in Active Directory Domain Services (ADDS), Azure AD Cloud Sync, Azure AD Connect, Conferences, Forest Recovery | Leave a Comment »

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

Posted by Jorge on 2023-06-14

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:

Cheers,

Jorge

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

IAMTEC

Identity | Security | Recovery

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

Posted in Active Directory Domain Services (ADDS), AuthN, Azure AD Connect, Kerberos AuthN, KrbTgt Account, Passwordless, Passwordless, Passwords, Passwords, Read-Only Domain Controller, Windows Azure Active Directory | Tagged: Active Directory, Azure Active Directory, Azure AD Connect, Cloud Kerberos trust, Passwordless | Leave a Comment »

(2023-05-26) Presenting At Info Security 2023

Posted by Jorge on 2023-05-27

Oops, I’m doing it again…

Cheers,

Jorge

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

IAMTEC

Identity | Security | Recovery

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

Posted in Active Directory Domain Services (ADDS), Backup And Restore, Conferences, Forest Recovery, Ransomware | Tagged: Active Directory, Disaster Recovery, Ransomware | Leave a Comment »

(2023-05-19) Hybrid Identity Protection (HIP) 2023 Global Conference Coming In August

Posted by Jorge on 2023-05-19

The Hybrid Identity Protection 2023 Global Conference is coming up in New York on August 23rd and 24th this year. Real people, real talks, real experience. Interested? Great, make sure to register quickly through the following link: https://www.accelevents.com/e/hip-global-2023. Oh, by the way, it is free!

Cheers,

Jorge

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

IAMTEC

Identity | Security | Recovery

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

Posted in Conferences | Tagged: Conferences, HIP | Leave a Comment »

(2023-05-18) Test Environments, Snapshots And The SYSVOL Do Not Always Like Each Other (2)

Posted by Jorge on 2023-05-18

In the following article, I explained a scenario with test environments, where the SYSVOL replication breaks due to the use of snapshots. I also explained how to fix it.

(2023-05-06) Test Environments, Snapshots And The SYSVOL Do Not Always Like Each Other (1)

Now, if you are using snapshots frequently to revert the test environment back to a certain state, fixing the SYSVOL will be part of that whole process. In addition, if you forget to fix the SYSVOL, you are working with a broken SYSVOL while not even realizing it, and that might have an impact one way or another.

Another approach to this problem is to disable the Generation ID process that detects any difference in the Generation ID between the VM and the registration on the computer account. That process is managed by the “Microsoft Hyper-V Generation Counter” (GenCounter) service. That service is not visible in the services.msc, but it is visible through Get-Service CMDlet. The idea is to disable that service on ALL DCs in the AD forest. The best way to achieve that is to configure a GPO in every AD domain, existing or new, that is linked to the “Domain Controllers” OU. That configuration in the GPO, tells every DC (RWDC and RODC) to DISABLE the “Microsoft Hyper-V Generation Counter” (GenCounter) service, but it will not stop it. A reboot of every DC, make sure that service is not started as it has been configured to be disabled. It is therefore a 2 step approach.

However, to configure a service in the System Services section of a GPO, the service itself must exist on the DC. Because the service does exist but is not visible, you can still not configure it through the GPMC. Another way to configure this is to use a registry preference. The downside of configuring this through a registry preference is that it tattoos the registry, meaning it will not be undone when you remove the configuration. When using a service in the System Services, it does not tattoo the system, and because of that it is preferred. Although not visible when you want to configure it, it is visible in the GUI if you want to remove it.

The easiest way to configure this as a service in the System Services section of a GPO, is to use PowerShell. And to help you out I have written some PowerShell code. That code can be found through the following link: Configuring New Or Existing GPO With The GenCounter System Service To NOT Start (i.e., Disable Generation ID)

PS: please make sure to test this first in a test environment. DO NOT use it in any production environment!

That code would need to be used per AD domain and should be executed locally on 1 RWDC per AD domain. Remember, it should be used within all AD domains in the AD forest! Before using the code, configure first the name of either an existing GPO or a new GPO. In case of a new GPO, the code will create that GPO. With either an existing or new GPO, for it configuration to be affective, it must be linked to the Domain Controllers OU.

Just to be sure, a disclaimer: DO NOT USE SNAPSHOTS OR ANYTHING SIMILAR, OR ANY OF THE STEPS ABOVE IN A PRODUCTION ENVIRONMENT, OR ANY PRODUCTION LIKE TEST ENVIRONMENT!
Again: DO NOT DISABLE THE GENERATION ID PROCESS IN A PRODUCTION ENVIRONMENT, OR ANY PRODUCTION LIKE TEST ENVIRONMENT!

Please be aware, that when the Generation ID process is reenabled, after it has been disabled, it will detect a change which will trigger the behavior explained in the first part of the blog post. The fix of that is explained also in that first part.

Now, with a PERSONAL test environment that you use for regular testing of patches/updates, testing of AD features, security testing, scripting, testing AD-related products, used for learning/demoing, etc, etc, it is a common thing to use VM snapshots. The following are common steps in PERSONAL test environments:

Create and configure DCs and AD as needed
Shutdown ALL DCs in the AD Forest
For ALL DCs in the AD Forest, create the snapshot and give it a meaningful name with a date and time
Boot up ALL or SOME of the DCs in the AD forest
Do whatever you need to do
When done, shut down all the DCs that were booted after the snapshot was created, and also revert all those DCs to the same snapshot. ==> Because the generation ID process is disabled, nothing will happen with the SYSVOL as explained.

Do you need to perform updates on the DCs or AD, then follow the next steps:

Revert ALL DCs in the AD forest to the exact same snapshot as that is the snapshot containing the state of all DCs that all DCs know about each other ==> because the generation ID process is disabled, nothing will happen with the SYSVOL as explained.
Boot up ALL DCs in the AD forest
Perform all required updates on either/both the DCs and/or AD
Shutdown ALL DCs in the AD Forest
For ALL DCs in the AD Forest, create the snapshot and give it a meaningful name with a date and time
Delete the previous/older VM snapshot

Cheers,

Jorge

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

IAMTEC

Identity | Security | Recovery

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

Posted in Active Directory Domain Services (ADDS), Backup And Restore, SYSVOL | Tagged: Active Directory, Disaster Recovery, Snapshots, SYSVOL | Leave a Comment »

« Previous Entries

Jorge's Quest For Knowledge!

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

For Ad Free Blog

Social Media

Profiles

Statistics

Other Cool Blogs

Interesting Places To Visit

The Knowledge Archives

RSS Links

Email Subscription

Categories

(2024-04-23) Breaking The Glass Of Your “Get-Out-Of-Jail-For-Free” AD Account – Introduction (Part 1)

(2024-02-07) Testing SYSVOL/File Replication Latency/Convergence Through PowerShell (Update 5)

(2024-02-07) Testing Active Directory Replication Latency/Convergence Through PowerShell (Update 5)

(2024-01-31) Testing SYSVOL/File Replication Latency/Convergence Through PowerShell (Update 4)

(2024-01-29) Testing Active Directory Replication Latency/Convergence Through PowerShell (Update 4)

(2023-06-16) Presenting At Troopers 2023

(2023-05-26) Presenting At Info Security 2023

(2023-05-19) Hybrid Identity Protection (HIP) 2023 Global Conference Coming In August

(2023-05-18) Test Environments, Snapshots And The SYSVOL Do Not Always Like Each Other (2)

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

For Ad Free Blog

Social Media

Profiles

Statistics

Other Cool Blogs

Interesting Places To Visit

The Knowledge Archives

RSS Links

Email Subscription

Categories

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this: