Active Directory / Advanced / Lesson 14

Directory hardening and service identities

Match protection to the actual LDAP/authentication method and service identity, then plan compatibility and evidence before any enforcement change.

About 5 min readContent reviewed 2026-10-26

On this page

Lesson goals

Separate signing, encryption, and channel binding protections.
Review managed service identities and host authorization.
Plan hardening without weakening controls to hide a failure.

One secure-sounding label does not cover every property

LDAP signing, SASL sealing, TLS, and channel binding address different security properties and contexts. Signing provides integrity/authenticity in applicable non-TLS SASL sessions, not confidentiality. TLS protects the transport when correctly configured and validated; channel binding ties applicable authentication to that TLS channel. Simple binds have their own transport-protection requirement. Do not claim that selecting port 636 alone proves certificate validation, account authorization, or application safety. Microsoft documents different defaults for new Windows Server 2025 deployments and older or upgraded environments, so record actual version, updates, effective policy, and client capabilities instead of inferring them from an OS label alone.

Compare declared requirements with client capabilities

The complete Python model checks two synthetic client capability sets against a chosen integrity requirement. It does not negotiate LDAP, validate a TLS certificate, interpret channel-binding tokens, or enforce a policy. A True means only that the declared set contains the modeled requirement; it is not proof of a secure connection. Real assessment must identify bind method, transport, trust validation, application library, and supported policy behavior. Use sanitized authorized observations to find dependencies that need migration. The model deliberately contains no endpoint, credential, cipher prescription, or traffic generator.

python Offline declared-protection compatibility model

required = {"integrity"}
clients = {
    "reviewed_client": {"integrity", "confidentiality"},
    "legacy_model": {"directory_query"},
}
for name, capabilities in clients.items():
    print(name, required <= capabilities)

Expected output

reviewed_client True
legacy_model False

The reviewed model is True and the legacy model False. No real protocol support or connection security is measured.

Choose service accounts from workload requirements

A service identity should have a specific owner, workload purpose, allowed hosts, necessary resource rights, and a managed lifecycle. gMSAs can provide managed domain identity and automatic password management for supported multi-server workloads, but they do not grant least privilege automatically. Host eligibility, application support, domain prerequisites, and service principal naming still need review. Windows Server 2025 also introduces newer service-account options with their own prerequisites; do not treat all managed-account types as interchangeable. Never copy an administrator identity into an application configuration to avoid a proper service design. No service account, key, or credential is created or retrieved here.

Plan compatibility, enforcement, and rollback separately

The contextual record names a review sequence rather than concrete policy values. It is not a registry file, Group Policy template, or command. Inventory consumers, establish effective current behavior, test approved clients in isolation, identify unsupported dependencies, and obtain a scoped enforcement plan. A failure after enforcement can be an application compatibility defect, certificate issue, naming issue, or another dependency; disabling protections globally conceals the cause and can increase exposure. A rollback must be authorized and risk-assessed, not an automatic instruction to return to an insecure state. Preserve evidence and migration ownership.

json Non-runnable directory-hardening review record

{"service":"synthetic-directory-consumer","review":["bind_method","transport_validation","signing_or_sealing","channel_binding_applicability","host_identity","least_privilege"],"enforcement":"requires_separate_approval"}

The record lists questions, not deployable policy values. It changes no LDAP requirement, certificate, service account, or authentication setting.

Verify intended acceptance and rejection

A hardening test needs a supported accepted client and a deliberately unsupported synthetic case, with the expected failure category and recovery owner documented. Event availability depends on policy, version, and diagnostic configuration; absence of one event is not proof every connection is protected. Protect logs because client identity and directory details can be sensitive. Test application functions after transport changes instead of stopping at a connection-success indicator. Managed service identities need resource-denial tests as well as startup success. This course validates only local set logic and leaves every actual directory, certificate, service, or policy operation unexecuted.

Common errors and fixes

Signing is assumed to hide directory data in transit.

Why it happens: Integrity and confidentiality were conflated.
How to fix it: Review the required encryption and bind context separately.
Prevent it next time: Document each required protection property.

A managed service identity receives broad administrative rights.

Why it happens: Automatic secret management was mistaken for least privilege.
How to fix it: Grant only reviewed workload and host/resource rights.
Prevent it next time: Test denied resources and review owners regularly.

A global security control is disabled after one client fails.

Why it happens: Compatibility evidence was replaced by a broad rollback.
How to fix it: Identify the client method and exact failing protection requirement.
Prevent it next time: Use scoped approved migration and enforcement plans.

Check your understanding

1. Add integrity to legacy_model in the set fixture. What changes and what critical questions are still unanswered?

Show worked solution

Its Boolean result becomes True, showing only that the model now declares the requirement. It still cannot prove the implementation signs the applicable traffic, validates the server, uses appropriate encryption, or is authorized for requested data. Keep capability declarations separate from measured protocol and application evidence. A changed label is not a hardening deployment.

2. A multi-server workload wants automatic service-password management. List the review areas before selecting a gMSA without performing account operations.