Microsoft supported backups of Active Directory are very important to have. For backing up Domain Controllers, this is typically a System State backup. Why a Microsoft supported backup? If you are using a backup solution …
The domain Kerberos service account, KRBTGT (https://adsecurity.org/?p=483), is an important account since it is used to sign & encrypt Kerberos tickets. The account is disabled and the password doesn’t change except when moving from Windows …
The Tombstone lifetime (TSL) in Active Directory is the limit as to how long a deleted object can remain in AD. The original value was 60 (days). Windows versions since Windows 2003 SP2 have this …
Ensuring proper Domain Controller configuration is key for Active Directory security. Part of this is making sure they are running supported versions of Windows. At this point, DCs should be running at least Windows Server …
In every Active Directory domain, there’s the default domain Administrator account. Here are some key items to check: PowerShell for current domain using the AD PowerShell cmdlets:
There are several different types of user accounts – at least how they are used. There are standard user accounts, service accounts, and admin accounts.
There are numerous user account settings that can make them vulnerable. These configurations include:
Inactive – account has not logged on or changed the password in over 180 days which may flag this account as inactive/stale – Accounts known to be inactive should be disabled.
Reversible encryption – effectively clear-text on DCs – there’s no reason for this to be set.
Password not required – account may not have an associated password – possibly set by provisioning system – There’s no reason for this to be set. * Password never expires – password very likely to be old – should not be set on standard user accounts.
Kerberos DES encryption enabled – DES is a weaker encryption method which enables faster password brute-forcing. There’s no reason for this to be set.
Account does not require Kerberos pre-authentication – enables a trivial attack method for discovering the account’s password (AS-REProasting). May have been set for a compatibility issue with an application. Kerberos pre-authentication should always be required.
Account cannot change password – password may not change. Standard user accounts should not have this set. Attackers will look for these configurations, so best to review and adjust regularly. Admin accounts and service accounts require additional protection above and beyond standard user accounts.
A critical part of Active Directory security is regularly reviewing your AD admins. The simplest way to do this is to recursively enumerate the membership of the domain Administrators group (that group’s members and all member group members).
Check the AD Admins output for the following:
Are all the admin accounts associated with people expected?
Are there service accounts that shouldn’t require AD admin rights (VMware, Exchange, LDAP, VPN, Sharepoint, etc.)?
Are the associated passwords current?
Are they as expected with no outliers (all within 2 years but one has a password that’s 10 years old)?
Has the default domain Administrator account logged on recently?
Is that expected/known?
Are all accounts enabled?
Disabled accounts should be removed from being an AD Admin.
Do all accounts require Kerberos preauthentication?
They must if they are AD admins.
Do any use Kerberos DES?
If so fix that.
Are any set to never expire their password?
Is that expected?
Accounts with this set rarely change their password.
Are there any passwords in Active Directory user attributes (commonly description notes/info, Exchange custom attributes, etc.)?
Practically all of the attributes are visible to users.
This article was originally posted on the Trimarc Content Hub on August 6, 2020. Updated here with authentication PowerShell code on August 18, 2025. ADSecurity.org is the new home for this article and all updates will occur here.
I have had the idea for a post describing how to best create a honeypot (or honeytoken) account for many years and only recently gained enough clarity around how to format and structure such an article for it to be useful. Shout-out to Carlos Perez (@Carlos_Perez) for a recent chat about Kerberoasting and the Detecting Kerberoast article I posted a while back which got me thinking enough about this to start writing.
This article covers how to create accounts used as honeypots (or honeytokens) that look like they provide something an attacker wants (access), but ultimately provides something the defender wants (detection). The focus is making honeypot accounts look normal and “real” in Active Directory and this premise should be somewhat portable to other systems.
AD Recon 101 I have previously covered AD recon in presentations (DEF CON 2016: Beyond the MCSE, Red-Teaming Active Directory), but provide expanded detail here focused on privileged AD account recon. When an attacker is performing reconnaissance of Active Directory, there are a few key items to review:
Identify Privileged Accounts
Identify Privileged Accounts with Old Passwords
Identify Privileged Accounts with Kerberos Service Principal Names (SPNs)
Identify Privileged Accounts with Network Sessions on Regular Workstations
In most Active Directory environments, we can scan the AD forest for all of these as a regular AD user (and in some cases without valid AD credentials).
1. Identify Privileged Accounts
Let’s start with #1. We can either recursively enumerate the Administrators group in every domain in the AD forest or we can scan all AD user accounts in each domain that have the user attribute “AdminCount” set to 1. I presented about how useful the AdminCount attribute can be in 2015 (DerbyCon – “Red vs Blue Active Directory Attack & Defense”).
The AdminCount attribute is automatically set to 1 on any AD accounts that are added to privileged AD groups such as Administrators, Domain Admins, Enterprise Admins, etc. The limiting factor in the usefulness of this technique is that we may also find accounts that used to be in a privileged AD group but no longer a member. This means that scanning for AD accounts with AdminCount=1 provides a quick list of potentially privileged accounts (without group enumeration).
A common method attackers leverage as well as many penetration testers and Red Teamers is called “password spraying”. Password spraying is interesting because it’s automated password guessing. This automated password guessing against all users typically avoids account lockout since the logon attempts with a specific password are performed against against every user and not one specific one which is what account lockout was designed to defeat. The attacker starts with a list list of passwords they’re going to try which starts with the most likely passwords (“Fall2017”, “Winter2018”, etc).
When password spraying begins, we start with the first password in the list. That first password is used in an attempt to authenticate as every user in Active Directory. This one password is attempted against each AD user and once all users have been tested with that password, we move on to the next one.
Since the Active Directory user lockout threshold is 5, we can try 4 different passwords for every user. Then we wait for >30 minutes (lockoutobservationwindow where the DCs keep the lockout count, after this it resets to 0), and try again. It’s trivial to gather the information about the AD environment’s password policy and have the password spraying tool automatically adjust to them.
Graphic shows the Domain Password Policy for the lab domain environment using the AD PowerShell cmdlet Get-ADDefaultDomainPasswordPolicy cmdlet.
This works most of the time because users have bad passwords (especially if the password policy includes a password minimum of <10 characters). Often password spraying connects to an SMB share or a network service, so let’s start with connections to the PDC’s netlogon share (\\PDC\NETLOGON) which is common on many networks. After password spraying has run for a while, we have discovered many user passwords, which may also include privileged accounts.
In early 2020, I published an article on how a Global Administrator could gain control of Azure resources, that no one would know about it, and how this access would persist even after removing them from Global Administrator.
From that article:
“While Azure leverages Azure Active Directory for some things, Azure AD roles don’t directly affect Azure (or Azure RBAC) typically. This article details a known configuration (at least to those who have dug into Azure AD configuration options) where it’s possible for a Global Administrator (aka Company Administrator) in Azure Active Directory to gain control of Azure through a tenant option. This is “by design” as a “break-glass” (emergency) option that can be used to (re)gain Azure admin rights if such access is lost. In this post I explore the danger associated with this option how it is currently configured (as of May 2020). The key takeaway here is that if you don’t carefully protect and control Global Administrator role membership and associated accounts, you could lose positive control of systems hosted in all Azure subscriptions as well as Office 365 service data.”
Elevated Access
There is a switch that can be flipped from “No” to “Yes” that allows a Global Administrator to gain “manage access to all Azure subscriptions and management groups in this directory”. Flipping this switch to Yes adds the current user to the Azure role User Access Administrator at the root level. Once this access is provided, the current user can then add themself to other roles like Subscription Admin. The graphic below shows this flow.
In May 2020, I presented some Active Directory security topics in a Trimarc Webcast called “Securing Active Directory: Resolving Common Issues” and included some information I put together relating to the security of AD Group Managed Service Accounts (GMSA). This post includes the expanded version of attacking and defending GMSAs I covered in the webcast. I put this information together after speaking with someone about using GMSAs running services on servers that have privileged AD rights and there was confusion about what GMSAs actually do and what they can’t. The confusion seemed to be rooted in the belief that GMSA credentials are protected more than regular accounts (they aren’t). The key benefit is that their passwords change automatically, not that the credential data has stronger protections.
This post is meant to highlight what GMSAs can do and what an attacker can do if not protected appropriately. We have seen limited usage of Group Managed Service Accounts in AD environments when we perform Active Directory Security Assessments at Trimarc. GMSAs should be used wherever possible to replace user accounts as service accounts since the passwords will rotate automatically.
Group Managed Service Accounts (GMSAs) User accounts created to be used as service accounts rarely have their password changed. Group Managed Service Accounts (GMSAs) provide a better approach (starting in the Windows 2012 timeframe). The password is managed by AD and automatically changed. This means that the GMSA has to have security principals explicitly delegated to have access to the clear-text password. Much like with other areas where delegation controls access (LAPS), determining who should have be delegated access needs to be be carefully considered.
Key Points for Group Managed Service Accounts (GMSAs) :
The GMSA password managed by AD.
Computers hosting GMSA service account(s) request current password from Active Directory to start service.
Configure the GMSA to allow computer accounts access to password.
If an attacker compromises computer hosting services using GMSA, the GMSA is compromised.
If attacker compromises an account with rights to request GMSA password, the GMSA is compromised.
Group Managed Service Accounts have the object class “msDS-GroupManagedServiceAccount” and associated attributes specific to GMSAs. These properties include:
msDS-GroupMSAMembership (PrincipalsAllowedToRetrieveManagedPassword) – stores the security principals that can access the GMSA password.
msds-ManagedPassword – This attribute contains a BLOB with password information for group-managed service accounts.
msDS-ManagedPasswordId – This constructed attribute contains the key identifier for the current managed password data for a group MSA.
msDS-ManagedPasswordInterval – This attribute is used to retrieve the number of days before a managed password is automatically changed for a group MSA.
Running the AD PowerShell cmdlet Get-ADServiceAccount, we can retrieve information about the GMSA, including specific GMSA attrbiutes. This GMSA is a member of the domain Administrators group which has full AD & DC admin rights to the domain. The screenshot shows that the password changed recently and won’t change for a few weeks – changed on 5/11/2020 and configured to change every 30 days. This means that if we can get the password for this account, we have almost a month to use the account credentials before it changes. We can also identify a group that can retrieve the password data. We’ll take a look at this is a bit.
For most of 2019, I was digging into Office 365 and Azure AD and looking at features as part of the development of the new Trimarc Microsoft Cloud Security Assessment which focuses on improving customer Microsoft Office 365 and Azure AD security posture. As I went through each of them, I found one that was very interesting.
While Azure leverages Azure Active Directory for some things, Azure AD roles don’t directly affect Azure (or Azure RBAC) typically. This article details a known configuration (at least to those who have dug into Azure AD configuration options) where it’s possible for a Global Administrator (aka Company Administrator) in Azure Active Directory to gain control of Azure through a tenant option. This is “by design” as a “break-glass” (emergency) option that can be used to (re)gain Azure admin rights if such access is lost. In this post I explore the danger associated with this option how it is currently configured (as of May 2020).
The key takeaway here is that if you don’t carefully protect and control Global Administrator role membership and associated accounts, you could lose positive control of systems hosted in all Azure subscriptions as well as Office 365 service data.
Note: Most of the research around this issue was performed during August 2019 through December 2019 and Microsoft may have incorporated changes since then in functionality and/or capability.
Attack Scenario: In this scenario, Acme has an on-premises Active Directory environment. Acme embraced Azure Infrastructure as a Service (IAAS) as an additional datacenter and deployed Domain Controllers to Azure for their on-prem AD (as their “cloud datacenter”). Acme IT locked down the DCs following hardening advice and limited Azure administration to the VMs hosting the DCs. Acme has other sensitive applications hosted on servers in Azure.
Acme signed up for Office 365 and started a pilot. All of the Active Directory and Exchange admins (and many other IT admins) are granted temporary Global Administrator (aka Global Admin or GA) rights to facilitate the pilot. So, more than should be there and not well protected.
Many are familiar with Active Directory, the on-premises directory and authentication system that is available with Windows Server, but exactly what is Azure Active Directory?
Azure Active Directory (Azure AD or AAD) is a multi-tenant cloud directory and authentication service. Azure AD is the directory service that Office 365 (and Azure) leverages for account, groups, and roles. It is also an Identity Provider (IPD) and supports federation (SAML, etc). Note: given how rapidly the cloud changes, elements of this post may become out of date soon after the original post date. Azure AD is highly available and globally deployed.
Azure AD is deployed in over 30 datacenters around the world leveraging Azure Availability Zones where present. This number is growing rapidly as additional Azure Regions are deployed.
For durability, any piece of data written to Azure AD is replicated to at least 4 and up to 13 datacenters depending on your tenant configuration. Within each data center, data is again replicated at least 9 times for durability but also to scale out capacity to serve authentication load. To illustrate—this means that at any point in time, there are at least 36 copies of your directory data available within our service in our smallest region. For durability, writes to Azure AD are not completed until a successful commit to an out of region datacenter.
This approach gives us both durability of the data and massive redundancy—multiple network paths and datacenters can serve any given authorization request, and the system automatically and intelligently retries and routes around failures both inside a datacenter and across datacenters.
To validate this, we regularly exercise fault injection and validate the system’s resiliency to failure of the system components Azure AD is built on. This extends all the way to taking out entire datacenters on a regular basis to confirm the system can tolerate the loss of a datacenter with zero customer impact. … Azure AD is already a massive system running on over 300,000 CPU Cores and able to rely on the massive scalability of the Azure Cloud to dynamically and rapidly scale up to meet any demand. This can include both natural increases in traffic, such as a 9AM peak in authentications in a given region, but also huge surges in new traffic served by our Azure AD B2C which powers some of the world’s largest events and frequently sees rushes of millions of new users. … To support the health checks that gate safe deployment and give our engineering team insight into the health of the systems, Azure AD emits a massive amount of internal telemetry, metrics, and signals used to monitor the health of our systems. At our scale, this is over 11 PetaBytes a week of signals that feed our automated health monitoring systems.
Azure Active Directory is Not Cloud AD Azure Active Directory is not Active Directory hosted in the cloud. There is no standard AD authentication methods such as NTLM or Kerberos; no LDAP; and no group policy (GPO), so Azure AD won’t work for traditional on-prem applications.
There are cloud hosted Active Directory environments that can be used to manage cloud workloads in Microsoft Azure (Azure Active Directory Domain Services), Amazon AWS (Amazon Managed Microsoft AD), and Google Cloud (Managed Service for Microsoft Active Directory (AD)). These are all hosted Microsoft Active Directory environments which have 2 Domain Controllers (or more) and the tenant admins do not receive Domain Admin rights to the hosted AD environment; only delegated access is provided which often includes the ability to create/manage resources in a specific OU and specific GPOs.
Note: I don’t have room to include a comparison of these services here, but may write a future post if there’s interest (I did some research comparing Microsoft Azure vs Amazon AWS hosted AD service offerings in 2017).
Primary Management Tools The tool that most AD administrators are familiar with is Active Directory Users and Computers aka ADUC (MMC tool).
Azure Active Directory administrators will primarily use the web console at https://portal.azure.com to administer the environment.
Admins that manage Active Directory on-prem and now Azure AD/Office 365 will be using the on-prem MMC tools as well as the web admin portals (and various URLs associated with them). There are PowerShell cmdlets available for managing Azure AD (similar to on-prem), though cloud features often move faster than the PowerShell tools are released, which means that using the cloud admin portal should still be used, even when using PowerShell.
Interfacing with Azure Active Directory Since Azure AD doesn’t have LDAP, interfacing with AAD involves connecting via the Graph API (or PowerShell modules). I like PowerShell, so I use the PowerShell modules (or Portal websites) for management and reporting.
There are 2 primary PowerShell modules for interfacing with Azure AD: MSOnline and AzureAD. These can be installed through the PowerShell install feature: Install-Module -Name MSOnline -Force Install-Module -Name AzureAD -Force
The AzureAD module may eventually replace the MSOnline PowerShell module, but there are features available in MSOnline that haven’t been ported to the Azure AD module (yet).
Attacking and Defending the Microsoft Cloud (Office 365 & Azure AD) Sean Metcalf (Trimarc) & Mark Morowczynski (Principal Program Manager, Microsoft)
The allure of the “Cloud” is indisputable. Organizations are moving into the cloud at a rapid pace. Even companies that have said no to the Cloud in the past have started migrating services and resources. The Cloud is a new paradigm and the rapid update pace makes it difficult to keep up, especially when it comes to security.
This presentation focuses on the Microsoft Cloud (Office 365 & Azure AD) and explores the most common attacks against the Cloud and describes effective defenses and mitigation. While the content is focused on the Microsoft Cloud, some of the attack and defense topics are applicable to other cloud providers and are noted where applicable.
Key items covered:
Attacks against the Cloud
Account compromise and token theft
Methods to detect attack activity
Cloud identity firewall
Securing cloud infrastructure against attacks
Secure cloud administration
There are no new features for Active Directory in Windows Server 2019 except one performance update which doesn’t affect most deployments. This update is related to an updated algorithm that better supports the ESE version store on DCs. Ryan Ries describes this on the Ask DS blog:
The intent of the first section of this article is to discuss how Active Directory’s sizing of the ESE version store has changed in Server 2019 going forward. The second section of this article will discuss some basic debugging techniques related to the ESE version store.
Active Directory, also known as NT Directory Services (NTDS,) uses Extensible Storage Engine (ESE) technology as its underlying database.
One component of all ESE database instances is known as the version store. The version store is an in-memory temporary storage location where ESE stores snapshots of the database during open transactions. This allows the database to roll back transactions and return to a previous state in case the transactions cannot be committed. When the version store is full, no more database transactions can be committed, which effectively brings NTDS to a halt.
In 2016, the CSS Directory Services support team blog, (also known as AskDS,) published some previously undocumented (and some lightly-documented) internals regarding the ESE version store. Those new to the concept of the ESE version store should read that blog post first.
In the blog post linked to previously, it was demonstrated how Active Directory had calculated the size of the ESE version store since AD’s introduction in Windows 2000. When the NTDS service first started, a complex algorithm was used to calculate version store size. This algorithm included the machine’s native pointer size, number of CPUs, version store page size (based on an assumption which was incorrect on 64-bit operating systems,) maximum number of simultaneous RPC calls allowed, maximum number of ESE sessions allowed per thread, and more.
Since the version store is a memory resource, it follows that the most important factor in determining the optimal ESE version store size is the amount of physical memory in the machine, and that – ironically – seems to have been the only variable not considered in the equation!
The way that Active Directory calculated the version store size did not age well. The original algorithm was written during a time when all machines running Windows were 32-bit, and even high-end server machines had maybe one or two gigabytes of RAM.
As a result, many customers have contacted Microsoft Support over the years for issues arising on their domain controllers that could be attributed to or at least exacerbated by an undersized ESE version store. Furthermore, even though the default ESE version store size can be augmented by the “EDB max ver pages (increment over the minimum)” registry setting, customers are often hesitant to use the setting because it is a complex topic that warrants heavier and more generous amounts of documentation than what has traditionally been available.
Recent Comments