Introduction

Hi! My name is Richard Sasser, or Rick, as I prefer, and I’m a Microsoft Certified Master for Active Directory and I work on the Platforms DSE team. I do a lot of security related work, and consult frequently on Public Key Infrastructures and Authentication issues. I don’t blog as often as I should, but I’m trying to correct that – Shameless plugs here:

http://blogs.technet.com/b/rsasser/archive/2012/11/21/create-virtual-machines-quickly-using-mdghost-part-1.aspx

http://blogs.technet.com/b/askpfeplat/archive/2013/04/22/choosing-a-hash-and-encryption-algorithm-for-a-new-pki.aspx

Before you read this blog, you should be familiar with the contents of Ned Pyle’s blog here:

http://blogs.technet.com/b/askds/archive/2009/04/15/the-lastlogontimestamp-attribute-what-it-was-designed-for-and-how-it-works.aspx

Issue

I ran across an interesting scenario with LastLogonTimeStamp and in my research, I turned up many cases in our database, and I thought I would dig in.

Essentially, there is a situation where LastLogonTimeStamp can be updated even if the user has not logged on.

This is an artifact of a Kerberos Operation known as Service-for-User-to-Self or,S4u2Self,” in which a client/service can request a ticket for a user that is only useful for things like determining Access Checks or Group Membership. This can cause confusion about the relative staleness of an account, in addition to other security concerns. Wouldn’t it be nice if you could discover the source of the request so you could address your security concerns and possibly remediate updating stale accounts?

Technical Details

S4u2Self is documented here:

http://msdn.microsoft.com/en-us/magazine/cc188757.aspx#S2

S4U2Self

The S4U solution in this case is for the server to go through the motions of Kerberos authentication and obtain a logon for the client, but without providing the client's credentials. Thus, you're not really authenticating the client in this case, only making the rounds to collect the group security identifiers (SIDs) for the client. To allow this to occur, Windows Server 2003 domain controllers accept a new type of Kerberos request, where the service requests a ticket from the client to itself, presenting its own credentials instead of the client's. This extension is called Service-for-User-to-Self (S4U2Self).

If the client and the service are in separate domains, this requires a bidirectional trust path between them because the service, acting on the client's behalf, must request tickets from the client's domain.

While the wire-level details are all rather complicated, the service developer need only call one function to start the ball rolling: LsaLogonUser. In spirit, this is similar to calling LogonUser as I have shown earlier, but without needing to provide the client's password. The result is a token that the service can use with functions like AccessCheck and CheckTokenMembership, as well as the new AuthZ family of authorization functions. This allows the service to perform access checks against security descriptors for objects that it manages.

To protect the client, LsaLogonUser normally returns a token with a special restriction. The token will have an impersonation level of Identify, which means that the service will not be able to open kernel objects while impersonating the client using this token. However, for services that are part of the trusted computing base (TCB)—for example, a service running as SYSTEM—LsaLogonUser will return a token with an impersonation level of Impersonate, allowing access to local kernel objects using the client's identity. This prevents an untrusted service from using an S4U2Self ticket to elevate its own local privileges.

You can test this by logging into a file server and performing an effective access check on a file. For example, right click a folder, select properties, select security, select Advanced and go to the effective access tab.

I’m going to focus on the “AccessCheck” function mentioned above - more information about it can be found here:

http://technet.microsoft.com/en-us/library/cc772184.aspx

This generates the appropriate S4U2Self conversation. This exchange is documented here:

http://msdn.microsoft.com/en-us/library/hh554517.aspx

1.     Perform a Kerberos S4U2Self service ticket request using the S4U2self KRB_TGS_REQ/KRB_TGS_REP protocol extension as specified in [MS-SFU] section 3.1.5.1.1.1.

The userName MUST be set to the user name obtained in step 2.

The userRealm MUST be set to the domain name of the obtained in step 2.

The chksum MUST be set as specified in [MS-SFU] section 2.2.2.

The auth-package MUST be set to "Kerberos".

http://msdn.microsoft.com/en-us/library/cc246102.aspx

Using the TGT to the TGS in the user's realm, Service 1 requests a service ticket to itself. The S4U2self information in the KRB_TGS_REQ consists of: padata-type = PA-FOR-USER (ID 129), which consists of four fields: userName, userRealm, cksum, and auth-package. Service 1 sets these fields as follows: The userName is a structure consisting of a name type and a sequence of a name string (as specified in [RFC4120] section 6.2). The name type and name string fields are set to indicate the name of the user. The default name-type is NT_UNKNOWN. The userRealm is the realm of the user account. If the user 's realm name is unknown, Service 1 SHOULD use its own realm name. The auth-package field MUST be set to the string, "Kerberos". The auth-package field is not case-sensitive.

