Active Directory Account Design

Scope

This page examines Active Directory (AD) account design from both operator and attacker perspectives. An account is a security principal that connects credentials to permissions. In designing accounts, consider who can create them and which paths can lead to which privileges.

Think in terms of issuance, mapping, use, and auditing

When a decision is unclear, divide it into four questions:

• Issuance: Who can create accounts or credentials?
• Mapping: How do we identify the owner of a credential?
• Use: Which services and privileges can it reach?
• Auditing: Can we trace when, by whom, and where it was used?

Issuing and mapping identities

flowchart TB
    subgraph Issuers["Issuing authorities (Issuers)"]
        DC["DC/KDC (Domain Controller)"]
        CA["AD CS / CA (Certificate Authority)"]
    end
    Account["Account (User/Computer/Service)"]
    SID["SID (Security Identifier)"]
    SPN["SPN (servicePrincipalName)"]
    Ticket["Kerberos Ticket (TGT/TGS)"]
    Cert["Certificate (X.509)"]
    Resource["Resource / Service"]

    Account --> SID
    Account --> SPN
    DC --> Ticket
    CA --> Cert
    Ticket --> Resource
    Cert --> Resource
    SID --> Resource

The DC’s KDC issues Kerberos tickets, while the CA issues certificates. Both are starting points for identity verification, so their issuance rights and mappings to accounts need to be checked.

Basic concepts

SIDs and accounts: identifiers versus names

A SID (Security Identifier) is a unique identifier within AD. ACLs (Access Control Lists) bind to SIDs, not names.

• Names (SamAccountName/UPN) can change in operations, but SIDs are generally immutable.
• Accounts with the same name but different SIDs are different principals. Conversely, a renamed account retains its rights if its SID stays the same.
• SIDHistory is useful during migration, but abuse can turn it into a way around intended privilege boundaries.

Design implication: Treat the account name as a label and the SID as the identity itself. This makes certificate mapping and permission audits easier to reason about.

SPNs (servicePrincipalName) and “SPN density”

An SPN is an attribute Kerberos uses to identify the account providing a service. The account on which an SPN is registered receives the Kerberos service ticket (TGS).

• An account with many SPNs concentrates the authentication entry points of multiple services in one place.
• Duplicate SPNs create ambiguity for Kerberos and break authentication.

Why SPN density amplifies the impact of compromise

An account with high SPN density gives an attacker a point from which a single compromise can spread to multiple services. For example, if Kerberoasting (offline analysis of a Kerberos ticket) exposes that account’s credentials, all associated services become vulnerable at once.

flowchart LR
    svc["svc-app (Service Account)"]
    spn1["SPN: HTTP/app01"]
    spn2["SPN: MSSQLSvc/db01"]
    spn3["SPN: HOST/file01"]
    svc --> spn1
    svc --> spn2
    svc --> spn3

Foundations of Kerberos authentication

Kerberos is a protocol that proves identity with tickets. Authentication rests on these assumptions:

• The KDC (Key Distribution Center) runs on a DC and is central to issuing identities in the domain.
• Clients and servers identify each other through SPNs.
• Broken time synchronization can invalidate tickets.
• The PAC (Privilege Attribute Certificate) carries SIDs and group information used in authorization decisions.
• TGTs (Ticket Granting Tickets) and TGSs (service tickets) make up the authentication flow.

Design implication: A Kerberos-based design requires correctly managed SPNs and recognizes the DC as the center of the trust boundary.

Design by account type

User accounts

Operator perspective

User accounts are the entry point for work, the most numerous account type, and costly to operate. Identity lifecycle management and access control directly determine how their risks are managed.

Attacker perspective

For attackers, user accounts are a primary initial access target. Compromise through credential reuse, phishing, or MFA (Multi-Factor Authentication) bypass can provide a foothold for lateral movement.

Design decisions

• Recommended: Separate administrator accounts from everyday accounts and enforce tiering (Tier 0 = AD infrastructure / Tier 1 = servers / Tier 2 = clients).
• Recommended: Automate reviews of disabled accounts and accounts belonging to former employees so abandoned accounts do not accumulate.
• Avoid: Making shared accounts a routine practice.
• Avoid: Granting ordinary users permanent rights such as Domain Admin.

computer account

Operator perspective

A computer account is the identity of a domain-joined device. It can also be a principal for GPO (Group Policy Object) application, certificate distribution, and Kerberos authentication, so it is closely tied to server design.

