Identity, Password and Active Directory Security

Introduction

Identity is the control plane of a modern enterprise. Applications, endpoints, cloud services, databases and administrative tools all make decisions based on the identity presented by a user, device, service or application. If an attacker obtains a valid identity or causes a trusted identity to perform an unintended action, conventional perimeter controls may provide little protection. Ethical hackers therefore assess not only whether a password can be guessed, but also how identities are created, authenticated, authorised, delegated and monitored.

This chapter examines credential policies, multifactor authentication (MFA), privilege models and directory services, with emphasis on Microsoft Active Directory (AD). It explains password attacks, Kerberos authentication, trusts, delegation, group-based privilege and common configuration weaknesses. The focus is defensive and authorised: testing must be conducted only with written permission, defined scope and appropriate safeguards.

Learning Objectives

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

• distinguish identification, authentication, authorisation and accounting;
• evaluate password and credential policies using risk-based criteria;
• explain MFA, its strengths and its principal bypass risks;
• compare least privilege, role-based access control and privileged access management;
• describe the main components of Active Directory and Kerberos;
• identify weaknesses involving password exposure, trusts, delegation, groups, service accounts and directory configuration;
• analyse identity-based attack paths without causing unauthorised harm; and
• recommend controls, monitoring and remediation priorities.

1. Identity and Access as a Security System

An identity and access management (IAM) system answers four related questions:

1. Identification: Who or what is requesting access?
2. Authentication: What evidence supports that claimed identity?
3. Authorisation: What actions and resources is that identity permitted to use?
4. Accounting and auditing: What happened, when, from where and under which identity?

Authentication is not the same as authorisation. A user may authenticate successfully but still lack permission to read a file. Conversely, excessive authorisation can make a stolen account highly damaging.

Important identity principals include human users, administrators, computers, service accounts, managed service identities, applications and security groups. A principal can possess credentials, receive permissions, belong to groups and become trusted for delegated actions. These relationships form an identity graph. Attack-path analysis examines how an attacker could move from an initially compromised principal to a valuable target through such relationships.

The principal security objectives are confidentiality, integrity, availability, accountability and resilience. Identity controls support all five. For example, strong authentication protects confidentiality, separation of administrative duties protects integrity, and break-glass accounts support availability during an identity-provider outage.

2. Password Security and Credential Policies

2.1 Passwords and password-derived secrets

A password is a shared secret. Its security depends on secrecy, unpredictability, resistance to guessing and protection during storage and transmission. Passwords should not be stored in plaintext. A verifier should store a salted, deliberately expensive password hash using a password-hashing function designed for this purpose, such as Argon2id, scrypt, bcrypt or PBKDF2, configured according to current professional guidance.

A salt is a unique random value stored with each password record. It prevents identical passwords from producing identical stored values and makes precomputed rainbow tables ineffective. A salt does not make a weak password strong; it makes large-scale reuse of precomputed guesses less efficient.

A password hash is not encryption. Encryption is reversible with a key, whereas a properly designed password hash is intended to be computationally impractical to reverse. Password verification hashes should also be protected by access controls, monitoring and, where appropriate, an additional secret held separately from the database.

2.2 Password policy evaluation

A useful password policy addresses:

• minimum length and support for long passphrases;
• screening against breached and common passwords;
• prevention of username, organisation and contextual terms;
• rate limiting, progressive delays or risk-based challenge controls;
• secure reset and recovery processes;
• protection against password spraying and credential stuffing;
• secure transmission using protected channels;
• prohibition of routine password sharing;
• management of service-account credentials; and
• additional controls for privileged accounts.

Length is generally more useful than arbitrary complexity rules. A policy requiring an uppercase letter, digit and symbol may produce predictable substitutions, while a long, unique passphrase can provide greater resistance to guessing. However, length alone does not prevent reuse or phishing. Password screening, MFA and detection remain necessary.

Routine forced password changes can be counterproductive when there is no evidence of compromise: users may choose predictable variations or write passwords down. A change should be required after suspected compromise, administrator reset, exposure in a breach or a documented risk event. Organisations must follow applicable standards and sector requirements rather than adopting a single rule mechanically.

