Enterprise Identity Catalog
Every Service Account
Type — Explained
A comprehensive reference covering all nine categories of non-human accounts used in enterprise environments: purpose, privilege level, rotation complexity, and how Delinea's platform manages each one.
9
Account Types
4
Risk Tiers
🛡 Why Service Account Security Matters
Service accounts represent the largest and most overlooked attack surface in enterprise environments. They often have elevated privileges, rarely-rotated passwords, and run unmonitored 24/7. A compromised service account can enable lateral movement across an entire environment.
🔄 The Delinea Approach
Delinea's Secret Server and Privilege Manager platforms provide vaulting, automatic rotation, session recording, and just-in-time access across all account types — from traditional Windows service accounts to ephemeral cloud workload identities and Kubernetes service accounts.
📋 Using This Reference
Expand each account type to see: purpose & use cases, privilege level justification, rotation complexity, associated risks, and specific Delinea capabilities. Use the filter chips above to sort by privilege tier, or search by name or technology.
Privilege Key
Critical
High
Medium
Low
Rotation
Complex
Moderate
Simple
Automated
Service Account Types
9 ENTRIESWindows Service Accounts
Domain User · Standard SA · NT Service
▾
Overview
Risks
Delinea
📋 Purpose & Use Cases
Domain user accounts repurposed as service identities for Windows services (svchost-based, Win32 services). Used when a service must authenticate to domain resources — file shares, databases, directory services, or other Kerberos-aware endpoints. Examples include Exchange Transport, backup agents, monitoring services, and AV engines.
📊 Specifications
| Account Format | DOMAIN\svc-appname or svc-appname@domain.com |
| Auth Protocol | Kerberos (preferred), NTLM fallback |
| Logon Type | Service logon (type 5); not interactive |
| Password Policy | Custom — often "never expires" (high risk) |
| SPN Required | Yes, for Kerberos delegation |
| AD Object | Yes — standard User class object |
🔄 Rotation Complexity — Why It's Hard
Rotating a Windows service account password requires: (1) updating the AD password, (2) updating the Services Control Manager entry on every server that runs the service, (3) restarting the service — often during a maintenance window. If the password is hardcoded in config files, additional files must be updated. Any service not restarted post-rotation immediately fails. Delinea automates this entire chain via its Service Account Discovery and Dependency Mapping engine.
⚠ Associated Risk Factors
⬤ Password Never Expires
⬤ Kerberoastable SPNs
⬤ Lateral Movement Vector
⬤ Over-privileged AD Rights
⬤ Manual Rotation Drift
⬤ Service Dependency Sprawl
Kerberoasting is the most critical risk: attackers request a Kerberos TGS ticket for any account with an SPN and attempt offline cracking. Service accounts with SPNs and weak passwords are high-value targets. Attackers with a cracked service account can move laterally across the domain using the account's existing permissions.
🛡 Hardening Controls
• Enforce 20+ character random passwords
• Apply "Deny log on locally" GPO
• Enable "Account is sensitive" AD flag
• Restrict to specific service hosts via ACL
• Audit all logon events (Event ID 4624/4625)
• Prefer gMSA where technically possible
• Apply "Deny log on locally" GPO
• Enable "Account is sensitive" AD flag
• Restrict to specific service hosts via ACL
• Audit all logon events (Event ID 4624/4625)
• Prefer gMSA where technically possible
🎯 MITRE ATT&CK Techniques
• T1558.003 — Kerberoasting
• T1078.002 — Valid Domain Accounts
• T1550.003 — Pass-the-Ticket
• T1021.002 — SMB/Windows Admin Shares
• T1134 — Access Token Manipulation
• T1078.002 — Valid Domain Accounts
• T1550.003 — Pass-the-Ticket
• T1021.002 — SMB/Windows Admin Shares
• T1134 — Access Token Manipulation
D
Delinea Management Secret Server
Delinea Secret Server vaults Windows service account credentials and automates the full rotation lifecycle — including dependency discovery, password push to all dependent services, and automatic service restart. No maintenance windows required for most service types.
Credential Vaulting
Passwords stored encrypted in Secret Server vault; removed from config files and Group Policy Preferences
Auto Rotation
Scheduled or event-triggered rotation with automatic push to Windows Service Control Manager on all hosts
Dependency Mapping
Discovers all services, scheduled tasks, and IIS pools using the account before rotation — prevents outages
IIS Application Pool Identities
IIS AppPool · ApplicationPoolIdentity · Network Service
▾
Overview
Risks
Delinea
📋 Purpose & Use Cases
IIS application pools run web applications in isolated worker processes (w3wp.exe). Each pool runs under a specific identity that determines what system and network resources the application can access. Built-in options include ApplicationPoolIdentity (virtual account, preferred), Network Service, Local Service, Local System, or a custom domain account. Custom accounts are required for database access, file share access, or Kerberos impersonation.
📊 Specifications
| Built-in Types | ApplicationPoolIdentity, NetworkService, LocalSystem, LocalService |
| Custom Account | Domain user; IIS grants "Log on as service" |
| Process | w3wp.exe — one per app pool |
| Isolation | Pool boundary — each pool is a separate process |
| Delegation | Kerberos constrained delegation for downstream auth |
| Config Location | applicationHost.config / IIS Manager |
🏗 Identity Type Selection Guide
ApplicationPoolIdentity — Best for apps needing only local resources. Auto-created virtual account with no password to manage.
NetworkService / LocalService — Built-in accounts for limited network access (authenticates as MACHINE$). Avoid for production web apps.
Custom Domain Account — Required for database connections via Windows Auth, UNC file shares, or Kerberos delegation chains. Highest operational overhead.
NetworkService / LocalService — Built-in accounts for limited network access (authenticates as MACHINE$). Avoid for production web apps.
Custom Domain Account — Required for database connections via Windows Auth, UNC file shares, or Kerberos delegation chains. Highest operational overhead.
⚠ Risk Factors
⬤ Web App Compromise → Credential Theft
⬤ Overly Permissive Pool Account
⬤ Shared Pool Across Apps
⬤ Kerberos Delegation Misconfiguration
If a web application is compromised (RCE, SSRF), the attacker inherits the pool account's identity. If this is a privileged domain account with database or file share access, the blast radius is significant. Always apply least privilege to pool accounts and never run multiple applications under a single privileged pool identity.
🛡 Hardening Controls
• Prefer ApplicationPoolIdentity over domain accounts
• Separate pool per application (no shared identities)
• Constrained delegation only — never unconstrained
• Restrict pool account to minimal DB/share permissions
• Enable IIS request filtering and WAF policies
• Monitor w3wp.exe child process spawning (T1059)
• Separate pool per application (no shared identities)
• Constrained delegation only — never unconstrained
• Restrict pool account to minimal DB/share permissions
• Enable IIS request filtering and WAF policies
• Monitor w3wp.exe child process spawning (T1059)
🎯 Common Attack Vectors
• Web shell → pool account NTLM relay
• SSRF → internal service auth using pool identity
• Unconstrained delegation abuse
• config file credential exposure (conn strings)
• T1078.001 — Default / built-in account abuse
• SSRF → internal service auth using pool identity
• Unconstrained delegation abuse
• config file credential exposure (conn strings)
• T1078.001 — Default / built-in account abuse
D
Delinea Management Secret Server · Privilege Manager
Delinea discovers IIS app pool custom accounts, vaults their credentials, and performs coordinated rotation — automatically updating the IIS applicationHost.config and recycling affected app pools. Connection strings in web.config are also managed via the Dependency Handler framework.
IIS Discovery
Auto-discovers app pool identities across IIS servers in scope; links to corresponding Secret
Zero-Downtime Rotation
Password change + applicationHost.config update + graceful app pool recycle in a single atomic operation
Config File Handler
Updates connection strings in web.config, appsettings.json, and custom XML configs as part of the rotation workflow
SQL Server Service Accounts
SQLServer · SQLAgent · SSRS · SSIS · SSAS
▾
Overview
Risks
Delinea
📋 Purpose & Use Cases
SQL Server uses multiple service accounts per instance: the Database Engine (MSSQLSERVER), SQL Server Agent (job scheduler), Reporting Services, Integration Services, Analysis Services, and the SQL Server Browser. Each has distinct functions and privilege requirements. The Database Engine account effectively controls access to all data on the instance.
📊 Specifications
| DB Engine Account | Local System / MSA / gMSA / Domain User |
| SQL Agent | Separate account; member of sysadmin by default (risk) |
| Cluster Accounts | Must be domain users for Windows Failover Cluster |
| AlwaysOn AG | Endpoint permissions between replica accounts |
| Linked Servers | Credential context forwarded via delegation |
| Preferred Type | gMSA for engine + agent (SQL 2014+) |
🔄 Why SQL Rotation Is the Most Complex
SQL Server tightly binds the service account to internal system objects: SPNs for Kerberos auth, database mirroring endpoints, linked server credentials, and replication publishers. Changing the account without using SQL Server Configuration Manager (not just Services SCM) leaves these bindings broken. In clustered environments, the account must have specific cluster permissions. Delinea handles this via SQL-specific rotation scripts that use Configuration Manager APIs.
⚠ Risk Factors
⬤ sysadmin Privilege Escalation
⬤ xp_cmdshell OS Access
⬤ Linked Server Credential Hop
⬤ SQL Agent Job Code Execution
⬤ SPN Misconfiguration → NTLM Downgrade
A compromised SQL Server service account with sysadmin rights can execute OS commands via xp_cmdshell, read Windows credential stores, and pivot to other systems via linked servers. SQL Server Agent jobs running as privileged proxy accounts are a common lateral movement path. Post-exploitation frameworks specifically target SQL Server for this reason.
🛡 Hardening Controls
• Use gMSA for SQL Engine where possible
• Separate account per SQL service type
• Remove SQL Agent from sysadmin role
• Disable xp_cmdshell; audit if re-enabled
• Audit linked server credentials
• Enable SQL Audit for privileged operations
• Use SQL Server Transparent Data Encryption
• Separate account per SQL service type
• Remove SQL Agent from sysadmin role
• Disable xp_cmdshell; audit if re-enabled
• Audit linked server credentials
• Enable SQL Audit for privileged operations
• Use SQL Server Transparent Data Encryption
🎯 MITRE ATT&CK Techniques
• T1505.001 — SQL Stored Procedures
• T1059.003 — xp_cmdshell (cmd execution)
• T1078.002 — Valid Domain Accounts
• T1210 — Exploitation of Remote Services
• T1484 — Domain Policy Modification (via sysadmin)
• T1059.003 — xp_cmdshell (cmd execution)
• T1078.002 — Valid Domain Accounts
• T1210 — Exploitation of Remote Services
• T1484 — Domain Policy Modification (via sysadmin)
D
Delinea Management Secret Server
Delinea includes SQL Server-specific rotation templates that invoke SQL Server Configuration Manager APIs, properly rebind SPNs, update linked server credentials, and restart only the necessary services — across standalone, clustered, and AlwaysOn Availability Group configurations.
SQL Config Manager
Uses official SQMCO API — not just SCM — to safely rotate accounts without breaking cluster state or SPNs
AlwaysOn Support
Coordinates rotation across all availability group replicas; validates replica connectivity post-rotation
Privileged Auditing
Records all sysadmin-level SQL sessions; alerts on xp_cmdshell execution and unusual linked server queries
Scheduled Task Accounts
Windows Task Scheduler · GPO Scripts · Batch Logon
▾
Overview
Risks
Delinea
📋 Purpose & Use Cases
Windows Task Scheduler runs scripts, executables, and PowerShell jobs on a schedule under a configured user account. Accounts range from SYSTEM (no credentials needed) to domain users (credentials stored by the Task Scheduler service). Common uses: backup jobs, log rotation, report generation, AD sync scripts, monitoring agents, and license reconciliation.
📊 Specifications
| Logon Type | Batch logon (type 4) — no interactive session |
| Credential Storage | LSA secrets store (HKLM\SECURITY hive) |
| Managed By | Task Scheduler (schtasks.exe) or Group Policy |
| SYSTEM Tasks | No password — use for local-only operations |
| Run Level | Highest Privileges flag vs. limited user |
| GPP Risk | Legacy GPO preferences stored credentials in SYSVOL (deprecated) |
🔄 The Hidden Problem: Account Sprawl
Organizations typically have hundreds to thousands of scheduled tasks across their estate, many referencing service accounts that are shared, undocumented, or long since forgotten. When the password for a shared account is rotated, all dependent tasks fail silently — often not discovered until a critical batch job misses a run. Delinea's task dependency scanner identifies all scheduled task dependencies before any rotation event.
⚠ Risk Factors
⬤ LSA Secrets Extraction (Mimikatz)
⬤ Shared Accounts Across Tasks
⬤ Undocumented Task Sprawl
⬤ "Highest Privileges" Misconfiguration
⬤ SYSVOL GPP Credential Exposure
Scheduled task credentials stored in the LSA secrets store are extractable by any process running as SYSTEM or with SeBackupPrivilege. Mimikatz and similar tools trivially dump these. Additionally, attackers frequently use scheduled tasks for persistence — registering new tasks under existing service account names to blend into legitimate activity.
🛡 Hardening Controls
• Use SYSTEM or service accounts — not user accounts
• Never use "Run as highest privileges" for untrusted scripts
• Audit Task Scheduler event log (Event ID 106, 200, 201)
• Remove all GPO Preferences passwords (MS14-025)
• Review task XML for embedded credentials
• Limit account to minimal required permissions
• Never use "Run as highest privileges" for untrusted scripts
• Audit Task Scheduler event log (Event ID 106, 200, 201)
• Remove all GPO Preferences passwords (MS14-025)
• Review task XML for embedded credentials
• Limit account to minimal required permissions
🎯 Attacker Techniques
• T1053.005 — Scheduled Task persistence
• T1552.004 — LSA Secrets dump (Mimikatz)
• T1552.006 — Group Policy Preferences creds
• T1078.002 — Valid domain account reuse
• T1036.003 — Masquerading as legitimate tasks
• T1552.004 — LSA Secrets dump (Mimikatz)
• T1552.006 — Group Policy Preferences creds
• T1078.002 — Valid domain account reuse
• T1036.003 — Masquerading as legitimate tasks
D
Delinea Management Secret Server
Delinea discovers all scheduled tasks across a domain or OU using WMI/RPC scanning, maps each task to its service account Secret, and executes coordinated rotation: password change → schtasks credential update → validation run to confirm task still executes successfully.
Task Discovery
WMI-based scanner discovers all scheduled tasks referencing managed accounts across all in-scope servers
Coordinated Rotation
Updates task credentials via Task Scheduler API simultaneously with AD password change — zero-failure window
Post-Rotation Validation
Optionally triggers a test run of the task post-rotation and alerts if execution fails within the next schedule window
Managed Service Accounts (MSA / gMSA)
sMSA · gMSA · KDS Root Key · AD-Managed Password
▾
Overview
Risks
Delinea
📋 Purpose & Use Cases
MSA (sMSA) and gMSA are AD-managed service account types where Active Directory owns and rotates the password automatically every 30 days. No human ever knows the password. gMSA extends sMSA to support multiple hosts, making it ideal for web farms, clusters, and load-balanced services. The KDS Root Key enables AD to derive unique 240-character passwords per gMSA.
📊 Specifications
| Password Length | 240 characters (cryptographically random) |
| Rotation Frequency | Automatic, every 30 days (configurable) |
| Multi-host (gMSA) | Yes — defined PrincipalsAllowedToRetrieve |
| Interactive Logon | Not supported (by design) |
| Min DC Level | gMSA: Windows Server 2012+ |
| KDS Root Key | Required (domain-wide, created once) |
💡 sMSA vs. gMSA at a Glance
sMSA (Standalone MSA) — Bound to a single computer object. Simple to deploy; no KDS Root Key required (Server 2008 R2+). Ideal for single-server services.
gMSA (Group MSA) — Supports a security group of computer principals. KDS Root Key required. Best for clustered, load-balanced, and multi-server deployments. The gold standard for new service account deployments where the application supports it.
gMSA (Group MSA) — Supports a security group of computer principals. KDS Root Key required. Best for clustered, load-balanced, and multi-server deployments. The gold standard for new service account deployments where the application supports it.
⚠ Residual Risk Factors
⬤ PrincipalsAllowed Group Overpopulation
⬤ gMSA Still Kerberoastable
⬤ No Password to Steal (mitigated)
⬤ Application Compatibility Limits Use
While gMSA dramatically reduces credential theft risk, the PrincipalsAllowedToRetrieveManagedPassword group must be tightly controlled. Any computer in this group can retrieve the effective password via AD. Additionally, gMSA accounts with SPNs can still be Kerberoasted — offline cracking of 240-char random passwords is infeasible, but the ticket can still be requested if the account has SPNs.
🛡 Best Practices
• Minimize PrincipalsAllowedToRetrieve group
• Audit gMSA group membership quarterly
• Monitor gMSA SPN registration (DCSync risk)
• Use gMSA for SQL Engine + Agent where possible
• Document KDS Root Key backup/recovery procedure
• Plan application compatibility testing for migration from Standard SA
• Audit gMSA group membership quarterly
• Monitor gMSA SPN registration (DCSync risk)
• Use gMSA for SQL Engine + Agent where possible
• Document KDS Root Key backup/recovery procedure
• Plan application compatibility testing for migration from Standard SA
📋 Application Compatibility Checklist
App must: (1) support service accounts with no stored password, (2) not use hardcoded credentials in config files, (3) not use interactive logon, (4) run on Windows Server 2012+ hosts, (5) not use custom authentication providers that require a static password.
D
Delinea Management Secret Server
Delinea tracks gMSA accounts in its discovery engine even though AD manages rotation — providing visibility, audit logging, dependency mapping, and governance reporting. For services that cannot use gMSA natively, Delinea manages the fallback Standard SA with equivalent security controls.
gMSA Visibility
Discovers and catalogs all gMSA accounts in the domain; tracks which services use them and on which hosts
Governance Reporting
Provides audit-ready reports on gMSA group membership, last rotation, and application dependency mapping
Migration Assist
Workflow tooling to identify Standard SA accounts eligible for gMSA migration, with step-by-step transition guidance
Application-to-Application (A2A) Accounts
Machine-to-Machine · App Credentials · Inter-Service Auth
▾
Overview
Risks
Delinea
📋 Purpose & Use Cases
A2A accounts authenticate one application or service to another without human involvement. Examples: a backup application retrieving credentials from a vault, a CI/CD pipeline authenticating to a deployment target, microservices calling each other, an ERP system connecting to a middleware layer. These are often implemented as domain accounts, certificate-based identities, or OAuth 2.0 client credentials.
📊 Specifications
| Auth Methods | Client secret, certificate, mTLS, Kerberos |
| Credential Types | Password, API key, client secret, X.509 cert |
| Typical Lifetime | Long-lived secrets (risk) or short-lived tokens |
| Direction | Consuming app pulls creds from vault at runtime |
| Discovery Challenge | Often undocumented; spread across code and configs |
| Best Practice | Certificate-based or OAuth 2.0 client credentials |
🏗 Delinea A2A Framework
Delinea's A2A framework allows applications to retrieve credentials from Secret Server at runtime without storing them locally. The calling application authenticates to Secret Server using an API key or certificate, then receives the current vaulted credential. When the vault rotates the credential, all applications using the A2A framework automatically receive the new value on their next retrieval — eliminating the outage-on-rotation problem.
⚠ Risk Factors
⬤ Hardcoded Secrets in Source Code
⬤ Secrets in Environment Variables
⬤ Non-Expiring API Keys
⬤ Undocumented A2A Relationships
⬤ Overly Broad API Permissions
⬤ No Certificate Revocation Process
Hardcoded credentials in source code repositories are among the most common breach sources — exposed via public GitHub commits, insider access, or source code leaks. Environment variables stored in CI/CD systems, container orchestrators, and shell profiles are frequently over-exposed. The challenge is discovering all A2A credential usage before implementing rotation.
🛡 Hardening Controls
• Never commit secrets to source control (use .gitignore + pre-commit hooks)
• Prefer short-lived tokens over long-lived secrets
• Implement secret scanning in CI/CD pipelines
• Use certificate-based auth where possible
• Scope permissions to minimum required API surface
• Audit all A2A authentications centrally
• Prefer short-lived tokens over long-lived secrets
• Implement secret scanning in CI/CD pipelines
• Use certificate-based auth where possible
• Scope permissions to minimum required API surface
• Audit all A2A authentications centrally
🎯 Common Exposure Vectors
• Git repository secret commits (T1552.001)
• .env files in Docker images
• CI/CD environment variable leaks
• Log files capturing auth headers
• Swagger/OpenAPI docs exposing API keys
• Config file backups in public S3 buckets
• .env files in Docker images
• CI/CD environment variable leaks
• Log files capturing auth headers
• Swagger/OpenAPI docs exposing API keys
• Config file backups in public S3 buckets
D
Delinea Management Secret Server A2A Framework
Delinea's A2A integration enables applications to retrieve secrets programmatically at runtime. Applications are registered and authenticate via certificate or API key. The SDK and REST API allow any language or platform to integrate. Secrets are never stored in the application — only retrieved on demand.
SDK Integration
.NET, Java, Python, Go, and PowerShell SDKs; REST API for all other platforms; zero secrets in application code
Cert-Based App Auth
Applications authenticate to Secret Server using X.509 client certificates — no shared secrets to protect the retrieval channel
Access Policies
IP-restrict which servers can retrieve each secret; enforce MFA for non-cert auth; record every retrieval event in audit log
# Python — Delinea A2A credential retrieval at runtime
from delinea.secrets.server import SecretServer, SecretServerCloud
ss = SecretServer('https://vault.corp.local/SecretServer', auth='cert')
# No password stored — retrieved fresh each time
db_password = ss.get_secret(secret_id=1042)['password']
Linux Daemon Accounts
System Users · /etc/passwd · systemd Units · nologin Shell
▾
Overview
Risks
Delinea
📋 Purpose & Use Cases
Linux system services run as dedicated low-privilege system users (/etc/passwd entries with shell set to /usr/sbin/nologin or /bin/false). Examples: nginx runs as www-data, PostgreSQL as postgres, MySQL as mysql, Redis as redis, syslog as syslog. Systemd unit files specify the User= and Group= directives. These accounts have no home directory login capability but may have sudo rules or file permissions that grant significant access.
📊 Specifications
| UID Range | System accounts: UID 1-999 (distro-dependent) |
| Shell | /usr/sbin/nologin or /bin/false (no interactive login) |
| Password | Typically locked ('!' in /etc/shadow) — auth via PAM |
| Systemd Config | User=, Group=, DynamicUser= in unit files |
| Sudo Risk | NOPASSWD sudo entries are a common privilege escalation path |
| PAM Integration | SSSD + Kerberos for AD-joined Linux hosts |
🐧 systemd DynamicUser — The Modern Approach
Systemd's DynamicUser=yes directive creates a transient, randomly-allocated UID for the service process duration — no persistent /etc/passwd entry. This is the most secure option for stateless services. For stateful services (databases, file servers), static daemon accounts with locked passwords remain the standard. Delinea manages authentication for these static accounts via PAM integration on AD-joined Linux systems.
⚠ Risk Factors
⬤ NOPASSWD Sudo Escalation
⬤ SUID Binary Abuse
⬤ World-Writable Files Owned by Daemon
⬤ SSH Key Credential in Daemon Home
⬤ Socket / Capability Overprivilege
Even with locked passwords and nologin shells, daemon accounts can be escalated: attackers exploit SUID binaries owned by the daemon user, leverage NOPASSWD sudo entries added by lazy administrators, or write to configuration files owned by the daemon that get executed as root on restart. Linux daemon accounts require the same audit rigor as Windows service accounts.
🛡 Hardening Controls
• Lock all daemon account passwords (passwd -l)
• Set shell to /usr/sbin/nologin
• Audit /etc/sudoers and /etc/sudoers.d/ for NOPASSWD entries
• Use systemd capabilities (CAP_NET_BIND_SOCKET) over root
• Implement AppArmor/SELinux profiles per daemon
• Scan for SUID binaries owned by daemon accounts
• Set shell to /usr/sbin/nologin
• Audit /etc/sudoers and /etc/sudoers.d/ for NOPASSWD entries
• Use systemd capabilities (CAP_NET_BIND_SOCKET) over root
• Implement AppArmor/SELinux profiles per daemon
• Scan for SUID binaries owned by daemon accounts
🎯 Linux Privilege Escalation Paths
• T1548.001 — SUID binary abuse
• T1548.003 — Sudo misconfig exploitation
• T1166 — Service account setuid abuse
• T1525 — Implant Container Image
• T1611 — Escape to Host (containers)
• T1548.003 — Sudo misconfig exploitation
• T1166 — Service account setuid abuse
• T1525 — Implant Container Image
• T1611 — Escape to Host (containers)
D
Delinea Management Secret Server · DevOps Secrets Vault
On AD-joined Linux hosts, Delinea integrates via PAM (Pluggable Authentication Modules) and SSSD to manage service account authentication and credential vaulting. For standalone Linux systems, the Secret Server agent manages local account credentials and SSH key rotation.
PAM Integration
PAM module intercepts authentication for privileged Linux accounts; enforces MFA and records session activity
SSH Key Rotation
Discovers and rotates SSH private keys used by daemon accounts for remote access; syncs authorized_keys entries
Session Recording
Records all privileged SSH sessions via the Delinea protocol gateway — full keystroke and screen capture audit trail
Cloud Workload Identities
AWS IAM Roles · GCP Service Accounts · Azure MI · K8s SA
▾
Overview
Risks
Delinea
📋 Purpose & Use Cases
Cloud workload identities represent non-human principals in cloud environments: EC2 instance profiles (AWS), GCP service accounts bound to Compute instances, Azure Managed Identities, and Kubernetes service accounts. They enable workloads to access cloud APIs (S3, Secrets Manager, Key Vault, Cloud Storage) without storing long-lived credentials. Short-lived tokens are vended by the cloud metadata service.
📊 Platform Comparison
| AWS | IAM Roles for EC2/Lambda/ECS via instance metadata IMDS |
| Azure | Managed Identity (system-assigned or user-assigned); MSI endpoint |
| GCP | Service Account email; bound to instance via IAM policy |
| Kubernetes | ServiceAccount + RBAC; IRSA/Workload Identity for cloud API access |
| Token TTL | Typically 1 hour (AWS/Azure/GCP); ephemeral |
| Long-Lived Keys | IAM access keys (AWS), SA JSON keys (GCP) — avoid these |
☁ The IMDS / Metadata Service Risk
All cloud platforms vend temporary credentials via an instance metadata service (AWS IMDS, Azure IMDS, GCP metadata server). If a workload is compromised via SSRF or RCE, attackers can query the metadata endpoint and steal short-lived credentials. AWS IMDSv2 mitigates this with a required PUT request, but many workloads still run on IMDSv1. GCP and Azure have similar mitigations. Kubernetes adds complexity: any pod in a namespace with a permissive service account can inherit cloud permissions.
⚠ Risk Factors
⬤ SSRF → IMDS Token Theft
⬤ Long-Lived IAM / SA JSON Keys
⬤ AdministratorAccess / Owner Role Overassignment
⬤ K8s Service Account Token Sprawl
⬤ Cross-Account Role Assumption Chains
⬤ Shadow Admin IAM Policies
Long-lived IAM access keys (AWS) and GCP service account JSON keys are the highest-risk pattern — they behave like passwords that never expire and can be used from anywhere in the world. Organizations should have zero IAM access keys checked into source code and rotate all existing long-lived keys into Delinea vaulting immediately.
🛡 Hardening Controls
• Prefer IAM roles over access keys; zero long-lived keys
• Enable AWS IMDSv2 on all EC2 instances
• Apply least-privilege IAM policies (AWS Access Analyzer)
• Enable GCP Workload Identity instead of SA JSON keys
• Restrict K8s service account token automounting
• Enable cloud audit logging (CloudTrail, Cloud Audit Logs, Azure Monitor)
• Enable AWS IMDSv2 on all EC2 instances
• Apply least-privilege IAM policies (AWS Access Analyzer)
• Enable GCP Workload Identity instead of SA JSON keys
• Restrict K8s service account token automounting
• Enable cloud audit logging (CloudTrail, Cloud Audit Logs, Azure Monitor)
🎯 Cloud Attack Techniques
• T1552.005 — Cloud Instance Metadata API abuse
• T1528 — Steal Application Access Token
• T1098.001 — Additional Cloud Credentials
• T1580 — Cloud Infrastructure Discovery
• T1619 — Cloud Storage Object Discovery
• T1528 — Steal Application Access Token
• T1098.001 — Additional Cloud Credentials
• T1580 — Cloud Infrastructure Discovery
• T1619 — Cloud Storage Object Discovery
D
Delinea Management DevOps Secrets Vault · Secret Server
Delinea's DevOps Secrets Vault provides dynamic, short-lived cloud credentials on demand — eliminating long-lived keys entirely. For existing IAM access keys, Secret Server vaults and rotates them automatically. Cloud account discovery maps all IAM roles and service accounts across multi-cloud environments.
Dynamic Secrets
Vends just-in-time, scoped AWS/Azure/GCP credentials that expire automatically — zero long-lived keys in codebases
Multi-Cloud Discovery
Scans AWS, Azure, and GCP for all service accounts, IAM users, managed identities, and access keys; maps to Secrets
IAM Key Rotation
Rotates AWS IAM access key pairs, GCP service account keys, and Azure SPN secrets on schedule with zero application downtime
API Service Principals
OAuth 2.0 Client Credentials · Azure Entra App Reg · OIDC
▾
Overview
Risks
Delinea
📋 Purpose & Use Cases
Service principals represent non-human application identities in OAuth 2.0 / OIDC ecosystems. In Microsoft Entra ID (Azure AD), they're Application Registrations with client secrets or certificates. They authenticate applications to Microsoft Graph, Exchange Online, SharePoint, and any Azure resource. In broader contexts, OAuth 2.0 Client Credentials flow is the industry-standard pattern for server-to-server API authentication.
📊 Specifications
| Entra ID Object | App Registration (global) + Service Principal (per-tenant) |
| Auth Methods | Client secret (password) or X.509 certificate (preferred) |
| Token TTL | Access tokens: 1 hour; refresh tokens: up to 90 days |
| Permission Types | Delegated (user context) vs. Application (no user — highest risk) |
| Secret Expiry | 2 years max in Entra ID (set shorter in practice) |
| Graph Permissions | Application permissions can grant tenant-wide data access |
⚠ The Application Permission Explosion Problem
Entra ID Application permissions (not delegated) operate without a user context — a service principal with
Mail.ReadWrite application permission can read every user's mailbox in the tenant. Directory.ReadWrite.All grants full AD-equivalent access. These are commonly over-provisioned and rarely audited. Service principal client secrets routinely end up in CI/CD pipelines, Terraform state files, and application logs.⚠ Risk Factors
⬤ Tenant-Wide Application Permissions
⬤ Client Secrets in CI/CD Pipelines
⬤ Long-Lived Secrets (2-year default)
⬤ No Expiry Alerts / Rotation Process
⬤ Orphaned App Registrations
⬤ Consent Grant Abuse
A leaked service principal client secret with tenant-wide Graph permissions (Mail.ReadWrite.All, Files.ReadWrite.All) is the equivalent of a God Mode credential for the Microsoft 365 tenant. Attackers specifically hunt for these in exposed Terraform state, GitHub repositories, and compromised CI/CD runners. The lack of IP restrictions and the absence of MFA on service principals make them extremely portable credentials.
🛡 Hardening Controls
• Prefer certificates over client secrets
• Set 90-day maximum secret lifetime (custom policy)
• Apply Conditional Access for service principals (Entra P2)
• Restrict to specific IP ranges via named locations
• Audit Graph application permissions quarterly
• Enable anomaly detection on service principal sign-ins
• Remove all orphaned / unused app registrations
• Set 90-day maximum secret lifetime (custom policy)
• Apply Conditional Access for service principals (Entra P2)
• Restrict to specific IP ranges via named locations
• Audit Graph application permissions quarterly
• Enable anomaly detection on service principal sign-ins
• Remove all orphaned / unused app registrations
🎯 Entra / AAD Attack Techniques
• T1528 — Steal Application Access Token
• T1550.001 — Application Access Token abuse
• T1098.001 — Add Credentials to Cloud Application
• T1606.002 — SAML Token Forgery
• T1134.005 — SID-History / Token impersonation
• T1550.001 — Application Access Token abuse
• T1098.001 — Add Credentials to Cloud Application
• T1606.002 — SAML Token Forgery
• T1134.005 — SID-History / Token impersonation
D
Delinea Management Secret Server · Cloud Manager
Delinea vaults all Entra ID service principal client secrets, manages their rotation before expiry, and provides full audit logging of every access. The rotation workflow updates the secret in Entra ID, then propagates the new value to all applications retrieving it via A2A — with zero manual intervention.
Expiry Management
Monitors all Entra ID app registration secret expiry dates; rotates on schedule before expiry — no more certificate/secret cliff events
Graph API Rotation
Uses Microsoft Graph API to add new client secret, push to dependent applications via A2A, then remove the old secret — zero downtime
Permission Audit Reports
Generates quarterly reports of all service principal application permissions; flags over-privileged principals for remediation
No account types match your current filter.
Try a different search term or clear the filter.
Try a different search term or clear the filter.