Attacker perspective

A compromised device’s computer account provides credentials usable for domain authentication. Excessive rights or delegation settings on server computer accounts can directly enable lateral movement or delegation abuse.

Design decisions

• Recommended: Separate OUs (Organizational Units) by device type (client/server/infrastructure), and separate GPOs and delegation scopes accordingly.
• Recommended: Understand that Resource-Based Constrained Delegation (RBCD) is authorized by the destination resource and keep its scope as small as possible.
• Avoid: Mixing business application permissions into critical computer accounts.
• Avoid: Domain-joining unnecessary servers and expanding the management scope.

Service accounts

Operator perspective

Service accounts are identities that people do not log into. Their privileges tend to grow during long-term operation. SPN and password management are central design concerns.

Attacker perspective

Service accounts are major targets for Kerberoasting and credential dumping. Taking over an account with high SPN density can immediately open paths to multiple services.

Design decisions

• Recommended: Assign a dedicated account to each service and spread SPNs across accounts.
• Recommended: Migrate to gMSAs where possible and stop managing passwords manually.
• Avoid: Concentrating many SPNs on one account.
• Avoid: Allowing interactive logon for service accounts.

gMSA

Operator perspective

By automating passwords and assuming Kerberos, gMSAs substantially reduce operational effort and the risk of credential exposure. The key question is who can retrieve the password.

Attacker perspective

A gMSA may be safe in itself, but broad access to its password (Read msDS-ManagedPassword) can enable lateral movement from a compromised host. The allowed group design is the defensive boundary.

Design decisions

• Recommended: Limit hosts using a gMSA to the smallest possible group and delegate rights by OU.
• Recommended: Document each gMSA’s purpose, associated SPNs, and hosts that use it.
• Avoid: Reusing a gMSA as a universal service identity.
• Avoid: Adding hosts to a gMSA without audit logs.

Domain Controller (DC)

Operator perspective

The DC, which runs the KDC, is the heart of identity issuance. Unauthorized logon there undermines trust in every account.

Attacker perspective

Compromising a DC can yield secrets for the entire domain through techniques such as DCSync (abuse of the Directory Replication API). Even temporary access to a DC is critical.

Design decisions

• Recommended: Isolate DCs as Tier 0 and manage them only from a PAW (Privileged Access Workstation).
• Recommended: Strictly limit users allowed interactive logon on DCs.
• Avoid: Running ordinary applications or other roles, such as file serving, on DCs.
• Avoid: Keeping unnecessary service accounts resident on DCs.

Certification Authority (AD CS / CA)

Operator perspective

AD CS (Active Directory Certificate Services) provides another route for issuing identities through certificates. Alongside Kerberos, it is authentication infrastructure, so CA operations directly affect AD security.

Attacker perspective

Abusing certificate issuance can allow privileged logon without touching a password. ESC-class misconfigurations permit identity forgery.

Design decisions

• Recommended: Isolate CAs as Tier 0 and minimize rights to change templates.
• Recommended: Enable Strong Certificate Mapping (strict SID-based mapping) and use the SID extension.
• Avoid: Granting broad Enrollment rights on highly privileged templates.
• Avoid: Exposing Web Enrollment (AD CS Web) without adequate precautions.

Classify AD CS attack paths

ESC attacks against AD CS are best understood as attacks on the identity issuance path, rather than merely a collection of techniques. ESC1 through ESC8 can be grouped as follows:

Category	Broken boundary	Representative ESCs	Impact
Breakdown of identity in template/enrollment flow	Mismatched Subject/UPN/SAN/EKU/Enrollment	ESC1–ESC4	Certificates can be issued for another account
Compromise of CA administration or protocol path	CA rights, Web Enrollment, NTLM Relay, etc.	ESC5–ESC8	Control of the CA itself or takeover of the issuance path

Note: Subject/UPN/SAN express the identity on a certificate; EKU (Extended Key Usage) limits what the certificate can be used for; Enrollment defines who can request and issue it. Loose settings undermine the answer to “Whose certificate is this?”

Meaning and danger of ESC16 (disabled SID security extension)

ESC16 refers to a situation where a certificate is not properly bound to a SID. If the SID extension is disabled or not validated, mapping may rely only on the certificate’s Subject/UPN, making impersonation of another account easier.

Design implication: This breaks AD’s SID-centered design and lets the certificate’s displayed identity determine the account. CA operations should therefore be as strictly controlled as DC operations.

How account design relates to security

