poyaqua.blogg.se - Wireshark capture samples

#Wireshark capture samples windows

Yes, I like naming things after myself and it is duly noted that it is somewhat redundant in this case.

Note, the domain in question is called RCBJ (its DNS name is ) the domain user we are tracing the sign in of is called rcbj.

#Wireshark capture samples windows

The following screenshot shows the initial TCP connection between the domain-joined Windows server and the domain controller when the user “RCBJ\rcbj” tried to login via RDP. We will see one authenticator in this request: the authenticator sent with the TGT-REQ message. A server that encounters a replayed authenticator must reject the message. session sub-key (used in negotiations for a session key unique to this particular session)Īuthenticators must not be re-used.initial sequence number KRB_SAFE or KRB_PRIV messages).Structure of a Kerberos AuthenticatorĪ Kerberos Authenticator contains the following information (all encrypted): We will see two tickets in this example: Ticket Granting Ticket (TGT) and Service Ticket. *The following flags can be used in a ticket: Authorization-data - used to pass authorization data from the principal on whose behalf a ticket was issued to the application service ( see Section 5.3 of RFC4120 for more information).Timestamp and other meta data about last initial request.List of Kerberos realms that took part in authenticating the user to whom this ticket was issued.A Windows Server was joined to the new domain per instructions provided here.Ī Kerberos Ticket includes the following information: Unencrypted Part:.DNS for internal domain was setup per instructions provided here.Domain Controller was configured per instructions provided here.All traffic was generated in a test environment that will no longer exist by the time this post is published. No effort was made to obfuscate any of the information in these screenshots.

The network traces captured for this post were generated with Windows Server 2016 running on AWS.

If you are having trouble following, please see this post.

Likewise, I skip most of the introductory material in this post and jump straight to what is needed in order to understand the network traces.

See this post for more information about the processing done by each Kerberos actor.

I skip most of the details of what each actor is doing and instead focus on the messages exchanged by the protocol here.

See this for a detailed description of Windows user login. Here we are only interested in the pure-Kerberos details. Some of it involves proprietary details beyond the scope of the Kerberos 5 protocol that we do not care about in this post.

There is a lot going on with Kerberos in a Windows Domains.

AssumptionsĪs always, we’ll start with a bunch of assumptions to make sure we are in the same chapter (mostly given up trying to be on the same page). The traces were captured on the Windows Domain Controller that handled the Kerberos requests. In this post, we will be using Wireshark v2.6.0. Of course, many of the other identity protocols are built on top of HTTP(S) and tools like Chrome Developer Tools or similar can be used in the browser. This makes it easier to capture network traces (with Wireshark or similar tools) of Kerberos than some of the other identity protocols. Luckily, the Kerberos protocol is mostly unencrypted (except for the tickets, authenticators, and some other sensative details) that rely upon message and field level encryption. If you are new to the Kerberos protocol, a good starting place would be my Kerberos and Windows Security: Kerberos v5 Protocol post.

This post will help solidify our understanding of the Kerberos v5 protocol with a real world example. It describes the Kerberos network traffic captured during the sign on of a domain user to a domain-joined Windows Server 2016 instance. This blog post is the next in my Kerberos and Windows Security series.