Smart card required password rotation Active Directory

Smart Card Required Password Rotation in Active Directory

Smart card required password rotation in Active Directory matters because these accounts still retain a network password secret. Without password rolling, the random secret established by Windows can persist until it is explicitly changed. The claim that it “never changes by default” needs an immediate qualification: Microsoft documents rolling as enabled for new domains, while existing domains require configuration. Treat this as a risk in domains where rolling is absent or disabled, rather than a universal property of modern Active Directory. Microsoft's Windows Server 2016 feature documentation makes that distinction.

The account option and the domain rotation setting answer different questions. The first determines whether the user must use a smart card for initial interactive sign-in, including Remote Desktop. The second controls maintenance of the password-based secret that remains relevant to network authentication. A review that stops at the account checkbox leaves the second question unanswered. Microsoft's account documentation describes both the interactive restriction and the remaining NT hash.

For administrators, the useful objective is therefore broader than “make the checkbox green.” Establish which identities require the card, whether their domain supports and enables rolling, and how you will demonstrate a successful reset on a representative account. This guide follows that sequence: inspect the account and domain, interpret the findings, then pilot remediation. The commands below are documentation-based examples; none was executed against a domain for this article.

The bit is an authentication requirement

The option maps to the cumulative userAccountControl flag SMARTCARD_REQUIRED, hexadecimal 0x40000, decimal 262144. Other flags can coexist with it. Reading the entire attribute as though it must equal 0x40000 would miss accounts carrying additional options. Microsoft's UserAccountControl reference lists the flag and explains the cumulative values.

Windows randomizes the account's secret when the requirement is enabled. Microsoft's administrative guidance describes an initially unknown random password and warns that someone with password-reset rights can subsequently set a known value and use certain network access paths. Requiring the card does not remove the importance of those reset permissions. Microsoft's least-privilege guidance is explicit about that remaining administrative capability.

How the Remaining Secret and Rolling Work

Random does not mean regularly replaced

Microsoft's account reference says that, without the additional rolling behavior, the generated value remains until a new password is set or the smart-card requirement is disabled and enabled again. A high-entropy initial value addresses guessing; keeping the same value after theft is a different concern. That is the distinction behind this review, not a claim that every smart card account has the oldest password in its domain. The documented account behavior supports the persistence and manual replacement mechanism.

Windows authentication also has to support subsequent access to network resources. Microsoft's credential-process documentation describes retention of the corresponding NT hash in its credential model after smart card sign-in. This establishes why the secret matters. It does not establish that an attacker can extract a hash from every endpoint regardless of its protections or the actual session. Keep the existence of a credential, its exposure, and its theft as separate investigative questions.

The domain setting enables policy-based expiration

The Boolean domain attribute msDS-ExpirePasswordsOnSmartCardOnlyAccounts controls expiration of smart-card-only account passwords according to password policy. It is not the per-user smart card bit. MS-ADA2's attribute definition identifies its purpose.

The feature requires a Windows Server 2016 domain functional level or higher. A domain controller's operating-system version alone does not demonstrate that prerequisite, and the requirement here is the domain level, not an invented forest-level prerequisite. Microsoft's feature page also documents the Active Directory Administrative Center option for existing domains. The rolling feature description is the reference for these deployment requirements.

Reset is part of eligible sign-in processing

During PKINIT AS-REQ processing, the KDC requests the smart-card-only password reset under the conditions defined in MS-PKCA's reset procedure. Successful completion causes it to restart processing the original request.

The responding service applies the expiration and validation rules in MS-SAMS's normative reset specification. An unexpired password returns success without replacement. Here, expiration means the protocol's computed condition, which also considers ticket-lifetime rules; it is not simply the collector's domain-age cutoff. For an expired password, validation includes the enabled domain attribute, a sufficient domain functional level, the smart card bit, and absence of DONT_EXPIRE_PASSWD. A successful reset generates new secrets and updates pwdLastSet to the current time.

This is sign-in processing subject to policy and protocol conditions. It is not a background timer, a replacement guaranteed at every logon, or a universal fixed-day schedule. As an operational inference, an account that rarely performs an eligible sign-in can retain an old date even when rolling is enabled. Investigate that account's policy and actual use before assigning a cause to the date.

Measure the Account and Domain Separately

Use a named domain controller for comparable reads, and replace corp.example, dc01.corp.example, the domain distinguished name, and admin-pilot with real values. Keep the identity, collection time, and raw results with your change record. The examples are assembled from documented cmdlet parameters; they are not presented as exact commands copied verbatim from Learn or as results from a customer audit.

Step 1 — Inventory accounts carrying the requirement

