Nov 04 2025

Active Directory Security Tip #14: Group Managed Service Accounts (GMSAs)

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 is managed by AD.
  • Computers hosting GMSA service account(s) request the current password from Active Directory to start the associated service.
  • Configure the GMSA to allow computer account(s) access to the GMSA password.
  • If an attacker compromises any computer hosting services using the GMSA, the GMSA is compromised.
  • If attacker compromises an account with rights to request the 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.

Lab Example

In order to identify GMSAs in an Active Directory domain, we can use the Active Directory PowerShell cmdlet “Get-ADServiceAccount”.

get-adserviceaccount -filter * -prop * | Select Name,DNSHostName,MemberOf,Created,LastLogonDate,PasswordLastSet,msDS-ManagedPasswordInterval,PrincipalsallowedtoDelegateToAccount,PrincipalsAllowedtoRetrieveManagedPassword,msDS-ManagedPassword,ServicePrincipalName | Sort Name

In my lab environment (mirroring what I’ve seen in real world AD environments), we notice that there is a GMSA in Domain Admins. Let’s dig into that one.

The Citrix GMSA is configured to allow the group “Citrix04” the ability to get the password for the GMSA (property “PrincipalsAllowedToRetrieveManagedPassword”). Now, let’s take a look at the membership of that group.


There’s a user account in that group which means compromise of that user account (AdminJackson) would result in the compromise of the password for the Citrix GMSA and that would result in the compromise of Active Directory since the GMSA is a member of Domain Admins.

I wanted to make it easier to get this information, so I wrote a PowerShell script called Get-GMSADetail that captures this information using the Active Directory PowerShell module. This adds a new property called “PasswordAccessPrincipalString which is a list of principals in the group that have the rights to pull the password.
The results are shown here:


Conclusion

As part of this lab exercise, we learned that if a GMSA is a member of a privileged group (like Domain Admins), compromise of an account that has rights to pull the clear-text password for the GMSA (property “PrincipalsAllowedToRetrieveManagedPassword”) can leverage the GMSA rights (like compromise Active Directory). Furthermore, if we can compromise one of the computer accounts that have the ability to pull the GMSA password, then we can dump the password from the computer.

For more information about attacking GMSAs, read the ADSecurity article “Attacking Active Directory Group Managed Service Accounts (GMSAs)“

Oct 19 2025

Improve Entra ID Security More Quickly

At BSides Northern Virginia (BSides NoVa) in October 2025, I presented a talk on how to improve Entra ID security quickly. This post captures the key information from my talk slides.

This article describes the Entra ID settings and configuration that should be set to improve security including:

  • User Default Configurations
  • Guest Defaults
  • User Applications Consent and Permissions
  • Secure Entra ID roles
  • Privileged Role Membership Protection
  • Role Assignable Group Configurations
  • Highly Privileged Applications
  • Conditional Access Policies
  • Partner Access
  • Securing Entra Connect
  • Secure Entra ID Quickly Checklist
Continue reading

Oct 12 2025

BSides NoVa 2025 Presentation Slides Posted


My BSides NoVA talk on Saturday, October 11, 2025 was titled “10 Ways to Improve Entra ID Security Quickly“. I focused on the areas that tend to be missed in Entra ID.
Talk slides are now posted.


Downoad Presentation Slides

Oct 11 2025

Microsoft Interview

A couple years ago, the Microsoft Security Experts Blog interviewed me regarding Azure Active Directory (Entra ID) security.


Read the Interview here

Oct 08 2025

Active Directory Security Tip #13: Reviewing Foreign Security Principals (FSPs)

Review the membership of groups for accounts and groups from another Active Directory forest (technically another domain, but using forest here). These are called “Foreign Security Principals” (FSPs) like the ones highlighted in the image. These FSPs are accounts that exist in another forest but have rights in the AD forest.

Any FSPs should be scrutinized and removed if not required. It’s important to review and strictly control these since they may be highly privileged. In this example, compromise of another AD forest (TRDNET) would result in compromise of the current AD forest (Trd.com).


PowerShell script to scan privileged groups for FSPs:
https://github.com/PyroTek3/Misc/blob/main/Invoke-FindPrivilegedFSPs.ps1

Oct 06 2025

Active Directory Security Tip #12: Kerberos Delegation

I have mentioned in several presentations that Kerberos delegation is impersonation. Kerberos delegation is used when a service (ex. web server) needs to impersonate a user when connecting to a resource (ex. database).

There are a 4 types of Kerberos delegation:

Unconstrained delegation should be converted to constrained delegation due to security concerns. Any Kerberos delegation that is no longer required should be removed. If there’s no associated Kerberos service principal name, Kerberos authentication isn’t working and this should be fixed or removed.

PowerShell code using the Active Directory PowerShell module:
https://github.com/PyroTek3/Misc/blob/main/Get-ADKerberosDelegation.ps1

Oct 04 2025

The History of Active Directory Security