2.3 Common credential attacks

Password guessing tests likely passwords against one account. Password spraying tests a small number of common passwords across many accounts to avoid account lockout. Credential stuffing reuses username-password pairs exposed in another breach. Offline cracking occurs when an attacker obtains password hashes and tests guesses without interacting with the target service. Phishing persuades a victim to reveal a password or approve an authentication request. Pass-the-hash uses an obtained NTLM hash as an authentication credential without recovering the plaintext password. Pass-the-ticket abuses a stolen Kerberos ticket.

Ethical testing should use test accounts, approved password lists and explicit rate limits. It should never collect unnecessary real passwords. Findings should describe the control failure—for example, absence of breached-password screening or excessive authentication attempts—rather than disclosing sensitive credentials.

2.4 Credential lifecycle

Credentials should be governed from creation to destruction. Joiner–mover–leaver processes should ensure that accounts are created for approved roles, changed when responsibilities change and disabled promptly when employment or contract ends. Dormant accounts, shared accounts, legacy protocols and unmanaged local administrator passwords are frequent sources of risk.

Service accounts require particular attention because they often have long-lived credentials, non-interactive logon rights and broad permissions. Prefer group Managed Service Accounts (gMSAs) or equivalent managed identities where supported. Restrict logon locations, deny interactive logon where unnecessary, grant only required permissions and monitor use.

3. Multifactor Authentication

MFA combines two or more different authentication factors:

• Knowledge: something the subject knows, such as a password or PIN;
• Possession: something the subject has, such as a hardware security key or authenticator device; and
• Inherence: something the subject is, such as a biometric characteristic.

Two passwords are not two independent factors because both are knowledge factors. MFA substantially reduces the value of a stolen password, especially when phishing-resistant methods are used. FIDO2/WebAuthn security keys and platform passkeys use public-key cryptography and bind authentication to the legitimate origin, reducing many phishing attacks.

MFA is not automatically strong. Risks include push-notification fatigue, social engineering of help desks, SIM-swap attacks, interception of one-time codes, theft of session cookies and weak recovery procedures. Number matching, risk-based access, device binding, phishing-resistant authenticators and strict recovery controls improve resilience.

A sound MFA assessment asks:

• Which users, applications and protocols are covered?
• Are administrators and remote access users protected?
• Are legacy protocols exempted?
• Can users register a new factor without strong proof of identity?
• Can a help desk reset MFA without independent verification?
• Are emergency accounts monitored and tightly controlled?
• Are authentication prompts correlated with device, location and behaviour?

MFA should be evaluated as an end-to-end process rather than as a checkbox. If an attacker can use an unprotected legacy protocol or steal an authenticated session, the presence of MFA on one login page may not prevent compromise.

4. Privilege Models and Access Governance

4.1 Least privilege and separation of duties

Least privilege grants only the permissions needed for an approved task, for the shortest practical period. Separation of duties ensures that a single person cannot complete a sensitive process without independent oversight. For example, one employee may request a new administrator account while another approves it.

The principle of least privilege applies to users, applications, services, computers and automation pipelines. It includes permissions to read, modify, execute, delegate, reset passwords, create objects and change security policy.

4.2 Role-based and attribute-based access control

Role-based access control (RBAC) assigns permissions to job roles and assigns users to roles. It improves consistency but can produce role explosion if every exception becomes a new role. Attribute-based access control (ABAC) evaluates attributes such as department, device state, resource classification, time and location. In practice, organisations often combine RBAC with contextual conditions.

Privileged access management (PAM) adds controls such as just-in-time access, approval workflows, privileged session recording, credential vaulting, administrative workstations and emergency access procedures. A mature design separates ordinary user accounts from administrative accounts and prevents administrators from using privileged identities for email or routine web browsing.

4.3 Effective permissions

A user’s effective access is determined by the combined result of direct permissions, group memberships, nested groups, deny entries, inheritance, resource-level controls and conditions. Reviewing only direct permissions is therefore unreliable. Access reviews should consider transitive membership and privilege escalation paths.

High-risk privileges include the ability to add members to privileged groups, reset passwords, modify group policy, create or modify service principals, register delegation, alter access-control lists, create computer accounts and replicate directory secrets. These permissions may be more dangerous than ordinary membership in a low-level administrator group because they can enable indirect escalation.