Get-ADUser documents -Filter, -Properties, and -Server. The Active Directory object model documents SmartcardLogonRequired and the PasswordLastSet property derived from pwdLastSet.

Get-ADUser -Filter {SmartcardLogonRequired -eq $true} -Properties pwdLastSet,PasswordLastSet,PasswordNeverExpires,Enabled,adminCount -Server dc01.corp.example

Read the enabled state and expiration exception alongside the dates. Preserve disabled accounts in the inventory if useful, but distinguish them from the enabled population evaluated by the rotation detector. A date is evidence about password maintenance; it does not independently date when the smart card bit was enabled.

For each account, record its owner, expected sign-in workflow, applicable policy, and expiration exceptions. Gather the workflow and ownership details separately; Get-ADUser does not establish them.

Step 2 — Identify the domain and functional level

Get-ADDomain accepts a domain identity and a server and returns domain information, including DomainMode and DistinguishedName.

Get-ADDomain -Identity corp.example -Server dc01.corp.example

Use the returned domain identity to confirm that subsequent reads target the intended naming context. Record the functional level separately from the domain controller's OS inventory. If the result cannot be obtained or identifies the wrong domain, resolve that measurement problem before drawing conclusions about feature availability.

Step 3 — Read the domain attribute and password-age policy

Get-ADObject documents reading an object by identity with additional LDAP properties. Read the root domain object, not an OU or an individual user:

Get-ADObject -Identity 'DC=corp,DC=example' -Properties msDS-ExpirePasswordsOnSmartCardOnlyAccounts,maxPwdAge -Server dc01.corp.example

Keep the raw maxPwdAge value with the domain setting. The collector's age comparison described below uses a day-based value derived from that policy. Do not substitute an arbitrary age target and then describe it as Microsoft's rolling requirement.

Treat an absent attribute, a false value, and a failed read as distinct investigative situations. Confirm the controller, domain identity, permissions, and completeness of the response. An empty console view is not sufficient evidence that a successful collection returned false.

Detection: Decide Which Question the Evidence Answers

Start with two populations: enabled accounts that require the card, and administrative identities that do not. Within the first population, determine whether rolling is enabled before evaluating age. Within the second, confirm actual administrative responsibilities before deciding where the requirement belongs. These are review steps derived from the detector criteria, not proof of an intrusion.

The table summarizes smartcard-rotation.go:48 and admin-no-smartcard.go:24, examined in full for this article. Their implementation is detailed in “How EtcSec Detects This.”

A useful evidence record separates the configuration observation, the account-age observation, and the cause you confirmed. For example, a stale date plus enabled rolling is a reason to investigate; it is not evidence that the domain attribute must secretly be disabled. Avoid describing the detector's name as the diagnosis of every account it returns.

Why the attack consequence remains conditional

If a still-current NT secret is actually stolen, its use depends on the authentication protocols and rights available along the target path. Our Pass-the-Hash guide explains that conditional reuse through NTLM. It also separates Overpass-the-Hash, which obtains Kerberos authentication material under the relevant conditions, from Pass-the-Ticket, which reuses a ticket. Do not infer that possession of one user's NT hash provides every ticket in an AES-based domain.

Keep the hardening objective precise: reduce persistence of a reusable password secret. Do not describe a successful password reset as universal revocation of already-issued tickets, existing network sessions, or certificates. Those need their own incident-response decisions.

Remediation: Enable Rolling Through a Controlled Pilot

Step 1 — Establish prerequisites and ownership

Before changing the domain, name the accountable administrator, select a representative pilot account, and confirm the domain functional level. Review the pilot's actual password policy and expiration exceptions. Arrange a way to test its smart card sign-in and required network access, with an agreed recovery procedure.

This is a recommended change plan, not a lab result. Its purpose is to expose dependencies before expanding the change. Do not use a successful write operation as the only acceptance criterion. Decide in advance which reads and authentication tests the change owner will retain as evidence.

The selected identities must also match the intended use. Microsoft's account reference says smart-card-required accounts cannot be used to start services or run scheduled tasks. Review such dependencies before changing an account's requirement. Microsoft's account guidance supplies that boundary.

Step 2 — Enable domain rolling

After validating the functional level and planning the pilot, adapt example 6 of Set-ADDomain:

Set-ADDomain -Identity corp.example -PublicKeyRequiredPasswordRolling $true -Server dc01.corp.example

The documented parameter sets msDS-ExpirePasswordsOnSmartCardOnlyAccounts to true. This is a domain change, even if validation begins with a single account. Inventory affected identities and their owners before applying it.

Immediately repeat the earlier domain-object read against the chosen controller. Then arrange an eligible pilot sign-in and repeat the user read. Record what actually happened rather than inserting expected output into the change record. If the date does not move, investigate eligibility and policy before repeating changes blindly. There is no replication delay or reset result promised by this example.