Let’s look at an illustration of this in action.

SCENARIO - I logged in to a machine as myself and then used the “Effective permissions” tab in Windows Explorer to generate an effective access token for a user named “Vic” for a file on the server.

While I’m doing that, I have a network trace running on the client.

· The pertinent details are visible via the following NetMon filter

“Kerberosv5.TgsReq.KdcReq.PaData.PaData.PaData.PaDataType.AsnInt==129”

· UserName – vic…

· Realm = RS…

image

And can be located in a trace with the following filter:

Kerberosv5.TgsReq.KdcReq.PaData.PaData.PaData.PaDataType.AsnInt==129

Tracking down the source of the S4u2Self Request:

Now that I am armed with the appropriate knowledge, it is time to start tracking this stuff down:

The first place to start is with the account’s metadata, so we can understand where last logon timestamp was updated. So let’s take my lab for an example where I’m going to pick on Vic’s account because he has not logged into my server in a while:

Repadmin /showobjmeta <DCNAME> <ObjectDN>

repadmin /showobjmeta localhost "CN=Vic,OU=Administrator Accounts,DC=ad,DC=r,DC=net”

This is Vic’s User account. One of the many ways we can see that Vic hasn’t logged in to my server in a long, long time is that the DSA for this AD Environment has been deleted. Also, attributes are showing a last update of 1/2012. (I have omitted much of the attributes for brevity’s sake). Note that LastLogonTimeStamp for Vic is old as well.

Loc.USN Originating DSA Org.USN Org.Time/Date Ver Attribute

======= =============== ========= ============= === =========

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746445 2012-01-18 17:20:34 3 unicodePwd

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746445 2012-01-18 17:20:34 3 ntPwdHistory

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746445 2012-01-18 17:20:34 4 pwdLastSet

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746362 2012-01-18 16:57:43 1 primaryGroupID

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746361 2012-01-18 16:57:43 1 objectSid

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746455 2012-01-18 17:32:49 1 adminCount

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746362 2012-01-18 16:57:43 1 accountExpires

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746445 2012-01-18 17:20:34 3 lmPwdHistory

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746361 2012-01-18 16:57:43 1 sAMAccountName

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746361 2012-01-18 16:57:43 1 sAMAccountType

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746361 2012-01-18 16:57:43 1 userPrincipalName

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746361 2012-01-18 16:57:43 1 objectCategory

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746444 2012-01-18 17:20:34 1 lastLogonTimestamp

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746450 2012-01-18 17:20:36 5 msDS-LastSuccessfulInteractiveLogonTime

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746444 2012-01-18 17:20:34 1 msDS-FailedInteractiveLogonCountAtLastSuccessfulLogon

I subsequently logged in to a machine as myself (R*) and then used Explorer to generate an effective access token for Vic for a file on that server.

http://technet.microsoft.com/en-us/library/cc772184.aspx

Now Note Vic’s last logon timestamp in the metadata:

Loc.USN Originating DSA Org.USN Org.Time/Date Ver Attribute

======= =============== ========= ============= === =========

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746445 2012-01-18 17:20:34 3 unicodePwd

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746445 2012-01-18 17:20:34 3 ntPwdHistory

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746445 2012-01-18 17:20:34 4 pwdLastSet

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746362 2012-01-18 16:57:43 1 primaryGroupID

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746446 2012-01-18 17:20:34 2 supplementalCredentials

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746361 2012-01-18 16:57:43 1 objectSid

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746455 2012-01-18 17:32:49 1 adminCount

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746362 2012-01-18 16:57:43 1 accountExpires

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746445 2012-01-18 17:20:34 3 lmPwdHistory

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746361 2012-01-18 16:57:43 1 sAMAccountName

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746361 2012-01-18 16:57:43 1 sAMAccountType

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746361 2012-01-18 16:57:43 1 userPrincipalName

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746361 2012-01-18 16:57:43 1 objectCategory