5. Active Directory Architecture

Active Directory Domain Services (AD DS) is a directory and authentication service commonly used in Windows environments. Its principal elements include:

• Forest: the top-level security and schema boundary;
• Tree: a collection of domains in a contiguous namespace;
• Domain: an administrative and authentication boundary containing users, computers, groups and policies;
• Organisational unit (OU): a container used for administration and Group Policy application;
• Domain controller (DC): a server providing directory, authentication and replication services;
• Global Catalog: a searchable, partial representation of objects across the forest;
• Group Policy: centrally managed configuration and security settings; and
• Security principals and SIDs: identities represented by security identifiers used in access checks.

AD uses LDAP for directory queries and management, Kerberos for primary domain authentication, DNS for locating services and, in some environments, NTLM for legacy compatibility. A domain controller is therefore a high-value asset. Compromise of a highly privileged DC can expose or enable control over many identities and systems.

5.1 Groups and Group Policy

Groups simplify administration, but nested and undocumented membership can create excessive privilege. The convention often described as AGDLP—Accounts into Global groups, Global groups into Domain Local groups, Permissions assigned to Domain Local groups—can improve manageability in a domain environment. It is a design aid, not a security guarantee.

Group Policy can enforce password, auditing, firewall, application and security settings. Weaknesses arise when users can modify a policy linked to sensitive systems, when policies contain embedded credentials, when inheritance is misunderstood or when conflicting policies produce unintended results. Administrative delegation over OUs and Group Policy must be reviewed as carefully as group membership.

6. Kerberos Authentication

Kerberos is a ticket-based protocol designed to authenticate principals to network services without sending the password to every service. In a Windows domain, the Key Distribution Center (KDC) runs on domain controllers and consists conceptually of an Authentication Service and a Ticket-Granting Service.

A simplified exchange is:

1. A client requests a Ticket-Granting Ticket (TGT), proving knowledge of its long-term secret.
2. The KDC issues a TGT with a session key.
3. The client presents the TGT to request a service ticket for a named service principal.
4. The client presents the service ticket to the target service.
5. The service validates the ticket and establishes the authenticated context.

Kerberos relies on time synchronisation, service principal names (SPNs), secure keys and the KDC. Clock skew, duplicate SPNs, weak service-account passwords and unsupported encryption can cause failures or security weaknesses.

The ticket-granting ticket is not a universal password. It is a time-limited credential used to obtain service tickets. A stolen ticket can nevertheless enable impersonation until it expires or is invalidated through appropriate response actions. Kerberoasting refers to requesting service tickets for accounts with SPNs and attempting to crack the encrypted service portion offline. The risk is greatest when an SPN is associated with a user account having a weak or old password and excessive privilege.

AS-REP roasting targets accounts configured not to require pre-authentication. An attacker may obtain an encrypted response and attempt offline guessing. The defensive response is to require pre-authentication unless a documented exception exists, use strong managed service credentials and monitor unusual ticket requests.

7. Trusts and Delegation

7.1 Trust relationships

A trust allows authentication or authorisation information to cross a boundary. Trusts may be one-way or two-way, transitive or non-transitive, and within a forest or between forests. A trust does not automatically grant every user access; it creates a path that may be used if permissions and group relationships allow it.

Security review should document every trust, its direction, transitivity, purpose, administrative ownership and permitted authentication scope. Old acquisitions, test domains and broad forest relationships often remain after their business justification has disappeared. Selective authentication and resource-based controls can reduce unnecessary exposure.

7.2 Delegation

Kerberos delegation allows a service to act on behalf of a user when accessing another service. It is useful for applications such as a web server that must query a database using the user’s identity. It is also dangerous because compromise of the delegating service may allow impersonation of users to downstream services.

Unconstrained delegation can expose reusable delegated credentials on a compromised host and should be avoided except under exceptional, controlled circumstances. Constrained delegation limits which services a principal may access. Resource-based constrained delegation allows the resource owner to specify which front-end principals may delegate to it, improving administrative separation in some designs. Delegation settings must be reviewed alongside service accounts, SPNs, computer objects and administrative permissions.

