I was browsing thru the new schema updates in Windows Server TP 4 and found an interesting new attribute: ms-DS-Expire-Passwords-On-Smart-Card-Only-Accounts

Sch83.ldf:

dn: CN=ms-DS-Expire-Passwords-On-Smart-Card-Only-Accounts,CN=Schema,CN=Configuration,DC=X
changetype: ntdsSchemaAdd
objectClass: attributeSchema
CN: ms-DS-Expire-Passwords-On-Smart-Card-Only-Accounts
attributeID: 1.2.840.113556.1.4.2344
attributeSyntax: 2.5.5.8
adminDisplayName: ms-DS-Expire-Passwords-On-Smart-Card-Only-Accounts
adminDescription: This attribute controls whether the passwords on smart-card-only accounts expire in accordance with the password policy.
oMSyntax: 1
lDAPDisplayName: msDS-ExpirePasswordsOnSmartCardOnlyAccounts
isSingleValued: TRUE
systemOnly: FALSE
schemaIDGUID:: SKsXNCTfsU+AsA/LNn4l4w==
systemFlags: 16
searchFlags: 0
instanceType: 4

Well, this sound interesting if you read the adminDescription:

This attribute controls whether the passwords on smart-card-only accounts expire in accordance with the password policy.

No much more info when I tried to search the internet.

If we search for the attribute we can find it being used at the root of DNC corp.secid.se

If you promote a Windows Server 2016 Domain Controller in a 2012R2 domain (or older) the value is set to False.
If you set it to True nothing fun happened. Neither when I moved the PDC fsmo role to the 2016 Domain Controller. Just to see if this has anything to do with PDC e more than the standard password management.

I demoted the 2012R2 DCs and raised the domain mode to WindowsThresholdDomain and now it gets interesting.

With my tests I created a Fine-grained Password Policy with the password set to expire in 5 minutes. Assigned it to one of my smart card user:

New-ADFineGrainedPasswordPolicy -ComplexityEnabled:$true -LockoutDuration:”00:30:00″ -LockoutObservationWindow:”00:30:00″ -LockoutThreshold:”0″ -MaxPasswordAge:”00.00:05:00″ -MinPasswordAge:”00.00:00:00″ -MinPasswordLength:”120″ -Name:”Admin-Policy” -PasswordHistoryCount:”24″ -Precedence:”1″ -ReversibleEncryptionEnabled:$false -Server:”DC-TP4.corp.secid.se”

Add-ADFineGrainedPasswordPolicySubject -Identity:”CN=Admin-Policy,CN=Password Settings Container,CN=System,DC=corp,DC=secid,DC=se” -Server:”DC-TP4.corp.secid.se” -Subjects:”CN=Danne,OU=Users,OU=Data Admins,OU=Admin,DC=corp,DC=secid,DC=se”

On my smart card user account I have enabled the User Account Control: Smart card is required for interactive logon.

Each time the smart card user authenticates and the password has expired, the password is automatically changed by the DC.
This can be seen on the pwdLastSet attribute on the user account:

Or if we look at the object metadata the password attributes is updated:

And last we can extract the NTLM hashes with e.g. mimikatz and compare them:

And why do we like this?

If we first take a look at the User Account Control: Smart card is required for interactive logon

From Microsoft:
Ticking the ‘Smart Card is required for interactive logon’checkbox for a user resets the password for that user to a random complex password that is unknown to anyone and the UserAccountControl attribute of the user gets the flag SMARTCARD_REQUIRED added to it.

In addition to this, the DONT_EXPIRE_PASSWORD flag on the account is set so that the user’s password never expires. The GINA or LogonUI components on the client check for the presence of the SMARTCARD_REQUIRED flag during an interactive logon (console or RDP) and reject the logon if it isn’t made with a smartcard when it is set for the user.

Using a smart card is a pretty good idea and it provides a strong authentication. The problem here is when a smart card user authenticates, the domain controller provides the client with the NTLM hash to support SSO. If a malicious user gets on hold of the NTLM hash he can impersonate that user as long as it exists, since the password is set to never expire.

One of the most common solutions to this is a scheduled task running a script changing the smart card user passwords e.g. fliping the require smart card.. bit of and on again making the DC generate a new random password. In a large environment this could be quite consuming for the script to run.

If it’s managed automatically by the authenticating DC its pretty good load balanced and you don’t need to rely on a script.

Conclusion:

This is a really good improvement and helps us maintain better security by automatically changing the Smart Card users’ passwords when it has expired.

To be able to use this new functionality, the domain mode needs to be at: WindowsThresholdDomain (for now).

The attribute: ms-DS-Expire-Passwords-On-Smart-Card-Only-Accounts is a domain level configuration.

The password is automatically changed on the “smart card only” user accounts according to the password policy.

Since the password is changed when a user authenticates after password expiration, it’s pretty good load balanced cross the domain.

If you still have users in your domain using only passwords I would recommend configuring a more aggressive Fine-grained password policy for your smart card users. Let the password expire after a couple of days, or map it to the Kerberos TGT lifetime policy.