82572 Default-First-Site-Name\TITAN 82572 2014-01-17 16:24:57 2 lastLogonTimestamp

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746450 2012-01-18 17:20:36 5 msDS-LastSuccessfulInteractiveLogonTime

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746444 2012-01-18 17:20:34 1 msDS-FailedInteractiveLogonCountAtLastSuccessfulLogon

· If you’re curious, here’s Vic’s lastLogonTimestamp prior to this access check:

12463 Default-First-Site-Name\SUPERMASSIVE\0ADEL:6439a528-0957-48e0-b37d-426bf9ee446b (deleted DSA) 13746444 2012-01-18 17:20:34 1 lastLogonTimestamp

From the metadata dump above, I can see on which DC the lastLogonTimestamp attribute change was made (“Titan”), so I can surf the security event log of Titan. Obviously, to catch these events I need the advanced audit policy enabled PRIOR to the events. You do have proper auditing enabled on your DCs, don’t you?

Account Logon:  Kerberos Service Ticket Operations      Success and Failure

http://technet.microsoft.com/en-us/library/dd772667(v=WS.10).aspx

Now there’s a bit of a rub here which I had to know - the audit event WILL NOT show the request for the user “Vic.” It will contain the account that made that made the request for the information (usually a service account), which is why I needed the trace. However, the event data can tell you if a particular application or user requested a ticket, and I can correlate the metadata update time with the event id time I’m looking for.

This event can then be correlated with Windows logon events by comparing the Logon GUID fields in each event. Also, important, the logon event occurs on the machine that was accessed, which is often a different machine than the domain controller which issued the service ticket.

Log Name: Security

Source: Microsoft-Windows-Security-Auditing

Date: 1/17/2014 4:24:57 PM

Event ID: 4769

Task Category: Kerberos Service Ticket Operations

Level: Information

Keywords: Audit Success

User: N/A

Computer: Titan.ad.r.net

Description:

A Kerberos service ticket was requested.

Account Information:

Account Name: r@AD.R.NET

Account Domain: AD.R.NET

Logon GUID: {f0886d68-26f2-d3c2-9d1f-1e790f212956}

Service Information:

Service Name: r

Service ID: R\r

Network Information:

Client Address: ::ffff:192.168.1.200

Client Port: 49502

Additional Information:

Ticket Options: 0x40810008

Ticket Encryption Type: 0x12

Failure Code: 0x0

Transited Services: -

This event is generated every time access is requested to a resource such as a computer or a Windows service. The service name indicates the resource to which access was requested.

The logon event occurs on the machine that was accessed, which is often a different machine than the domain controller which issued the service ticket.

Ticket options, encryption types, and failure codes are defined in RFC 4120.

The logon event referenced is logged on the machine used to generate the request and DOES contain the account that the S4U2Self extension was requested:

Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 1/21/2014 11:47:19 AM
Event ID: 4624
Task Category: Logon
Level: Information
Keywords: Audit Success
User: N/A
Computer: 2K8R2NPS.ad.rsasser.net
Description:
An account was successfully logged on.

Subject:
Security ID: S-1-5-21-3250969430-3741033745-72471029-1108
Account Name: r
Account Domain: R
Logon ID: 0x25B9B

Logon Type: 3

New Logon:
Security ID: S-1-5-21-3250969430-3741033745-72471029-1643
Account Name: vic
Account Domain: R
Logon ID: 0x6C395E
Logon GUID: {30ca5978-a4f4-d0c3-de5a-8a5e6b1f7bad}

Process Information:
Process ID: 0x654
Process Name: C:\Windows\explorer.exe

Network Information:
Workstation Name: 2K8R2NPS
Source Network Address: -
Source Port: -

Detailed Authentication Information:
Logon Process: Authz
Authentication Package: Kerberos
Transited Services: -
Package Name (NTLM only): -
Key Length: 0

This event is generated when a logon session is created. It is generated on the computer that was accessed.

The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).

The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.

The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The impersonation level field indicates the extent to which a process in the logon session can impersonate.

The authentication information fields provide detailed information about this specific logon request.
- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.
- Transited services indicate which intermediate services have participated in this logon request.
- Package name indicates which sub-protocol was used among the NTLM protocols.
- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

Summary

LastLogonTimeStamp might not always be updated by an actual Logon. S4u2Self requests for access checks can update the attribute. In order to track down the requests that are updating the account, you need to dump the metadata for the account, locate the DC that updated the attribute and parse the logs for the 4769 Kerberos Service Ticket Operation made at the same time. The machine making the request will log a 4624 Logon Event.