Identity, Authentication, and Enterprise Directory Testing

Introduction and Context

Identity is the control plane of an enterprise. Users, administrators, services, devices, applications, and automated workloads receive identities; those identities are authenticated and then authorized to perform actions. A weakness in any stage can allow an attacker to move from a single compromised account to sensitive systems, confidential data, or administrative control.

Identity testing in penetration testing is therefore broader than password guessing. It evaluates the complete identity lifecycle: account creation, authentication, authorization, privilege assignment, directory configuration, federation, service credentials, secrets storage, monitoring, and account removal. Testing must be authorized, carefully scoped, and designed to demonstrate risk without causing lockouts, data exposure, or service interruption.

This chapter focuses on enterprise environments using directory services such as Microsoft Active Directory, LDAP-based directories, cloud identity providers, Kerberos, SAML, OAuth 2.0, and OpenID Connect.

Learning Objectives

By the end of this chapter, a learner should be able to:

1. Explain identification, authentication, authorization, and accountability.
2. Assess password, account-lockout, session, and multifactor-authentication policies.
3. Describe Kerberos authentication and identify common configuration risks.
4. Evaluate directory-service permissions, group nesting, trusts, and delegation.
5. Test secrets-management practices without unnecessarily exposing credentials.
6. Construct identity-based attack paths and recommend proportionate controls.
7. Document identity findings ethically and communicate their business impact.

1. The Identity and Access Model

An identity system answers four related questions:

• Identification: Who or what is requesting access?
• Authentication: What evidence proves that identity?
• Authorization: What is the identity allowed to do?
• Accountability: Can actions be reliably attributed to that identity?

These functions are distinct. A username identifies an account but does not authenticate it. A successful login authenticates an account but does not automatically authorize access to every resource. Logging supports accountability, but only if identities are unique, timestamps are reliable, and logs are protected.

Authentication factors

Authentication factors are commonly classified as:

Multifactor authentication (MFA) requires evidence from at least two different factor categories. Two passwords are not MFA because both are knowledge factors. MFA substantially reduces the value of stolen passwords, but it does not eliminate risk: phishing proxies, session-token theft, malicious OAuth consent, recovery-process abuse, and push-notification fatigue can bypass or weaken it.

Identity lifecycle

A secure lifecycle includes joiner, mover, and leaver processes. New accounts should be approved and linked to a business role. Role changes should remove obsolete permissions as well as add new ones. Departing personnel should have accounts, tokens, sessions, certificates, API keys, and delegated access revoked promptly. Dormant, shared, service, and emergency accounts require special ownership and review.

The principle of least privilege states that a subject should receive only the permissions required for an approved task, for the minimum practical duration. Separation of duties prevents one person or identity from completing a sensitive process alone. Just-in-time administration reduces the time during which privileged rights are exposed.

2. Credential and Authentication Policy Testing

A penetration test should review policy and verify effective behavior. A documented policy may differ from the configuration actually enforced by a domain controller, cloud identity provider, application, or legacy protocol.

Password controls

Important questions include:

• Are passwords screened against breached-password lists?
• Are minimum length and passphrase requirements appropriate?
• Are old passwords prevented from immediate reuse?
• Are default credentials removed before deployment?
• Are passwords transmitted only through protected channels?
• Are service and local administrator passwords unique per system?
• Are password-reset processes resistant to social engineering?

Length is generally more useful than arbitrary complexity rules, particularly when combined with breached-password screening and MFA. Password rotation should be risk-based; forced periodic changes can encourage predictable variants when there is no evidence of compromise.

Testing must avoid uncontrolled password spraying. The tester should define a small, approved credential set, maximum attempts, lockout thresholds, test windows, and emergency contacts. Password spraying differs from brute force: spraying tries one or a few likely passwords against many accounts, reducing the chance of locking one account repeatedly. Both activities can disrupt operations and may violate law or policy without explicit authorization.

Lockout and throttling

