PCNS and Kerberos S4U2Self updating lastLogonTimestamp

While trying to decommission a legacy user domain that was a target for MIM password synchronisation, I noticed that lastLogonTimestamp was being updated whenever a password was changing in another connected forest. It turns out this was because we still had PCNS on Domain Controllers in the legacy forest (for bi-directional password sync), and a ‘feature’ of PCNS is to update lastLogonTimestamp due to a Kerberos S4U2Self network logon. Note that this is still governed by the ‘ms-DS-Logon-Time-Sync-Interval’ attribute (default 14 days) providing a window so that LLT isn’t updated *every* time you log on, only as soon as you fall out of the time sync window.

I poked around a little and I believe this occurs because the pcnssvc.exe calls the AuthzInitializeContextFromSid() function, which appears to perform a network logon of the target user to grab information from the token. This uses the Kerberos 2003 extensions for S4U (service for user). This made it invalid to use lastLogonTimestamp as a mechanism to determine whether accounts are still being logged in to, as PCNS was making it seem like they were!

I also think that anything that uses the S4U extensions will exhibit the same behaviour. For example, to do an equivalent in PowerShell, you can create a new windows identity object with only the UPN, which also results in a network logon of the target account:

  new-object system.security.principal.windowsidentity("user@domain.com")

This results in event 4624 network logon on the local machine - which consequently will fail if the target user doesn’t have SeNetworkLogonRight – ‘Access this computer from the network’ right:

  Logon Information:
 Logon Type:  3
 Restricted Admin Mode: -
 Virtual Account:  No
 Elevated Token:  Yes

  Impersonation Level:  Identification

And looking at the Kerberos conversation, after getting a TGT, it ends doing a AP-REQ using the ‘PA-FOR-USER’ S4U2Self structure:

And once the ticket has been acquired, if you use ‘klist tickets’, you’ll see the krbtgt and the S4U ticket (only showing your user, it won’t display the:

References:

AuthzInitializeContextFromSid function
http://msdn.microsoft.com/en-us/library/windows/desktop/aa376309(v=vs.85).aspx AuthzInitializeContextFromSid attempts to retrieve the user's token group information by performing an S4U logon. AuthzInitializeContextFromSid attempts to retrieve the information available in a logon token had the client actually logged on. An actual logon token provides more information, such as logon type and logon properties, and reflects the behavior of the authentication package used for the logon.

WindowsIdentity Constructor (String)
http://msdn.microsoft.com/en-us/library/td3046fc.aspx
This constructor is intended for use on computers joined only to Windows Server 2003 domains. An exception is thrown for other domain types. This restriction is because the constructor uses the KERB_S4U_LOGON structure.

Kerberos S4U2self
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/02636893-7a1f-4357-af9a-b672e3e3de13
The S4U2self extension allows a service to obtain a service ticket to itself on behalf of a user. The user is identified to the KDC using the user's name and realm. Alternatively, the user might be identified based on the user's certificate. The Kerberos ticket-granting service (TGS) exchange request and response messages, KRB_TGS_REQ and KRB_TGS_REP, are used along with one of two new data structures. The new PA-FOR-USER data structure is used when the user is identified to the KDC by the user name and realm name.

Wayne's World of IT (WWoIT).