8. Identity-Based Attack-Path Assessment

A professional assessment begins with authorisation, scope, rules of engagement, data-handling requirements and an emergency contact. The tester then develops an inventory of identity assets and relationships rather than immediately attempting exploitation.

A practical workflow is:

1. Discover: identify domains, forests, DCs, identity providers, privileged groups, service accounts, trusts, authentication protocols and administrative interfaces.
2. Model: represent principals, groups, permissions, sessions, SPNs, delegation and trust paths as an identity graph.
3. Prioritise: focus on paths to domain-wide, cloud-wide, financial or safety-critical assets.
4. Validate safely: confirm high-risk relationships with minimal-impact evidence, preferably using test accounts or read-only analysis.
5. Remediate: remove unnecessary privilege, rotate exposed secrets, correct configuration and improve monitoring.
6. Retest: verify that the path is closed and that legitimate business processes still function.

A finding should state the affected asset, precondition, technical weakness, realistic impact, evidence, risk rating and remediation. Avoid reporting merely that a tool found a “path”; explain why the path is possible and what control breaks it.

Useful evidence includes directory configuration exports, group membership reviews, authentication logs, ticket-service anomalies, policy settings and controlled demonstrations. Passwords, hashes, tokens and personal data must be minimised, encrypted and securely destroyed according to the engagement agreement.

Illustrative Case: Northbridge Manufacturing

Background

Northbridge Manufacturing operates a single AD forest with two domains: production and corporate. A legacy scheduling application runs under a user service account. Remote administration is available through a VPN, and MFA is enforced for the VPN but not for several internal administrative protocols.

Problem

A security review identifies that the scheduling account has an SPN, has not changed its password for several years and is a member of a group that can modify a production application server. A help-desk group can reset passwords for many users, including one administrator, without a second approval. A two-way trust connects the corporate and production domains, although only a small number of applications require cross-domain access.

Analysis

The SPN creates a possible offline password-cracking exposure. The service account’s group membership creates a route from that account to a production server. The help-desk delegation creates a separate privilege-escalation risk. The broad trust increases the number of identities that must be trusted by production. The VPN MFA control is valuable but does not address these internal paths or session and recovery weaknesses.

Approach and solution

The assessment team uses a written, read-only scope and a designated test account. It does not retrieve or crack production credentials. Northbridge replaces the service account with a gMSA, removes unnecessary group membership and restricts the application’s permissions to its required database operations. It reviews SPNs and delegation settings, requires phishing-resistant MFA for administrators, and introduces approval and logging for administrator password resets. The trust is changed to selective authentication, and unused trust paths are removed. Privileged administration is moved to hardened administrative workstations.

Outcome

The principal attack paths are closed or made substantially more difficult. Monitoring is added for unusual service-ticket requests, privileged-group changes, password resets, delegation changes and authentication from unmanaged devices. A retest confirms that the scheduling application works while the former service account and help-desk escalation paths no longer provide the same privilege.

Learning points

The case demonstrates that identity risk is relational. A strong password policy cannot compensate for excessive group membership, unsafe delegation or weak recovery controls. MFA is essential but must cover relevant protocols and lifecycle processes. Risk reduction comes from combining prevention, least privilege, secure design, monitoring and tested response.

9. Defensive Monitoring and Incident Response

Identity monitoring should establish normal patterns and alert on high-value deviations. Important events include repeated failures across many accounts, successful authentication from unusual locations, new MFA registration, help-desk resets, privileged-group changes, creation of new service principals, changes to SPNs or delegation, abnormal ticket requests and use of legacy protocols.

Logs should be time-synchronised, protected from unauthorised alteration and retained according to legal, regulatory and operational needs. A security information and event management (SIEM) platform can correlate directory, endpoint, VPN, cloud and application events. Detection quality depends on identity context: an administrator’s expected maintenance activity differs from a newly created account authenticating to many servers.

If compromise is suspected, response may include disabling or isolating accounts, revoking sessions and tokens, rotating passwords and service secrets, invalidating or expiring tickets as appropriate, removing malicious persistence, checking replication and administrative changes, and preserving evidence. Emergency actions must be planned because indiscriminate account disabling can interrupt safety-critical or essential services.