Controls may include progressive delays, risk-based challenges, account lockout, IP or device reputation, and detection of distributed attempts. Lockout can itself be abused for denial of service, so organizations should balance resistance to guessing with availability and help-desk recovery.

Session and recovery testing

Assess session expiration, refresh-token revocation, logout behavior, concurrent sessions, secure cookie attributes, reauthentication for sensitive actions, and recovery channels. A password reset link should be single-use, time-limited, bound to the intended account, and delivered through a controlled channel. Knowledge-based questions are weak recovery factors because answers may be discoverable.

MFA assessment

A professional test examines enrollment, replacement, recovery, device registration, number matching, phishing-resistant methods, and administrative bypass. Stronger methods include FIDO2/WebAuthn security keys and certificate-based authentication. SMS codes may be useful as a transitional control but are exposed to SIM-swap and telecommunications risks. Push MFA should use number matching and risk-based controls rather than accepting an unexplained prompt.

The tester should never repeatedly trigger prompts against a real user without explicit consent and safeguards. Evidence should demonstrate a control weakness, not harvest genuine tokens or private data.

3. Kerberos and Directory Services

Kerberos overview

Kerberos is a ticket-based protocol widely used in Windows domain environments. A simplified exchange is:

1. A client requests a ticket-granting ticket (TGT) from the Authentication Service in the Key Distribution Center (KDC).
2. The KDC issues a TGT after validating the client’s long-term secret.
3. The client presents the TGT to the Ticket Granting Service (TGS) to request a service ticket.
4. The client presents the service ticket to the target service.
5. The service validates the ticket and may perform mutual authentication.

The KDC depends on accurate time, protected cryptographic keys, reliable domain controllers, and correct service principal names (SPNs). Clock-skew limits help prevent replay, while tickets avoid sending the user’s password to every service.

Common testing concerns include:

• weak or obsolete encryption types;
• service accounts with SPNs and weak passwords;
• unconstrained delegation;
• unsafe constrained-delegation configuration;
• excessive ticket lifetimes;
• exposed domain-controller services;
• replication permissions granted too broadly;
• stale computer and user accounts;
• insecure LDAP or SMB communication;
• privileged accounts used for routine work.

A service principal name identifies a service instance for Kerberos. Duplicate or incorrect SPNs can cause authentication failures and may create unexpected authentication paths. Service accounts should use long, randomly generated secrets, managed service accounts where available, and narrowly scoped delegation.

Directory permissions and group nesting

Directories represent users, groups, computers, organizational units, policies, and access-control entries. Testing should examine effective rather than merely apparent permissions. A user may inherit rights through nested groups, organizational-unit delegation, application groups, or cloud role assignments.

High-risk permissions include the ability to reset another user’s password, modify group membership, write service-principal attributes, create or modify computer accounts, alter group policy, replicate directory secrets, or change access-control entries on privileged objects. A non-administrator with a chain of such rights may be able to reach administrative control even though no single permission appears to be full administration.

Group scope and nesting rules differ by platform. Analysts should map actual effective access, document inheritance, and identify toxic combinations such as help-desk password-reset rights combined with privileged-group management.

Trust relationships

Trusts allow identities in one security boundary to access resources in another. They may be transitive or non-transitive, one-way or bidirectional, and configured with varying levels of filtering. Testing should identify:

• which domains or forests trust one another;
• the direction and purpose of each trust;
• whether privileged identities cross boundaries;
• whether SID filtering or equivalent protections are enabled;
• whether external and legacy trusts remain necessary;
• whether cloud and on-premises identities are synchronized safely.

A trust is not automatically a vulnerability. Risk depends on direction, authentication scope, privileges, filtering, monitoring, and the sensitivity of reachable resources.

4. Identity-Based Attack Paths

An attack path is a sequence of relationships by which an attacker moves from an initial foothold to a valuable objective. Identity graphs can represent accounts, groups, devices, applications, permissions, trusts, credentials, and resources as nodes and edges.

A practical analysis asks:

