Active Directory Service Account Discovery: Building the Complete Inventory PAM Vendors Assume You Already Have
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
The CyberArk implementation guide, the Delinea onboarding checklist, and every PAM vendor's professional services team will ask the same question in the first project meeting: how many privileged accounts do you have? The honest answer in most enterprises is: we do not know.
PAM vendors assume you arrive with a documented service account inventory. In practice, the discovery project begins on day one of the PAM engagement and regularly extends the timeline by four to eight weeks. The accounts that surface during discovery fall into categories: vendor-created accounts with no internal owner, accounts named after developers who left three years ago, application accounts embedded in scheduled tasks that no one has touched since Windows Server 2012, and gMSA accounts that will break if a third-party vault tries to rotate them.
This guide covers the four discovery methods that together produce a complete service account inventory, the risk signals that determine vault onboarding priority, and the documentation template that PAM onboarding actually requires.
Method 1: SPN-based discovery
Service Principal Names are registered on accounts that authenticate to network services. Any account with an SPN set is almost certainly a service account used by an application or service that relies on Kerberos authentication.
PowerShell query: Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName, LastLogonDate, PasswordNeverExpires, PasswordLastSet, Description, MemberOf | Select-Object Name, SamAccountName, ServicePrincipalName, LastLogonDate, PasswordNeverExpires, PasswordLastSet, Description | Export-Csv -Path C:\discovery\spn_accounts.csv -NoTypeInformation
For computer accounts with SPNs (SQL server service accounts registered under machine accounts): Get-ADComputer -Filter * -Properties ServicePrincipalName | Where-Object {$_.ServicePrincipalName -ne $null} | Select-Object Name, ServicePrincipalName
Priority signals to flag: PasswordNeverExpires = True combined with PasswordLastSet older than 365 days. These accounts have persistent, non-rotating credentials and are typically the highest-value targets for Kerberoasting attacks that can lead to DCSync and golden ticket credential compromises.
Method 2: PasswordNeverExpires sweep
Many service accounts are created without SPNs but are still application accounts exempt from the standard password policy. The PasswordNeverExpires attribute is the clearest operational signal.
PowerShell query: Get-ADUser -Filter {PasswordNeverExpires -eq $true -and Enabled -eq $true} -Properties PasswordNeverExpires, PasswordLastSet, LastLogonDate, Description, ServicePrincipalName, MemberOf | Select-Object Name, SamAccountName, PasswordLastSet, LastLogonDate, Description | Export-Csv -Path C:\discovery\pne_accounts.csv -NoTypeInformation
This list will include human user accounts whose administrators disabled password expiration as a convenience measure. Filter out accounts in the standard Users container whose PasswordLastSet aligns with recent quarterly resets. Accounts with PasswordLastSet older than 2 years and LastLogonDate recent are your service accounts.
Note: a high LastLogonDate combined with an old PasswordLastSet is the clearest service account fingerprint. The account is actively used by an application but has never had its password changed.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Method 3: Naming pattern discovery
The majority of deliberately created service accounts follow naming conventions: svc_, sa_, _svc, service, app, or the application name prefixed to a common suffix. These accounts may not have SPNs or PasswordNeverExpires set but are still application credentials.
PowerShell query: Get-ADUser -Filter {(Name -like "svc_") -or (Name -like "svc") -or (Name -like "sa") -or (Name -like "service") -or (SamAccountName -like "svc")} -Properties PasswordLastSet, LastLogonDate, PasswordNeverExpires, ServicePrincipalName, Description | Export-Csv -Path C:\discovery\naming_accounts.csv -NoTypeInformation
For non-standard naming, pull all accounts whose Description field contains application or service references: Get-ADUser -Filter {Description -like "application" -or Description -like "service account" -or Description -like "automated"} -Properties Description, PasswordLastSet
Combine all three CSV outputs and deduplicate on SamAccountName to produce the consolidated inventory before adding gMSA accounts.
Method 4: gMSA and DSMA enumeration
Group Managed Service Accounts require separate enumeration because they are not standard ADUser objects. gMSAs have automatic password management by Active Directory, which means a third-party PAM vault cannot rotate them using the same mechanism as standard accounts. Onboarding gMSAs requires configuring the PAM platform to read the current password from AD rather than manage rotation directly.
Enumerate gMSAs: Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword, ServicePrincipalNames, LastLogonDate | Select-Object Name, SamAccountName, ServicePrincipalNames, PrincipalsAllowedToRetrieveManagedPassword
For each gMSA, document which computers or groups are in PrincipalsAllowedToRetrieveManagedPassword. This is the access control list for who can retrieve the password from AD. If your PAM platform's service account is not in this group, vault reads of the gMSA password will fail.
Keyboard Standalone MSAs (sMSA) follow the same pattern: Get-ADServiceAccount -Filter {ObjectClass -eq 'msDS-ManagedServiceAccount'}
Classification and documentation template
After consolidating the four discovery outputs, each account needs a minimum set of documentation fields before vault onboarding can proceed. Missing any of these fields blocks the onboarding workflow.
Required fields per account: Account Name (SamAccountName), Account Type (standard AD user, gMSA, sMSA), Associated Application or Service (what uses this account), System Owner (team or individual responsible), Target Systems (which servers or services the account authenticates against), Password Last Changed, Rotation Safe (yes/no, with explanation if no), Vault Priority (High/Medium/Low based on privilege level and exposure).
Rotation Safe requires specific investigation for each account. Service accounts embedded in IIS application pool identity, COM+ component identity, SQL Server Agent jobs, or Windows Scheduled Tasks often have the account credentials stored in a configuration file, registry key, or task definition. Before PAM can rotate the password, all credential storage locations must be identified and updated as part of the rotation script. Marking an account Rotation Safe requires confirming that the rotation mechanism covers all storage locations.
Accounts that cannot be made Rotation Safe (vendor-managed application accounts, accounts where the vendor does not support password change without reinstallation) should be documented with a compensating control: network isolation, privileged access workstation enforcement, or session monitoring. Use BloodHound to visualize which of these accounts sit on attack paths toward Domain Admins, so you can prioritize compensating controls for the highest-risk accounts first.
The bottom line
The four discovery methods combined (SPN sweep, PasswordNeverExpires sweep, naming pattern match, gMSA enumeration) produce a complete service account inventory in two to three days for most enterprise environments. The documentation phase, particularly determining what each account is used for and whether rotation is safe, takes four to six weeks and is the actual cause of privileged access management deployment delays. Starting discovery before vendor selection, rather than after, compresses the overall project timeline significantly.
Frequently asked questions
How many service accounts should I expect to find in an Active Directory environment?
The ratio varies widely but a common benchmark is 1 service account per 10 enabled user accounts in mid-market environments. In enterprise environments with significant application portfolios, the ratio often reaches 1 service account per 5 users. A 5,000-user organization should plan to discover between 500 and 1,000 service accounts, though the number that require active management by a PAM platform is typically lower after filtering out gMSAs (which manage themselves) and accounts tied to deprecated applications.
Can a PAM platform rotate gMSA passwords?
No. Group Managed Service Accounts have their passwords managed automatically by Active Directory Domain Services, and the password is only retrievable by computers or service principals listed in PrincipalsAllowedToRetrieveManagedPassword. PAM platforms can read and store the current gMSA password for session recording and access control purposes, but they cannot rotate gMSA passwords because the rotation mechanism is internal to AD. CyberArk, Delinea, and BeyondTrust all support gMSA monitoring but not rotation.
What is the fastest way to find service accounts that have never had their password changed?
Run: Get-ADUser -Filter {PasswordNeverExpires -eq $true -and Enabled -eq $true} -Properties PasswordLastSet, WhenCreated | Where-Object {$_.PasswordLastSet -eq $_.WhenCreated} | Sort-Object PasswordLastSet. Accounts where PasswordLastSet equals WhenCreated have had their password set exactly once, at account creation. These are the highest-priority accounts for PAM onboarding because they represent the longest credential exposure window.
What information does a PAM platform need to onboard a service account?
PAM onboarding documentation typically requires: account name and domain, the application or service that uses the account, the server or servers where the service runs, the application owner and a backup contact, the password rotation method (manual, automatic, or gMSA), any known dependencies (scheduled tasks, services, IIS app pools, or COM+ applications using this account), and whether the account's password can be rotated without a service restart. Missing the dependencies field causes rotation-triggered outages. Build this inventory before starting the PAM project, not during onboarding.
How do I find service accounts used in Windows scheduled tasks?
Run: Get-ScheduledTask | Where-Object {$_.Principal.UserId -notlike 'SYSTEM' -and $_.Principal.UserId -notlike 'NETWORK SERVICE' -and $_.Principal.UserId -ne $null} | Select-Object TaskName, TaskPath, @{n='RunAs';e={$_.Principal.UserId}} | Export-Csv scheduled_tasks_accounts.csv. This outputs all scheduled tasks running as a named account rather than a built-in service identity. Do the same for services: Get-WmiObject Win32_Service | Where-Object {$_.StartName -notlike '*LocalSystem*' -and $_.StartName -notlike '*NetworkService*'} | Select-Object Name, StartName. Run on every server class in scope.
What do I do with service accounts discovered during the pre-PAM audit?
Categorize discovered service accounts into three tiers: (1) candidates for Group Managed Service Accounts (gMSA) — any service account running Windows services on domain-joined servers where the application supports gMSA; migrate these first as gMSA eliminates password management entirely. (2) Candidates for PAM vaulting — accounts that cannot use gMSA (legacy applications, scheduled tasks, cross-system accounts); onboard these to your PAM vault for rotation and checkout. (3) Decommission candidates — accounts running no active services or with no recent password use; disable and delete after confirming no dependencies. Document the owner, system, and service function for each account before making any changes.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.