During the Summer of 2024, I had a talk at Troopers called “A Decade of Active Directory Attacks:
What We’ve Learned & What’s Next” (Slides & Video) where I focused on the key milestones of Active Directory security (history). This article covers my “decade of Active Directory attacks” in some detail which was correlated with public information and GitHub release information. This Active Directory security history article breaks down the notable attacks into a timeline starting with Active Directory’s release in 2000 and continuing until the present day in late 2025.
If you are interested in the history of Active Directory, this is the article for you.

If you have anything to add or update on the History of Active Directory Security, please email me: sean[@]adsecurity[dot]org.

“Baby Steps” (2000 – 2009)

We start with a time period I call “Baby Steps” (2000 – 2009). This is where some of the key attack capability still in use today was developed.

April, 1997: Paul Ashton posted to NTBugtraq about “‘Pass the Hash’ with Modified SMB Client” leveraging the username and LanMan hash against Windows NT.

February 17, 2000: Active Directory released as part of Windows 2000 (RTM was December 5, 1999 while retail release was February 17, 2000).

March, 2001: Sir Dystic of Cult of the Dead Cow (cDc) releases SMBRelay and SMBRelay2.

2007: NBNSpoof tool created by Robert Wesley McGrew (LLMNR/NBT-NS).

July 2008: Hernan Ochoa publishes the “Pass-the-Hash Toolkit“ (later called WCE and was the inspiration for Mimikatz).

Continue reading

Oct 03 2025

Active Directory Security Tip #11: Print Service on Domain Controllers

The Print Spooler service is a default service on Windows Servers and is set to run at startup. There are a number of attacks that are enabled by having the Print Spooler service running on Domain Controllers (ex.: Printer Bug: https://adsecurity.org/?p=4056)


At this point it’s best to configure a GPO to disable the Print Spooler service on Domain Controllers (2nd & 3rd screenshot show the GPO settings). There shouldn’t be anything affected by this change. No one should be using their Domain Controller as a print server and the only thing this service does by default is manage automatic Printer object pruning, but there needs to be a GPO to configure this. We have only seen this a total of 2 times over 8 years of performing Active Directory Security Assessments (ADSAs)


PowerShell code to check if the Print Spooler service is running in the current domain (requires DC admin rights, so domain Administrator or equivalent): 

$Domain = $env:userdnsdomain
$DomainDC = (Get-ADDomainController -Discover -DomainName $Domain).Name

$DomainDCs = Get-ADDomainController -Filter * -Server $DomainDC | Sort HostName 
ForEach ($DomainDCItem in $DomainDCs) 
 { 
     $ServiceStatusArray = Get-service -Name 'spooler' -ComputerName $DomainDCItem.HostName 
     switch ($ServiceStatusArray.Status) 
      { 
         "Running" { Write-host "$($DomainDCItem.HostName): Print Spooler Service is RUNNING" -ForegroundColor Red } 
         "Stopped" { Write-host "$($DomainDCItem.HostName): Print Spooler Service is stopped" -ForegroundColor Green } 
         default { Write-host "$($DomainDCItem.HostName): Test failed" -ForegroundColor Yellow } 
      } 
 }

Oct 01 2025

Active Directory Security Tip #10: FSMO Roles

Getting Microsoft supported backups of Domain Controllers is an important part of recovery strategy.

A best practice is to locate all Flexible Master Single Operator (FSMO) roles on a single DC in the domain. That way you can more easily target the DC that hosts the FSMOs for backup.


PowerShell code to check for FSMO role holders for the forest & current domain: 

$ADForestArray = Get-ADForest 
$ADForestArray | Select-Object SchemaMaster,DomainNamingMaster 
ForEach ($ADForestArrayDomain in $ADForestArray.Domains)
 {
    $DomainDC = (Get-ADDomainController -Discover -DomainName $ADForestArrayDomain).Name
    Get-ADDomain -Server $DomainDC | Select-Object PDCEmulator,RIDMaster,InfrastructureMaster
 }

Sep 29 2025

Active Directory Security Tip #9: Active Directory Backups

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 that isn’t fully AD aware, performing a restore may involve getting Microsoft involved and that costs $$.

I know companies that have used ####### (redacted) to backup their AD and there was no System State and the backup wasn’t a full AD aware backup so they ended up paying ###### $$$ and Microsoft $$$. Just get a System State backup of the DCs that host your FSMO roles about every month and be prepared for a scenario where you may have to restore AD.

Determining if a recent supported backup has been performed is easy since these backups update a bit in each partition.


PowerShell code to check the current domain for the last Microsoft supported AD backup: 

$ContextType = [System.DirectoryServices.ActiveDirectory.DirectoryContextType]::Domain
$Context = New-Object System.DirectoryServices.ActiveDirectory.DirectoryContext($ContextType,(Get-ADDomain).DNSRoot)
$DomainController = [System.DirectoryServices.ActiveDirectory.DomainController]::findOne($Context)
    
[string[]]$Partitions = (Get-ADRootDSE).namingContexts
 foreach ($Partition in $Partitions) 
  {
    $dsaSignature = $DomainController.GetReplicationMetadata($Partition).Item("dsaSignature")
    Write-Host "$Partition was backed up $($dsaSignature.LastOriginatingChangeTime.DateTime)" 
   }

Load more