Account design gives an organization answers to three questions:

• “Who can issue an identity?”: How are the operational boundaries of DCs and CAs protected?
• “What guarantees the identity?”: Are SID, SPN, and certificate mapping consistent?
• “How far can a compromise spread?”: SPN density and permission design determine the blast radius.

All of these depend on account operations design. That is why AD account design is itself a security concern.

PKINIT and TGT issuance

Concept

In brief:

• PKINIT performs initial authentication with an AS-REQ using a certificate.
• The certificate does not become a TGT; the KDC issues the TGT.
• After a TGT is acquired, the flow is the same whether authentication used a password or certificate, and the PAC carries authorization information.

PKINIT (Public Key Cryptography for Initial Authentication in Kerberos) performs pre-authentication for initial authentication (AS: Authentication Service) with a certificate instead of a password. AS-REQ/AS-REP (Authentication Service Request/Response) are the request and response for that initial authentication. The key distinction is that the certificate itself does not become the TGT (Ticket Granting Ticket); the KDC issues a TGT based on the certificate.

The KDC (Key Distribution Center) signs TGTs using krbtgt, the service account holding the KDC’s long-term key. The PAC (Privilege Attribute Certificate) is trusted through the KDC’s signature and affects subsequent authorization. Thus, the trust boundary lies with KDC/krbtgt and the PAC signature.

UPN (User Principal Name) is an account’s unique logon name, altSecurityIdentities is an attribute for certificate mapping, and userAccountControl (UAC) contains account control flags. The KDC uses this directory information to map certificates to accounts.

ASCII diagram: ordinary AS-REQ/AS-REP versus PKINIT (KDC view)

(Ordinary: password-based pre-authentication)
[Client] --AS-REQ (PA-ENC-TIMESTAMP)--> [KDC/krbtgt]
                [KDC] --(AD lookup: SID/UPN/userAccountControl/Group)--> [Directory]
[Client] <--AS-REP (TGT + PAC)--------- [KDC/krbtgt]

(PKINIT: certificate-based pre-authentication)
[Client(cert+private key)] --AS-REQ (PA-PK-AS-REQ)--> [KDC/krbtgt]
                     [KDC] --(AD lookup: UPN/altSecurityIdentities/userAccountControl)--> [Directory]
[Client] <--AS-REP (TGT + PAC)----------------------- [KDC/krbtgt]

*Note: A certificate is evidence of identity; the TGT is an authorization token issued by the KDC.

Note: PA-ENC-TIMESTAMP is password-based pre-authentication data; PA-PK-AS-REQ is certificate-based pre-authentication data.

ASCII diagram: when a certificate leads to a TGT through PKINIT

(Preparation) Client has 1) a certificate and 2) a private key

[Client] --AS-REQ(+PA-PK-AS-REQ: certificate/signature/key exchange)--> [KDC/krbtgt]
              |
              | KDC-side checks (important)
              | - Is the certificate chain trusted?
              | - Is the certificate's intended use (EKU, etc.) suitable for logon?
              | - Which AD account does the certificate map to?
              | - Depending on policy, can revocation (OCSP/CRL) be checked?
              v
[Client] <--AS-REP(TGT + session key)------------------ [KDC/krbtgt]
                ^ This is when the certificate leads to a TGT

The key point: after a TGT is issued, the certificate’s role fades and the TGT/PAC becomes the basis for authorization. The flow after acquiring a TGT is the same for password-based and certificate-based authentication.

[Client] --TGS-REQ (present TGT)--> [KDC] --TGS-REP (TGS)--> [Client]

This is why misconfiguration can be so damaging. If the KDC issues a TGT incorrectly, subsequent authorization continues to use information in the TGT/PAC, so the impact may be broad and long-lasting.

Implementation perspective

With PKINIT, the client sends an AS-REQ signed with a certificate, and the KDC verifies the certificate before issuing a TGT. The KDC’s decision has three layers: whether the certificate is trusted, which AD account it maps to, and whether that account satisfies logon conditions.

Summary of the KDC’s decision points

• Chain validation: Is the issuing CA trusted, and is the certificate chain valid?
• Revocation validation: Can revocation be checked through a CRL (Certificate Revocation List) or OCSP (Online Certificate Status Protocol)?
• Intended-use validation: Are the EKU/KU suitable for Kerberos logon?
• Mapping: Can UPN (User Principal Name), SID, altSecurityIdentities (certificate-mapping attribute), etc. resolve the account unambiguously?
• Account status: Do userAccountControl (UAC: account control flags) or logon restrictions prohibit access?
• Policy: Are Strong Certificate Mapping requirements met?