10. Governance, Ethics and Regulation

Identity assessments involve sensitive personal and organisational information. Ethical practice requires informed authorisation, proportionality, least collection, confidentiality, secure evidence handling and clear disclosure of limitations. Testers must not use captured credentials outside scope, access unrelated personal data or conceal activity from the authorised client’s monitoring team unless the rules of engagement explicitly require a controlled exercise.

Organisations should maintain identity policies, access reviews, privileged-account inventories, retention rules, supplier requirements and documented exceptions. Regulatory obligations vary by jurisdiction and sector, but common themes include access control, accountability, protection of personal data, breach response and evidence of risk management. Compliance does not prove security; a control must be effective in the organisation’s actual architecture.

11. Contemporary Developments and Limitations

Cloud identity, hybrid directories, workload identities, passwordless authentication and zero-trust architectures are changing the identity perimeter. Cloud applications may rely on federation, synchronisation agents and tokens rather than direct domain authentication. A compromise in one identity plane can therefore affect another. Security teams should inventory synchronisation scope, application consent, token lifetime, conditional access and emergency access accounts.

AI can assist with identity analytics by identifying unusual login patterns, correlating privilege changes and prioritising attack paths. It can also generate false positives, reproduce biased assumptions or expose sensitive identity data if used carelessly. Human review, data minimisation, explainable decisions and protected processing remain necessary.

No identity control is perfect. Passwordless systems still require secure device binding and recovery. MFA may not protect stolen sessions. Least privilege can be undermined by undocumented exceptions. Automated identity governance may remove access needed for operations or fail to understand business context. Effective security is therefore a continuous process of design, measurement, review and improvement.

Best-Practice Checklist

• Use long, unique passwords and screen against breached-password lists.
• Store passwords with salted, adaptive password-hashing functions; never plaintext.
• Require phishing-resistant MFA for administrators and sensitive applications.
• Separate ordinary and privileged accounts.
• Review nested groups, delegated permissions, trusts and effective access.
• Prefer managed service identities and rotate or remove legacy credentials.
• Minimise SPNs, avoid unconstrained delegation and review constrained delegation.
• Require Kerberos pre-authentication unless a documented exception exists.
• Restrict legacy protocols and monitor ticket, reset and privilege events.
• Apply just-in-time access, approval and session accountability to high-risk administration.
• Protect domain controllers, identity providers, recovery processes and emergency accounts.
• Test identity-based attack paths safely and retest remediation.

Chapter Summary

Identity security encompasses identification, authentication, authorisation and accountability. Password protection requires unique secrets, secure hashing, breached-password screening, controlled recovery and lifecycle governance. MFA reduces the impact of stolen passwords, but phishing-resistant methods, secure recovery and coverage of all relevant protocols are essential.

Least privilege, RBAC, ABAC, separation of duties and PAM provide complementary ways to limit what identities can do. Active Directory integrates domains, forests, groups, Group Policy, DNS, LDAP and Kerberos. Kerberos depends on sound time synchronisation, protected keys, secure service accounts and correctly managed SPNs. Trusts and delegation create useful relationships but can also create indirect privilege-escalation paths.

Ethical penetration testing models these relationships, validates risk with minimal impact and reports actionable remediation. Strong outcomes combine preventive controls, monitoring, incident response, governance and continual retesting.

Key Terms

Active Directory: Microsoft directory service providing identity, authentication and policy capabilities.

Authentication: Verification of a claimed identity.

Authorisation: Determination of permitted actions or resources.

Credential stuffing: Reuse of credentials exposed in another breach.

Delegation: Permission for one service to act on behalf of a user or principal.

Domain controller: Server providing AD authentication and directory services.

Forest: Highest-level AD namespace and security structure.

Group Policy: Centrally managed configuration and security settings.

Kerberos: Ticket-based network authentication protocol used by AD.

Least privilege: Granting only necessary permissions for the required time.

MFA: Authentication using two or more different factor types.

Pass-the-hash: Using an NTLM hash as an authentication credential.

Password spraying: Trying a few common passwords across many accounts.