1. What is the assumed starting identity or device?
2. Which credentials, tokens, or permissions can it access?
3. Which groups or roles can it modify or join?
4. Which systems can those identities administer?
5. What sensitive objective becomes reachable?
6. Which control would break the shortest or most dangerous path?

For example, a low-privilege workstation user may have access to a script containing a service-account secret. That account may modify a deployment group. The deployment group may administer servers containing a database credential. The database credential may provide access to regulated records. The risk is the chain, not merely the script or service account in isolation.

Attack-path analysis should distinguish theoretical reachability from practical exploitability. Conditions include network location, endpoint protection, MFA, approval gates, credential validity, monitoring, and the attacker’s ability to execute code.

5. Secrets Management

Secrets include passwords, private keys, API tokens, connection strings, signing keys, recovery codes, and cloud access keys. Common exposure locations are source repositories, build logs, container images, shell history, configuration files, backups, tickets, spreadsheets, and endpoint memory.

A mature secrets-management design uses a dedicated vault, encryption in transit and at rest, strict access policies, short-lived credentials, automated rotation, audit logs, and separation of duties. Applications should retrieve secrets at runtime rather than embedding them in code. Secret scanning can identify likely credentials, but findings require validation because false positives are common and scanning does not prove that a secret is unused.

During testing, exposed secrets should be treated as sensitive evidence. Do not copy more data than necessary, do not use a discovered key beyond the approved objective, and notify the client rapidly when a live credential creates immediate risk. Rotation is not sufficient if old tokens remain valid or if the same secret was replicated into backups and logs.

6. Testing Methodology and Evidence

A disciplined identity assessment normally follows these stages:

Scope and rules of engagement

Define domains, tenants, applications, test accounts, prohibited actions, credential-handling rules, time windows, rate limits, and emergency contacts. Obtain written authorization and clarify whether social engineering, password attacks, wireless access, or cloud testing is included.

Discovery and review

Collect architecture diagrams, identity inventories, authentication policies, role matrices, trust maps, privileged-account lists, recovery procedures, and logging configurations. Compare documented design with observed behavior.

Low-impact validation

Begin with configuration review, authenticated queries using approved accounts, permission analysis, and safe checks for exposed services. Escalate only when necessary and approved. Use unique canary accounts or synthetic records where possible.

Privilege and path analysis

Map effective permissions and identify routes to critical assets. Validate a path with the least intrusive proof. For example, demonstrating that an account can modify a test group is preferable to adding a real privileged user.

Reporting and remediation

Each finding should state the condition, evidence, affected scope, exploitability, business impact, root cause, and prioritized remediation. A useful severity assessment considers likelihood, privilege gained, asset sensitivity, blast radius, and detectability. Retest after remediation, including inherited permissions and cached or long-lived tokens.

Applied Case: Illustrative Retail Enterprise

Background

A fictional retailer operates an on-premises Windows domain synchronized with a cloud identity provider. Store employees use cloud applications, while a central deployment platform administers point-of-sale servers.

Problem

A review identifies a shared deployment account, an old external trust, several service accounts with non-expiring passwords, and help-desk staff able to reset passwords for a broad employee population. MFA is required for cloud access but not for a legacy remote-access portal.

Analysis

The deployment account is used by an automated job and has administrative rights on point-of-sale servers. Its password appears in an old build log. The external trust is bidirectional and lacks effective filtering. A help-desk account can reset a manager’s password, and the manager belongs to a group that can approve deployment changes. The combined relationships create a plausible path from exposed build information to operational systems.

Approach and solution

The tester uses an approved synthetic account and does not access payment data. Evidence is limited to demonstrating read access to the old log, membership relationships, and modification rights on a test deployment group. Recommended actions are to revoke and rotate the deployment secret, migrate to a managed identity, remove unnecessary trust paths, narrow password-reset scope, enforce phishing-resistant MFA on remote access, separate approval and deployment roles, and alert on unusual group changes.