Pseudocode (KDC decision flow)

if not verify_cert_chain(cert): reject
if is_revoked(cert): reject
if not eku_allows_logon(cert): reject
account = map_cert_to_account(cert, directory)
if account is None: reject
if account.uac_disallows_logon(): reject
if not strong_mapping_ok(cert, account): reject
issue_tgt_with_pac(account, krbtgt_key)

Operations perspective

Operations must protect both CA-side issuance settings and KDC-side evaluation rules. Even a permissive certificate template can be countered if the KDC evaluates certificates strictly. Conversely, weak KDC mapping increases the risk that a certificate with only a convincing appearance will be accepted.

• Trust boundary: The TGT and PAC signatures issued by KDC/krbtgt are the basis of trust.
• Design risk: Disabling strong mapping, allowing requesters to supply Subject/SAN in certificate templates, or ineffective revocation checks can let certificates pass KDC evaluation improperly.
• Audit correlation: Make it possible to correlate CA-side template changes and issuance logs with KDC-side logon events.

Audit perspective

An audit tracks who can issue each certificate and under which conditions the KDC accepts it. Check both template settings visible through LDAP and KDC mapping/policy settings.

Troubleshooting perspective

Certificate logon failures often stop at KDC evaluation. Organize them by cause, check, and remedy:

• Cause: untrusted chain -> Check: CA trust store/intermediate certificates -> Remedy: distribute root/intermediate certificates
• Cause: EKU mismatch -> Check: certificate EKU/KU -> Remedy: correct the template and reissue
• Cause: mapping failure -> Check: UPN/altSecurityIdentities match -> Remedy: revise mapping rules
• Cause: revocation check failure -> Check: CRL/OCSP reachability -> Remedy: improve revocation infrastructure availability
• Cause: clock skew -> Check: NTP/AD time synchronization -> Remedy: correct the time source

Audit checklist (PKINIT)

• Is Strong Certificate Mapping enabled on the KDC?
• Are the CA and template restricted to Kerberos logon use?
• Are revocation checks (CRL/OCSP) designed to work continuously?
• Is certificate mapping (UPN/SID/altSecurityIdentities) unambiguous?

Common operational pitfalls

• Requiring PKINIT without ensuring revocation services are reachable.
• Allowing requester-supplied Subject/SAN in a template while weakening KDC mapping requirements.
• Operating KDC and CA issuance logs separately so they cannot be correlated.

AD CS templates from the KDC’s perspective

Concept

AD CS templates may look like “CA settings,” but the KDC does not read them directly. The KDC evaluates the properties of the certificates produced by a template. Think of a template as a specification for certificates the KDC may accept.

ASCII diagram: templates and KDC evaluation

[Template] --(configuration)--> [CA] --(issue certificate)--> [Client]
                                     |
                                     v
                          [KDC] --(evaluate certificate)--> TGT/PAC

Implementation perspective

Five questions from the KDC’s perspective make template evaluation clearer:

1. Is the chain trusted (Chain Trust)?
2. Is the intended use suitable for logon (EKU/KU)?
3. Which account does it map to (Mapping)?
4. Are restrictions effective enough (Policy/Restriction)?
5. Are revocation and validity handled safely (Revocation/Validity)?

Reading template attribute categories

The following uses the order “effect on certificate -> effect on KDC -> operational meaning.”

• EKU / KeyUsage

  • Certificate effect: Determines the intended use (Client Authentication/Smartcard Logon, etc.) and key usage.
  • KDC effect: A certificate without the EKU needed for logon is rejected. Broader uses widen what is accepted.
  • Operational meaning: Apply the principle of minimum use and confine logon use to limited templates.

• Subject/SAN generation rules (SAN: Subject Alternative Name; Name Flag: rules for automatically generating Subject/SAN)

  • Certificate effect: Places a UPN or DNS name in the certificate.
  • KDC effect: These fields are used for mapping, so requester-supplied values can undermine identity.
  • Operational meaning: Prefer automatic Subject/SAN generation from the directory; avoid manual input.

• Enrollment Flag (AutoEnroll: automatic enrollment, etc.)

  • Certificate effect: Determines whether automatic enrollment is available.
  • KDC effect: The KDC does not read this directly, but broader issuance increases the attack surface.
  • Operational meaning: Minimize the AutoEnroll scope and limit it to necessary OUs/groups.

