SMB2 Quick Guide
The Server Message Block version 2 (SMB 2) protocol is used to:
- Access files on a remote file server
- Operations such as Open, Read, Write, Rename, Move, Close
- Communicate between processes by providing a named pipe
- Can be used to carry transaction protocols
In this module we will focus on remote file access, although we will see that interprocess communication does play a part in the control of access.
SMB 2 is a significant rewrite of the SMB protocol. There are new concepts, a new message format and a tidier set of messages. There are three dialects of SMB 2:
- SMB 2.002
- SMB 2.1 - used by Windows 7 and Windows Server 2008 r2
- SMB 3.0 - used by Windows 8
This course module is based on SMB 2.1 as this is the most prevalent dialect at the time of writing. The differences between 3.0 and 2.1 relate to extended functionality, and so anything learned here can be carried over.
Almost all strings are encoded as UTF-16 values, with UTF-8 being used occasionally, for example in relation to Kerberos authentication. For those of us who just have to deal with a Latin character set, UTF-16 is easy to read as it comprises the code for the equivalent ASCII character followed by a one byte value of 0x00, just like the example above.
The protocol stack associated with interactions with file servers is quite complex. The following diagram shows some of the elements of a client stack.
The corresponding portion of the server stack is very similar.
We will use these portions of the stack as a reference when we look at the typical interactions later. Some points to note:
- NBSS is the acronym for NetBIOS Session Service; the NetBIOS header format that carries SMB data
- NBNS is the acronym for NetBIOS Name Service; the NetBIOS header format that carries NetBIOS name resolution traffic
- NBDS is the acronym for NetBIOS Datagram Service; the NetBIOS header format that carries the Mailslot protocol which in turn carries Host Announcements
- Representing the protocol stacks in this way is quite difficult and there are certain simplifications in the diagrams above
- An application can access a remote file in just the same way as it does a local file; the file system handles the redirection via SMB
- Multiple sessions can be multiplexed on a single TCP connection
- Multiple tree (share) connections can be multiplexed onto a single session
- The SMB file service is primarily on TCP port 445, although it can use TCP Port 139
The Host Announcement protocol is not particularly important in the provision of the remote file service, but we've included it here because it provides a handy way to cross check the name and IP address of a server.
Above we see the Host Announcement for a server with a NetBIOS name of GUPPIE and the IP source address is 192.168.1.70. Note that the frequency of the announcement in this case is every 12 minutes, and so we may not see this announcement in a trace covering a shorter period.
The Wireshark filter expression to display these announcements is 'nbdgm' which displays all NetBIOS Datagrams.
Requests and Responses
Let's start by introducing some terminology and concepts. An SMB command is carried in an SMB Request Message, and the response to the command is carried in an SMB Response Message. These messages flow over SMB Session, which is specified by the triplet:
- TCP Connection
- SMB Session ID
Each request and response carries a Command Sequence Number (or MessageId as it is called in the SMB 2 standard).
We can match a response to its request as both carry the same Command Sequence Number. Other information that is useful in the reviewing a trace summary are:
- Tree ID - because it shows the share that is the subject of the SMB Command
- File ID - because it shows the file or directory that is the subject of the SMB Command
We will cover these issues in more detail in the following sections.
Basic SMB Commands
They say that verbs are the backbone of any language. Here we look at some of the basic verbs (commands) that make up the SMB 2 protocol, and along the way learn a bit more about the detail.
To access a file on a remote file server we must start by connecting to a share. In SMB, the share and all of the directories and files below it are referred to as a tree.
In the trace above we see the following (by frame
- 144 - 146: The TCP three-way handshake
- 147 - 150: NegotiateProtocol - Negotiating the SMB 2 dialect and options
- 164 - 166: SessionSetup - Creating an SMB Session between
client and server; includes authentication
- Note that the response includes a Session ID which is used from this point onwards for all operations on that session
- 171 - 172: TreeConnect - Connecting to the share
- Note that the response includes a Tree Id which is used for all operations by this client on this share
- 167 - 168: TreeConnect - Connecting to a special share (IPC$)
for interprocess communication
- Note the different Tree Id but same Session Id
- 175 - 176: Create - Opening a special file which is actually
a named pipe called srvsvc which is used to communicated with
SRVSVC.SYS (the file service management driver) on the server
- We will look at opening files next
Later in the trace we connect to another share just called 'd'.
Note that we are still using the same TCP connections and the same SMB session, but we see that the operation gives us another Tree Id - 0x0000000d.
Checking if a File Exists
SMB 2 has many facilities and we will cover the basics of open, read, write and close but here's an example of the other operations that are supported.
In the trace entry above we see a request to search for information relating to a file called desktop.ini. Note that this search is made against a Tree Id (for the share \\GUPPIE\C$) and a File Id. The File Id in this case is for a directory called 'Users' which Wireshark detected as being opened at frame 224.
File Open (Create)
The Create command is used to create and/or open files, directories and named pipes. Later in the trace the user opened a file GCandMemory-042005.pdf.
From the Wireshark decode of the Create Request we can see that:
- The File Name in the Create Request is referenced to the share (i.e. the file is Downloads\GCandMemory-042005.pdf)
- The Share Type field is shown as Physical disk (see notes below)
- The Disposition value shows that we are trying to open an existing file, and if the file doesn't exist the operation should fail
We need to take care when we use the Wireshark decodes. Obviously most of the data presented is as a result of parsing the packet content (or dissecting in Wireshark-speak). However, Wireshark tries to add further information taken from other packets. Most of these values are enclosed in square brackets. We see above that the Tree (share) that this operation applies to is \\GUPPIE\C$, and yet this value is not carried in the Create Request packet. However, the Tree Id is included in the packet and, because Wireshark has already decoded the Tree Connect that maps the name to the Tree Id, Wireshark adds the detail. This raises two important points:
- We won't get the additional information if the packets needed have not been captured; in this case if we hadn't captured the TreeConnect Wireshark would not have been able to give us the \\server\share details
- Wireshark occasionally makes mistakes and so we may need to manually check the values in the square brackets if we get an unexpected indication
Another Wireshark-generated value that is shown in the Create Request is the Share Type, which is taken from the TreeConnect Response packet. There are three types of share defined in SMB 2:
- SMB2_SHARE_TYPE_DISK - Physical disk share
- SMB2_SHARE_TYPE_PIPE - Named pipe share
- SMB2_SHARE_TYPE_PRINT - Printer share
It's also worth noting at this point that the names used in Wireshark for header values don't always coincide to the names used in the SMB 2 documentation. For example, the Command Sequence Number value shown in the Wireshark decode is referred to as MessageId in the SMB 2 documentation.
The Process ID value is a particular puzzle as the documentation states that this is a Reserved field and should be set to four bytes of zeros. This value is nearly always set to 0x0000feff, else it is indeed set to 0x00000000.
The Create Response includes values that are important in further analysis:
- A response code called NT_STATUS indicates if the operation was successful
- Create, Access, Write and Change timestamp information is included
- A File Id (in the form of a GUID) that is used as a handle in future file operations
This decode demonstrates an example of information added by Wireshark that is not enclosed in square brackets. The file name information (with the label 'GUID handle File:') is not actually carried in the Create Response; it only contains the File Id.
In the following trace detail we see that the format of the open for a named pipe is the same as that for a regular file.
If we look at the Wireshark decode of the Create Request for the srvsvc named pipe we see that:
- The File Name specified is the named pipe name
- The Share Type is Named Pipe which is carried in the TreeConnect Response for the connection to \\server\IPC$
The Read Request operation is very straightforward, and it uses the File Id to identify the file to be read.
To define the portion of the file we wish to read we specify the offset in the file and a length of data to read. That's it.
The above screenshot shows the Read Response. In the Read Request we specified a read length of 4,096 which must be split into four TCP segments. The maximum amount of data that can be transferred in a single Read or Write operation is negotiated through the NegotiateProtocol sequence; in this case it is 1,048,576 bytes (1 MB).
Note the way that Wireshark adds summary Info to the last packet in the sequence, and that a decode of this packet shows the SMB header information, even though this was carried in the first packet in the sequence.
As with a Read, the Write operation is relatively simple. The command references the file to write to using the File Id, and then specifies a write length, a file offset and the data to be written.
In this case the Write was as a result of saving a Word document 'Users\george\Documents\Definitive Diagnostic Data Analysis.docx'. Note that Word actually saves the file with a temporary name, in this case 'Users\george\Documents\4B88E0E4.tmp'.
Continuing with our scenario, after saving the Word file with a temporary name, Word reads both the original file and the temporary file. It's not clear why it does this but it could be to perform some type of comparison. Eventually we see two packets that rename files.
Using the File Id the original document is renamed to a temporary value. The temporary file that was created by the save operation is then renamed to the original file name.
The close command has few parameters. The file to be closed is
specified using the File Id.
In the example above we see Word closing the temporary file created in the Write section above.
The method to delete a file is perhaps a little unexpected. There is no Delete command in SMB 2 the way there is in SMB and CIFS (SMB_COM_DELETE).
In our Word document save scenario we got to the point where we had renamed files so that now we have a new version of the original file, but we are left with a temporary file (Users\george\Documents\55D24395.tmp) that is the renamed original which we must now delete. This is the sequence of packets:
The scenario shows that Word:
- Opens the temporary file with a Create command
- Sets the Disposition value of the file to Delete On Close
- Closes the file, thereby deleting it
We cover notification mechanisms elsewhere in this course, but it's worth noting that SMB 2 includes such a mechanism. It is based on a Notify Request that only completes when a notification event occurs; in this case a change to a directory or file.
The sequence of frames is:
- 799 - An open for the directory being monitored (dumps) and a
- Note this is a compound request which we will look at later
- 805 - Confirmation that the directory is open and that we now have a handle to it
- 807 - Confirmation of the Notify and a status indicating that the client should await notification (STATUS_PENDING)
- 1051 - An asynchronous notification that the dumps directory has changed
- 1087 - The client re-enumerates the dumps directory
In the detailed decode section, note the CompletionFilter values which specify in what circumstances the Notify Response should be sent. An additional point of note is that we can request a notification for changes throughout a whole tree structure.
The screenshot highlights something new to us; the SMB 2 header now contains an Async Id. This value is used to match up the async notification that follows later when the directory changes.
We need to consider this mechanism when using our flip-flop model to analyse response times, although if we are just measuring the delta between the Notify Request and the first Notify Response (STATUS_PENDING) we should not have a problem. Note that the Notify Request and the two Notify Responses all have the same Command Sequence Number of 5847. We also see that the async response seems to upset the Wireshark dissector as it thinks the SMB 2 message is malformed.
RPC Over SMB 2
In an earlier snippet of the trace there was an example of an RPC operation over SMB.
A single RPC operation results in four SMB operations in the following frames:
- 1458 - A DCERPC Bind call carried in an SMB 2 Write command to a named pipe
- 1459 - An SMB 2 Write response that indicates that the write was successful
- 1460 - An SMB 2 Read command to get the response to the Bind call
- 1461 - A DCERPC Bind_ack carried in an SMB2 Read response
The purpose of the Bind is to bind a local stub code to a remote server application. The Bind format looks just like a Bind transported over vanilla TCP. RPC calls look as expected too:
The Opnum defines the actual procedure being called, and in this case an Opnum of 16 made to the srvsvc service means NetShareGetInfo. Further details in the packet show that the share info being requested is for a share called 'd' on the server GUPPIE.
The SMB 2 protocol includes a Lock command, but it has a slightly different meaning to perhaps what might be assumed. The Lock command allows a client to lock a portion of a file by offset and length. To control the sharing of a file SMB 2 uses Share Access flags in the Create Request.
In the example above a temporary Word file is created and opened for exclusive read and write access i.e. Delete, Write and Read share access is disabled.
Client Cache Control
Windows has a caching mechanism to improve the performance of an application that is accessing a remote file. The problem is that if, for example, an application repeatedly reads a 16 byte value from a file, every read requires a trip across the network to the file server. To avoid this performance penalty the client PC caches the 16 bytes. What's more, the client might read 4,096 bytes from the server and use the cached data to satisfy a later File Read for, say, 4 bytes from within the 4,096 bytes.
The client can also keep data in its cache even if the application closes the file so that if the file is reopened later by the same application, the cached data is immediately available. The problem is that if another PC wants to read the same data, it can't be sure that the data on the file server is up-to-date. It may have been updated in the first client's cache and not written back to the file server. SMB 2.1 provides a mechanism to control caching that has two parts:
- Lease - a flag that can be set in a file Create Request (and is confirmed in the Response) to indicate that the client will cache file data
- Break - a three-way operation that forces the client to flush updated data to the file server and cancel the lease
Prior to SMB 2.1 there was a very similar mechanism called Opportunistic Locking and the term OPLOCK is still widely used even though this is no longer a correct description.
In the scenario above we see the following:
- 70 - The client opens the file, specifying that it is prepared to share access but requesting a Lease on the data in the file
- 71 - The server responds with STATUS_SUCCESS and grants the Lease
- 107 - At some time later, another client attempts to open the same file with a Create (not shown here) and the server sends an unsolicited Break to the first client to cancel the Lease
- 108 - The first client issues a Break command to cancel the Lease
- 109 - The server confirms that the Lease is now cancelled
The flags in the Create Request are interesting.
The values of note here are:
- Oplock - the field is used for the older OPLOCK mechanism and the later Lease; a value of 0xff means Lease
- Share Access - we see here that the client is prepared to share Write and Read access to the file
- Chain Element: RqLs - these values are specific to the Lease;
although not decoded this area contains a GUID
1dde8b00-f8a0-ffff-e40a-500200000000 that is used later to
identify the Lease to be broken
- Note that a GUID is encoded 'on-the-wire' using a series of byte swaps and so it looks muddled in the hex dump area
Read-Ahead and Write Behind
Windows 7 takes the caching mechanism a lot further. Rather than only cache data as it is read, the Cache Manager uses a predictive algorithm to preload data into the cache so that it is ready for later use. Later file operations complete more quickly since the data is available locally in memory. The Cache Manager may also delay the writing of data back to the server since an application may change a particular area of a file multiple times, and delaying the write avoids unproductive trips across the network. Similarly the Cache Manager may delay issuing a file Close to the file server in case a client application reopens the file.
Let's start by looking at a sequence where Read-Ahead is not being used.
In the screenshot above we see a Process Monitor trace with file operations relating to a PDF file. The initial file operations are performed by the application process (in this case PID 3784 which is executing AcroRd32.exe or supporting DLLs). The related network interactions are performed by the SMB 2 kernel driver running in the context of the System process (PID 4 - ntoskernel.exe plus DLLs and drivers). We can see that the activity matches what is seen in the matching network trace.
The timestamps don't match perfectly because:
- Wireshark maintains its own time and there are inherent inaccuracies (+/- 30 ms is not unusual)
- The timestamp on a TCP Send is the time that the Send is acknowledged
The number of TCP Receives sometimes don't match because an application will often issue an initial Receive for more data than can be accommodated in a single packet. Also, an application may issue a Receive that specifies a length to accommodate header information, and then issue another Receive for payload data. Therefore, application TCP Sends and Receives don't always match the pattern of TCP segments seen on-the-wire; the TCP/IP stack reshapes the data to match the application TCP Receives.
After AcroRd32.exe has read a certain amount of the file we see some additional reads for the same file but now being generated by the System process.
This is an example of Windows 7's read-ahead cache mechanism. We see the Windows Cache Manager reading large chunks of the PDF into the cache for later use (note the Reads associated with PID 4).
Later AcroRd32.exe closes the file which completes successfully. Later still AcroRd32.exe reopens the file and reads 8 bytes at an offset of zero.
Note that although we see network traffic associated with the Create operation, there is none for the 8-byte Read. This is confirmed by the matching network trace.
The important point here is that if we are using network tracing to analyse a performance problem that involves a Windows file server we need to consider that the network trace will not show all file operations. However, we can still focus on identifying response time problems in the traffic we can see.
When using SMB 1 over high bandwidth high latency network connections (often referred to as long fat pipes) the typical maximum transfer between consecutive Read or Write Requests would be 64KB. This led to repeated pauses in the data transfer. SMB 2 overcomes this issue with a mechanism called multi-credit requests that allows the client to send two or more consecutive requests on a session without intervening responses. This capability is sometimes referred to as pipelining.
In the example above we see several SMB Read Request commands later followed by their corresponding responses. On the face of it this would seem to prevent us from treating SMB 2 traffic in a flip-flop manner. However, the request-response pairs can be matched using the Command Sequence Number. We will see later that we can use this value as a sort criteria and thereby treat the traffic as we would any flip-flop mode traffic.
Compounded Requests and Responses
The SMB 2 protocol includes the ability to concatenate multiple requests or multiple responses before passing the whole message to the TCP layer for transport. Note that this is subtly different to the simpler explanation that SMB 2 can place multiple requests or responses in a single packet. The concatenated SMB messages may not fit into a single packet.
In the example above we have two SMB commands with associated data that we want to send compounded. The total length of the two is 2,400 bytes, but the maximum TCP payload that can be carried in the packet is 1,460 bytes. Therefore, the TCP layer segments the data into two packets, one with a TCP payload of 1,460 bytes and the other with a payload of 940 bytes. Note that this is not IP fragmentation in action. This is TCP splitting the data across two segments that are carried in two packets.
The compound function has more to offer. In an earlier example we saw the following compounded request:
The Notify Request has been sent by the client so that it receive notification of changes to the dumps directory. To do this the Notify Request must specify a File Id for the dumps directory, but we only get this in the Create Response. Therefore how could we have a Create Request to open a directory that is compounded with a Notify Request that uses the File Id for the directory? Compounding allows the output from one command to be passed (chained) as input parameters to the next command without any intervening client interaction.
In the case above, the File Id generated by the Create Request is passed to the Notify Request. This chaining of information is controlled by two factors
- If the Chained flag (the SMB2_FLAGS_RELATED_OPERATIONS in the SMB 2 specification) in a command it will potentially use the SessionId, TreeId, and FileId output by the previous command, AND
- The input value parameter SessionId, TreeId, and FileId must be all hex Fs
Both of these conditions must be true for the chaining of a value to occur. In the example above we see the the File Id is set to ffffffff-ffff-ffff-ffff-ffffffffffff, but the Session Id and Tree Id are not, and so only the File Id from the Create Request output will be passed to the Notify.
Multiple NetBIOS Messages
It's also possible for multiple NetBIOS messages to be carried in a single packet.
Above we see two NetBIOS Session Service messages in one packet with each carrying an SMB2 message.
A point worth noting is that the Wireshark NetBIOS subdissector can make a mistake. The trace entry above shows Wireshark's interpretation with the TCP Protocol option Allow subdissector to reassemble TCP streams switched off. If we switch this option on we get the following:
This isn't a big deal but it is worth noting.
DFS Namespace (DFS-N)
Distributed File System Namespace (DFS-N) provides an additional level of abstraction of the path to data. Let's consider the data for three different groups of people spread across a number of servers and shares in a domain called Advance7:
- \\server01\tech - contains data and tools used by the technical support teams
- \\server01\mktg - contains all of the data used by the marketing department
- \\server19\Finance - contains data used by the finance department
- \\server26\hr - contains personnel information used by Human Resources
The problem with this setup is that the staff must remember where the data is and if it is moved to another server they need to remember a new location. We could use drive mappings, but these can become convoluted.
An alternative is to use DFS Namespace support where we use a simple namespace that can span servers, for example:
- \\Advance7\Teams\Technical - which DFS-N links to \\server01\tech
- \\Advance7\Teams\Marketing - which DFS-N links to \\server01\mktg
- \\Advance7\Teams\Finance - which DFS-N links to \\server19\Finance
- \\Advance7\Teams\Human Resources - which DFS-N links to \\server26\hr
These new references, called DFS links, are used by applications, and the underlying DFS-N client working with a number of servers resolve the DFS link to a \\server\share (which is referred to as a DFS link target).
DFS-N is particularly useful when:
- Data may be periodically moved from one server to another
- Data is replicated across multiple servers that are local to users in differing geographic locations
- A high availability setup where data held on the primary server replicated to another that is used in the case of failover
By using a UNC with a DFS link an application can be isolated from complications of moving data or replicated data. The application just consistently refers to the DFS link. To achieve this we need a supporting DFS infrastructure that comprises:
- Domain Controller - holds details of the DFS namespaces and the DFS root target servers for each of these namespaces
- DFS Root Target Server - holds the relationship between a DFS link and one or more DFS link targets (file servers with shares)
- DFS Link Target Server - a file server that actually holds the data
A DFS link is resolved in the following way:
- The PC's DFS-N client sends a request (REQ_GET_DFS_REFERRAL)
to its Domain Controller requesting the name of the DFS Root
Target Server for a particular namespace
- The response (RSP_GET_DFS_REFERRAL) includes a list of DFS Root Target Servers ordered by Site Cost i.e. how far away are they from the client
- Once it has this information, the PC's DFS-N client sends a
request (REQ_GET_DFS_REFERRAL) to the DFS Root Target requesting
the name of DFS Target Link Servers that can provide the data
- The list of DFS Target Link Servers returned (in a RSP_GET_DFS_REFERRAL) is ordered by Site Cost
- The PC connects to the share on the target link server
Note that there is only a single request-response pair of messages for all DFS name resolution activity; REQ_GET_DFS_REFERRAL and RSP_GET_DFS_REFERRAL. The meaning is altered by flags and string values contained in each message.
The above sequence is typical but there can be variations. For full details see 126.96.36.199 User/Application Initiated I/O Operation on a UNC Path in the [MS-DFSC].pdf document which includes a flow diagram defining DFS name resolution. Also see 4 Protocol Examples which shows and explains the various referral requests and responses.
DFS Replication (DFS-R)
DFS Replication (DFS-R) is a service (DfsrS.exe) that can be used to replicate user and application data between servers - in fact it's used by default to replicate SYSVOL data between DC servers. It uses an RPC protocol but unfortunately the payload is encrypted. Mechanisms like Share Access control and Leasing don't work across DFS-R replicated file systems. This means that two users could simultaneously update the same file. DFS-R resolves this issue by replicating the version of the file with the latest save timestamp to all servers and saving the other updated file in a ConflictandDeleted folder.
For the purposes of network trace analysis, the important point to note is that DFS-R is a totally different mechanism to DFS-N and uses a different protocol:
- DFS-N - IOCTL messages carried in SMB
- DFS-R - Replication data carried in encrypted RPC messages
Two other related protocols that we should mention are:
- DFS-N Management - a protocol to allow a client to manage the DFS namespace configuration
- DFS-R Helper - a protocol to allow a client to manage the DFS replication configuration
When a user accesses data on a file server it must pass the user identification information to that server, and in SMB this is done during the SessionConnect sequence. If a file server is to allow a user to access its data it must be sure that the user is who he or she claims to be. Similarly, a user needs to be certain that the server that it is to connect to is the server it claims to be. These certainties are achieved through authentication.
In a Windows Active Directory environment authentication is based on the Kerberos mechanism defined in RFC 4120. However, Microsoft adds extensions to the plain Kerberos mechanism to handle:
- Authorisation information such as group membership
- Interactive logon information
- Integrity levels
These extensions are defined in a document called Kerberos Protocol Extension ( [MS-KILE].pdf ). An alternative authentication mechanism is available to enable access to services that are not integrated into an AD nevironment. This mechanism is called NT LAN Manager (NTLM) Protocol which is defined in the document [MS-NLMP].pdf
Before we look at the authentication mechanism we need to introduce some terms contained in the Kerberos and extension documents:
- Key - A sequence of bytes that can be used by a cryptographic
algorithm to encrypt or decrypt data
- Symmetric Key is a one key that can be used to both encrypt and decrypt data
- Asymmetric Keys is a pair of keys (sometimes referred to as public/private) one of which is used for encrypting data and the other decrypting it
- Key Distribution Center (KDC) - A service that authenticates
a client and grants tickets to it so that it can safely access
other network services
- In a Microsoft AD environment the KDC function is integrated into the Domain Controller
- Security principal - A unique individual or server that is known to the KDC, and for which there is an associated cryptographic key
- Security principal name (SPN) - The name that identifies the security principal in the form username@domainname or machinename$@domainname
- Ticket-granting Service (TGS) - A service that grants tickets for access to other services
- Ticket-granting Ticket (TGT) - A special ticket that is needed to access the TGS
- Ticket - A ticket for any service other than a TGS; in the context of this course module ticket could be used by a file server to authenticate a connection request
- Token - An encrypted message that is carried in an application protocol and passed to the authentication mechanism at the server for checking
Based on the diagram above, the interactions are as follows:
- The client encrypts the user credentials (name and password) into an AS-REQ message and sends it the the (KDC) to obtain a TGT
- The KDC checks the user's credentials and then returns a TGT
- The client sends the TGT and details of the server it wishes to connect to in a TGS_REQ to the KDC
- The KDC returns a service ticket via a TGS_RSP message that enables the client to create a session with the target server
- The client sends the service ticket obtained to the target server imbedded in the GSS section of the Session Setup Request
- The server validates the ticket and then responds via the GSS section of the Session Setup Response
The above trace shows the authentication mechanism in action as a PC accesses a file server. The scenario is as follows:
- At some time prior to this trace the client sent an AS_REQ packet that contained an authenticator (encrypted userid and password) to the KDC to obtain a Ticket-granting Ticket (TGT) that would allow it to request tickets from the TGS
- The KDC must have responded with a suitable TGT
- 484 - 490: The client and server negotiate the protocol
dialect to be used, including the authentication method
- The server uses a Simple Protected Negotiation (SPNEGO) extension to the Negotiate Protocol Response to offer five different authentication mechanisms including Microsoft variant of Kerberos (MS KRB5)
- 497: The client sends a TGS_REQ with the TGT, the authenticator and the Security Principle Name (SPN) of the file server to the TGS component of the KDC to request a ticket to be used to connect to the file server
- 499 - 500: The TGS returns a suitable ticket and a session key that the client can use to encrypt communication with the file server
- 503 - 507: The client requests a Session with the server with the ticket imbedded in the request, and the server accepts the request, returning STATUS_SUCCESS
We can see from the above decode of the SessionSetup Request that the AP_REQ is carried in its header.
Flexible Authentication Secure Tunneling (FAST) provides a protected channel between the client and the Key Distribution Center (KDC). FAST is only available for Authentication Service (AS) and ticket-granting service (TGS) exchanges.
FAST armor uses a ticket-granting ticket (TGT) for the computer to protect Authentication Service (AS) exchanges with the KDC, so the computer’s AS exchange is not armored. The user’s TGT is used to protect its TGS exchanges with the KDC.
Authorisation and Impersonation
Authorisation to access directories and files on a file server is controlled by two mechanisms:
- Private Attribute Certificate (PAC) - the KILE extension enables a Kerberos Ticket to contain additional information such as the user SID and group SIDs
- The thread that runs on the server to service the SMB 2 file
operation impersonates the client user
- The thread runs in the client user's context with the user's access token obtained from the PAC data
The combination of the user's SID and group SIDs, and the ability for the service thread to run in the user's security context, enables the server to handle file operations as though the user were logged on to the server.
We can investigate the impersonation functionality using Microsoft Process Monitor. The following trace entry was taken from a Windows 2008 r2 server; we see the Event information and the Stack. The user Advance7\fredb uses a Windows 7 PC to access a share on the server. The share is called Test and it maps to c:\test.
Notice how the Event information shows that this thread is impersonating Advance7\fredb and how the Stack shows that the thread has been executing code in srv2.sys.