Outcome

The organization breaks the demonstrated path at several points rather than relying on one control. A follow-up test confirms that the old token is invalid, the synthetic account cannot modify the deployment group, and the remote portal requires strong MFA.

Learning points

Identity risk is cumulative. A leaked secret, excessive delegation, and weak recovery process may each appear moderate, but together they can produce administrative compromise. Effective remediation removes unnecessary relationships and reduces standing privilege.

7. Governance, Ethics, and Limitations

Identity testing can expose personal information, authentication secrets, and privileged access. Testers must follow authorization, data-minimization, confidentiality, and retention requirements. Relevant obligations may include organizational policy, privacy law, contractual requirements, and sector regulations. Reports should avoid publishing usable credentials and should protect evidence at the same classification as the underlying data.

Important limitations include incomplete inventories, cloud-provider abstraction, changing group membership, encrypted or inaccessible logs, undocumented legacy systems, and differences between configuration and runtime behavior. A clean test result is not proof of security; it is evidence limited by scope, time, accounts, controls, and techniques used.

8. Contemporary Developments and Best Practices

Identity security is moving toward zero-trust principles: continuously evaluate identity, device, application, resource, and context rather than trusting a network location. Privileged access management, passwordless authentication, conditional access, device-bound credentials, and just-in-time administration reduce standing exposure.

Organizations should prioritize:

1. phishing-resistant MFA for administrators and remote access;
2. unique, vaulted, rotated service credentials;
3. removal of legacy authentication protocols;
4. continuous review of effective permissions and attack paths;
5. strong joiner-mover-leaver automation;
6. protected and monitored recovery processes;
7. segmentation of administrative tiers;
8. high-quality logs for authentication, privilege changes, token use, and directory replication;
9. tested incident-response procedures for identity compromise;
10. regular adversarial validation and remediation retesting.

Artificial intelligence can assist with anomaly detection, identity-graph analysis, and prioritization of excessive permissions. It can also produce false positives, infer sensitive relationships, or become a target if identity data is sent to an unapproved service. Human review, data governance, explainability, and least-privilege access remain necessary.

Chapter Summary

Enterprise identity testing evaluates the complete path from identification to accountability. Strong passwords alone are inadequate: secure authentication requires appropriate factors, protected recovery, safe sessions, and resistance to phishing and token theft. Directory testing must consider effective permissions, group nesting, delegation, Kerberos tickets, service accounts, trusts, and replication rights. Secrets should be vaulted, short-lived, rotated, and excluded from code and logs. The most serious findings often arise from chains of individually modest weaknesses. Authorized, low-impact validation combined with identity-graph analysis allows testers to demonstrate these paths while protecting users and systems. Remediation should reduce standing privilege, remove unnecessary trust, strengthen MFA, improve lifecycle automation, and monitor identity changes.

Key Terms

Accountability: The ability to attribute actions to a specific identity through reliable records.

Authentication: Verification of an identity claim.

Authorization: Determination of what an authenticated identity may do.

Directory service: A system that stores and manages identities, groups, resources, and permissions.

FIDO2/WebAuthn: Phishing-resistant standards for public-key-based authentication.

Identity provider: A service that authenticates identities and issues access assertions or tokens.

Kerberos: A ticket-based network authentication protocol.

Least privilege: Granting only the access necessary for an approved task.

MFA: Authentication using evidence from at least two different factor categories.

Privilege escalation: Obtaining greater permissions than initially assigned.

Service principal name: An identifier associating a network service with an account for Kerberos.

Secrets management: Controlled creation, storage, use, rotation, and revocation of sensitive credentials.

Separation of duties: Dividing sensitive responsibilities among different people or identities.

Session token: A value representing an authenticated session after login.

SPN: Abbreviation for service principal name.

Ticket-granting ticket: A Kerberos ticket used to request service tickets.

Trust relationship: A configured relationship allowing authentication or authorization across security boundaries.

Just-in-time access: Temporary privilege granted only when needed.