• Issuance gates (Manager Approval / Authorized Signatures)

  • Certificate effect: Adds manual approval or signature requirements.
  • KDC effect: Restricting issuance reduces the risk of improperly issued certificates.
  • Operational meaning: High-risk uses should have an approval flow.

• Validity / Renewal / KeyLength

  • Certificate effect: Determines the certificate lifetime and key strength.
  • KDC effect: Long validity extends the impact of a compromise.
  • Operational meaning: Choose shorter lifetimes and operate a renewal process.

• Permissions (Enroll/AutoEnroll/Write/Owner)

  • Certificate effect: Determines who can enroll and who can change the template.
  • KDC effect: The KDC does not read this directly, but a broader set of issuers increases risk.
  • Operational meaning: Keep Enroll/AutoEnroll and template-change rights to a minimum.

Operations perspective

Operate template design as a specification for certificates the KDC will accept. To protect the KDC trust boundary (TGT/PAC signatures), narrow issuance conditions and make mapping strong.

Hypothetical template example: CORP-User-Logon-v1

Attribute category	Example setting	Meaning from the KDC’s perspective
EKU	Client Authentication, Smartcard Logon	Limited to logon use
Subject/SAN	UPN automatically generated from AD	Mapping is more likely to be unambiguous
Enrollment	AutoEnroll = enabled	Scope needs to be limited
Issuance gate	Manager Approval = disabled	Lower operational effort, but weaker control against improper issuance
Validity	1 year / Renewal 6 months	Limits the impact duration after compromise
KeyLength	2048	Minimum baseline for key strength
Permissions	Enroll: GRP-User-Logon, Write/Owner: PKI-Admins	Separates issuance rights from change rights

Interpretation (KDC perspective): Automatically generated UPNs make mapping clearer, but broad AutoEnroll increases the risk of improper issuance. Without an issuance gate, audits need to examine issuance history more closely.

Audit perspective

Template settings are visible through LDAP and are a primary audit target. Which certificates the KDC accepts depends on the combination of template settings, so focus audits on template change history and access rights.

Troubleshooting perspective

Organize typical certificate logon failures by cause, check, and remedy:

• Cause: EKU mismatch -> Check: certificate EKU/KU -> Remedy: correct the template
• Cause: mapping failure -> Check: UPN/SAN against AD -> Remedy: correct the Name Flag
• Cause: untrusted chain -> Check: trust state of CA certificate -> Remedy: distribute root/intermediate certificates
• Cause: revocation check failure -> Check: CRL/OCSP reachability -> Remedy: improve revocation infrastructure availability
• Cause: incorrectly assigned template rights -> Check: Enroll/AutoEnroll/Write ACL -> Remedy: narrow the rights

Audit checklist (templates)

• Is the scope of Enroll/AutoEnroll minimized?
• Is requester-supplied Subject/SAN disallowed?
• Are EKU/KU limited to logon use?
• Are template-change rights (Write/Owner) no broader than needed?
• Do certificate lifetime and key length match organizational policy?

Common operational pitfalls

• Assuming CA-side settings are unrelated to the KDC.
• Enabling AutoEnroll broadly so the population of recipients grows without control.
• Delegating template-change rights broadly to operations groups.

How LDAP information reaches Kerberos tickets

Concept

LDAP is a protocol; the directory information itself is what matters. The KDC reads directory information through LDAP to build TGTs, TGSs, and PACs. TGS (Ticket Granting Service) is the service-ticket issuance phase. LDAP is thus a window into the data, while Kerberos turns that data into tickets.

TGS-REQ/TGS-REP (Ticket Granting Service Request/Response) are the request and response for a service ticket.

ASCII diagram: directory information flowing into Kerberos tickets

AS (authentication)
[Client] --AS-REQ--> [KDC] --(read Directory attrs)--> [Directory]
[Client] <--AS-REP (TGT + PAC)------------------------ [KDC]

TGS (service ticket)
[Client] --TGS-REQ--> [KDC] --(read SPN/Delegation)--> [Directory]
[Client] <--TGS-REP (Service Ticket)----------------- [KDC]

Authorization
[Service] --(PAC/ACL lookup)--> [Directory/Local ACL]

Implementation perspective

Mapping LDAP-visible data to its use in Kerberos