Step 3 — Use manual replacement only as a controlled procedure

Where automatic rolling cannot yet be used, Microsoft's account reference documents replacement by disabling and enabling the requirement. Set-ADUser documents the -SmartcardLogonRequired Boolean parameter. The following are two separate actions on a pilot account.

First clear the requirement:

Set-ADUser -Identity admin-pilot -SmartcardLogonRequired $false -Server dc01.corp.example

Then restore it:

Set-ADUser -Identity admin-pilot -SmartcardLogonRequired $true -Server dc01.corp.example

Read the account again, verify the requirement is restored, test the intended sign-in and network workflow, and confirm the relevant replicated state. Do not claim that this manual procedure always updates pwdLastSet identically to the normative automatic reset. Measure the outcome.

If a lower functional level prevents automatic rolling, document the manual procedure, ownership, and organizational schedule. Choose that schedule through your risk and operational process; do not label a chosen interval as a Microsoft requirement for this feature.

Step 4 — Review the real administrative perimeter

Use the complementary detector's selection as a starting list. The syntax below uses documented Get-ADUser parameters; the selection criteria come from admin-no-smartcard.go:24.

Get-ADUser -Filter {Enabled -eq $true -and adminCount -eq 1 -and SmartcardLogonRequired -eq $false} -Properties adminCount,userAccountControl -Server dc01.corp.example

Reconcile that list with current group memberships, delegated administration, application authority, and recovery identities. The detector reads an administrative marker; it does not calculate every form of effective privilege. Microsoft's least-privilege guidance discusses privilege across directory groups, member systems, and applications, which is why the review must extend beyond the query's population. Review administrative privilege and password-reset rights before applying account restrictions.

Validate the Change Without Overstating the Result

Build the validation record around observations a reviewer can reproduce: the domain and controller queried, the functional level, the raw rolling attribute, the account requirement, the policy reviewed, and the pilot's authentication outcome. Include timestamps and retain any errors. This is a recommended evidence format, not a claim that a single command supplies every item.

Distinguish “the setting is enabled” from “an eligible account's reset completed.” If the pilot is not due for expiration, an unchanged date can be consistent with the documented flow. If the reset succeeds, compare the new user observation with the earlier capture. For rarely used accounts, decide how their future validation will be organized rather than assuming that a domain change immediately renews every secret.

Finally, re-run the configuration assessment and examine both populations again. A remaining finding deserves investigation; a zero count needs collection context. Keep the administrative recovery plan available while the change expands. Closure should describe exactly what was verified and what still depends on future sign-ins or separate controls.

How EtcSec Detects This

SMARTCARD_PASSWORD_ROTATION_DISABLED

The implementation in ad/advanced/other/smartcard-rotation.go:48 first handles missing domain information by returning a finding with Count: 0. It then selects enabled users whose userAccountControl contains 0x40000.

It has two actual branches:

• Domain setting false: every user in that enabled, smart-card-required population is selected, independently of PasswordLastSet. A recent password change does not remove the configuration finding.
• Domain setting true: age is evaluated only when MaxPasswordAge > 0. The account is selected if PasswordLastSet is zero or strictly before Now.AddDate(0, 0, -MaxPasswordAge). Equality is not selected. With maximum age zero, this branch infers no age finding.

These branches are at smartcard-rotation.go:79–87; the policy threshold is at 62–66. The check neither uses a fixed-day threshold nor proves that a reset occurred during a particular sign-in.

ADMIN_NO_SMARTCARD

The complementary implementation in ad/accounts/advanced/admin-no-smartcard.go:24 selects enabled users with AdminCount=true and the smart card bit absent, through the conditions at 29–41. It does not examine password age or the domain rolling attribute.

The two checks evaluate different account populations. One reviews maintenance of the secret behind a required smart card; the other identifies accounts in its administrative selection without that requirement. Neither should be presented as eliminating all password-based attacks.

What these findings do not measure

Neither Detect() validates the domain functional level, computes each user's effective fine-grained password policy, checks DONT_EXPIRE_PASSWD, proves successful logon or reset, or inventories administrators outside adminCount. The LDAP collection maps a true rolling attribute to a Boolean and maps absent or false to false; it derives maximum password age from maxPwdAge (providers/ldap/client.go:636,662–669). That collection boundary matters when interpreting the first branch.

A zero count can therefore mean no selected users, an age comparison without a positive threshold, or unavailable domain information. It is not standalone proof of complete collection or working rotation. Use the findings to guide the account and domain measurements above, and retain the pilot evidence that demonstrates the behavior you actually verified.