Privileged access management: Controls for governing high-risk administrative access.

RBAC: Access control based on job or system roles.

Service principal name: Identifier linking a service instance to an account for Kerberos.

Ticket-Granting Ticket: Kerberos ticket used to obtain service tickets.

Trust: Relationship allowing authentication or authorisation across boundaries.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorisation.
2. What purpose does a password salt serve?
3. Why are two passwords not necessarily two-factor authentication?
4. Name two risks associated with unconstrained delegation.
5. What is the role of a domain controller?

Long Answer Questions

1. Explain how a password policy should address guessing, reuse, recovery and service accounts.
2. Describe the main stages of a Kerberos authentication exchange.
3. Compare RBAC, ABAC, least privilege and privileged access management.
4. Explain how trusts, group membership and delegation can combine to create an identity-based attack path.
5. Discuss how an ethical tester should assess Active Directory while protecting credentials and business operations.

Analytical / Application Questions

1. An SPN is assigned to a long-lived user service account that belongs to a server-administration group. Analyse the risks and propose a remediation sequence.
2. A company enforces MFA for its VPN but permits legacy internal authentication and weak help-desk password resets. Evaluate the residual risk and design a testing plan.
3. A production domain has a two-way forest trust with an acquired domain and several nested privileged groups. Develop a method to prioritise review and reduce the most dangerous attack paths.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorisation?

A. Authentication determines permissions, while authorisation verifies identity.

B. Authentication verifies identity, while authorisation determines permitted actions.

C. Authentication records events, while authorisation encrypts passwords.

D. Authentication applies only to administrators, while authorisation applies only to users.

Correct Answer: B. Authentication verifies identity, while authorisation determines permitted actions.

Question 2

What is the primary purpose of a unique salt in password storage?

A. To make password transmission confidential

B. To allow recovery of the original password

C. To prevent identical passwords from producing identical stored values

D. To replace the need for a password-hashing function

Correct Answer: C. To prevent identical passwords from producing identical stored values

Question 3

Which option is a phishing-resistant authentication method?

A. A password followed by a second password

B. A security key using FIDO2/WebAuthn

C. A password sent by email

D. A security question based on public information

Correct Answer: B. A security key using FIDO2/WebAuthn

Question 4

What is password spraying?

A. Trying many passwords against one account at high speed

B. Trying a small number of common passwords across many accounts

C. Recovering passwords from encrypted backups

D. Using a stolen Kerberos ticket to access a service

Correct Answer: B. Trying a small number of common passwords across many accounts

Question 5

Which AD component provides authentication and directory services?

A. Domain controller

B. Global Catalog only

C. Organisational unit

D. Security group

Correct Answer: A. Domain controller

Question 6

What does a Ticket-Granting Ticket enable a Kerberos client to do?

A. Change every domain password

B. Obtain service tickets from the KDC

C. Disable time synchronisation

D. Bypass all authorisation checks

Correct Answer: B. Obtain service tickets from the KDC

Question 7

Why is an SPN associated with a weak service-account password a security concern?

A. It prevents DNS from resolving the domain controller

B. It can permit offline analysis of service-ticket material

C. It automatically grants every user domain administrator rights

D. It disables MFA for all users

Correct Answer: B. It can permit offline analysis of service-ticket material

Question 8

Which delegation model should generally be avoided because credentials may be exposed on a compromised delegated host?

A. Resource-based constrained delegation

B. Constrained delegation

C. Unconstrained delegation

D. Role-based access control

Correct Answer: C. Unconstrained delegation

Question 9

Which control most directly limits the impact of excessive administrator permissions?

A. Least privilege and just-in-time privileged access

B. Increasing password complexity alone

C. Removing all audit logs

D. Allowing shared administrator accounts

Correct Answer: A. Least privilege and just-in-time privileged access

Question 10

During an authorised AD assessment, which approach is most appropriate?

A. Collect and publish all discovered passwords

B. Exploit every possible path regardless of operational impact

C. Use minimal-impact validation, protect evidence and retest remediation

D. Disable domain controllers to prove their importance

Correct Answer: C. Use minimal-impact validation, protect evidence and retest remediation