LDAP attribute	Use in Kerberos	Audit and defense perspective
userPrincipalName (UPN)	Certificate/logon mapping	Enforce uniqueness and naming conventions
sAMAccountName	Legacy logon name and identification in tickets	Audit duplicates and naming conflicts
objectSid	Primary identifier in the PAC	Manage and review SIDHistory
memberOf	Reflected in group information in the PAC	Audit excessive group memberships
primaryGroupID	Used to calculate the default group’s SID	Review legacy compatibility
servicePrincipalName (SPN)	Identifies the recipient of a TGS	Detect and resolve duplicate SPNs
userAccountControl	Affects logon availability, delegation, pre-authentication, etc.	Review DONT_REQ_PREAUTH (pre-authentication not required) / TRUSTED_FOR_DELEGATION (delegation permitted)
msDS-AllowedToDelegateTo	Constrained Delegation	Minimize and review delegation targets
msDS-AllowedToActOnBehalfOfOtherIdentity	RBCD (Resource-Based Constrained Delegation)	Audit excessive delegation rights
altSecurityIdentities	Used for certificate mapping	Audit accounts eligible for certificate logon

Information not visible through LDAP but central to Kerberos security

• The krbtgt secret key and account secrets: They underpin TGT signing, and exposure can undermine trust across the domain.
• Password hashes/encryption keys: They are not directly visible through LDAP, but the KDC uses them for authentication.
• Internal KDC policy/cache: These affect strong mapping and revocation-check behavior.

Operations perspective

LDAP attribute design directly determines Kerberos behavior, so consistency of directory information is crucial. Protecting the KDC/krbtgt trust boundary requires managing SPNs, groups, and delegation attributes according to least privilege.

Audit perspective

Audits should focus on how directory settings are reflected in tickets. SPNs, delegation attributes, and certificate-mapping attributes are especially important audit targets for containing attacks.

Troubleshooting perspective

Inconsistent directory attributes can cause Kerberos failures or incorrect authorization. Organize issues by cause, check, and remedy:

• Cause: duplicate SPNs -> Check: detect duplicates in the SPN list -> Remedy: reassign SPNs
• Cause: inconsistent group information -> Check: memberOf/primaryGroupID -> Remedy: correct group design
• Cause: misconfigured delegation attributes -> Check: msDS-AllowedToDelegateTo/RBCD -> Remedy: narrow delegation scope
• Cause: certificate-mapping problem -> Check: altSecurityIdentities/UPN -> Remedy: standardize mapping rules

Audit checklist (LDAP and Kerberos)

• Check SPN design for duplicates and excessive concentration.
• Review excessive group memberships and privileges.
• Review delegation settings (Constrained Delegation/RBCD).
• Check certificate-mapping rules (altSecurityIdentities/UPN).

Common operational pitfalls

• Overlooking the effect of LDAP attribute changes on Kerberos authorization.
• Leaving duplicate SPNs in place because authentication seems to work.
• Making delegation exceptions permanent and neglecting their review.

Glossary and references

Glossary

• PKINIT (Public Key Cryptography for Initial Authentication in Kerberos): Initial authentication using a certificate in an AS-REQ.
• AS-REQ/AS-REP (Authentication Service Request/Response): Initial authentication request and response.
• TGT (Ticket Granting Ticket): Authentication ticket issued by the KDC; used to obtain subsequent TGSs.
• TGS (Ticket Granting Service): Service-ticket issuance phase.
• PAC (Privilege Attribute Certificate): Signed by the KDC and carries authorization information including SIDs and groups.
• krbtgt: Account holding the long-term key the KDC uses to sign TGTs.
• EKU (Extended Key Usage): Restricts the purposes of a certificate.
• KU (Key Usage): Restricts the uses of a certificate’s key.
• RBCD (Resource-Based Constrained Delegation): Delegation in which the resource side authorizes delegation.
• Strong Certificate Mapping: Strict mapping between a certificate and an account using, for example, the SID extension.

References

• RFC 4120: Kerberos Version 5
• RFC 4556: PKINIT (Public Key Cryptography for Initial Authentication in Kerberos)
• RFC 4762: Microsoft Kerberos PAC
• Microsoft Docs: Kerberos Authentication in Active Directory
• Microsoft Docs: Active Directory Certificate Services Overview
• Microsoft Docs: Certificate Templates in Active Directory Certificate Services
• Microsoft Docs: Strong Certificate Mapping and SID Extension
• Microsoft Docs: Service Principal Names (SPN) and Kerberos Authentication