Review Questions

Short Answer Questions

1. Distinguish identification, authentication, authorization, and accountability.
2. Why are two passwords not considered multifactor authentication?
3. What is the purpose of a Kerberos ticket-granting ticket?
4. State two risks associated with shared service accounts.
5. Why should penetration testers minimize the use and collection of discovered secrets?

Long Answer Questions

1. Explain how a tester should assess an enterprise password and account-lockout policy.
2. Describe the main stages of a Kerberos authentication exchange and identify important configuration risks.
3. Explain how group nesting, delegated permissions, and trust relationships can create privilege-escalation paths.
4. Compare password-based MFA, SMS codes, push approval, and FIDO2/WebAuthn in terms of security and operational risk.
5. Design a professional methodology for testing identity controls while minimizing disruption and privacy exposure.

Analytical / Application Questions

1. A help-desk group can reset passwords for managers, and managers can approve deployment changes. Analyze the possible attack path and recommend controls.
2. An API key is found in a public repository but its owner claims it was revoked. What evidence should the tester seek, and what remediation steps are appropriate?
3. An organization has a bidirectional trust with a partner domain and permits routine administrator accounts to cross it. Evaluate the risks and propose a safer trust and privilege model.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorization?

A. Authentication determines what a user may access, while authorization identifies the user.

B. Authentication verifies an identity claim, while authorization determines permitted actions.

C. Authentication records events, while authorization encrypts passwords.

D. Authentication creates groups, while authorization issues Kerberos tickets.

Correct Answer: B. Authentication verifies an identity claim, while authorization determines permitted actions.

Question 2

Which combination represents multifactor authentication?

A. Password and security question

B. PIN and passphrase

C. Password and FIDO2 security key

D. Two different passwords

Correct Answer: C. Password and FIDO2 security key

Question 3

What is the primary role of a Kerberos ticket-granting ticket?

A. To store a user’s password permanently

B. To request service tickets from the ticket-granting service

C. To replace all directory groups

D. To encrypt every database record

Correct Answer: B. To request service tickets from the ticket-granting service

Question 4

Which finding most directly indicates excessive directory privilege?

A. A user has a unique email address

B. A help-desk account can modify membership of a privileged group

C. A workstation has a screen lock

D. A domain has multiple organizational units

Correct Answer: B. A help-desk account can modify membership of a privileged group

Question 5

Why is a service account with a non-expiring, weak password a significant risk?

A. It prevents all logging

B. It may provide persistent access if the credential is discovered

C. It automatically disables MFA for every user

D. It guarantees Kerberos mutual authentication

Correct Answer: B. It may provide persistent access if the credential is discovered

Question 6

Which control is generally most resistant to real-time phishing among the following?

A. SMS one-time code

B. Security question

C. FIDO2/WebAuthn security key

D. Email-based password reset

Correct Answer: C. FIDO2/WebAuthn security key

Question 7

What should a tester do first after discovering a potentially live production secret?

A. Publish it to prove impact

B. Use it against every available system

C. Follow the rules of engagement and notify the authorized contact promptly

D. Place it in a shared team document

Correct Answer: C. Follow the rules of engagement and notify the authorized contact promptly

Question 8

What does least privilege require?

A. Every employee receives administrator rights

B. Access is limited to what is necessary for an approved task

C. Privileges are never reviewed after assignment

D. All users share one account

Correct Answer: B. Access is limited to what is necessary for an approved task

Question 9

Which relationship can allow authentication across security boundaries?

A. A trust relationship

B. A screen-lock policy

C. A password history rule

D. A backup schedule

Correct Answer: A. A trust relationship

Question 10

Which remediation best addresses a leaked automated deployment credential?

A. Rename the file containing it

B. Leave it active but increase its password length later

C. Revoke and rotate it, then migrate to a managed or vaulted identity

D. Copy it into additional build logs

Correct Answer: C. Revoke and rotate it, then migrate to a managed or vaulted identity