Authenticating Logins - Tracing Login Network Traffic
(Page 6 of 24 )
In this section, you’ll examine the login process in detail by observing the network traffic passing between the client, SQL Server, a name resolution server, and a domain controller.
However, before we look under the hood, let’s stop for a moment to run through the testing methodology used for this section. The tool used to record the network traffic was the full version of Network Monitor that ships with Microsoft’s Systems Management Server (SMS). If you have the SMS 2.0 disk, navigate to the NMEXT\I386 folder and run setup.exe.It can also be found on Windows 2000 Server (a good free sniffer is NGSSniff at http://www.nextgenss.com/products/ ngssniff.htm). You may think it odd to use network traces in a book on SQL Server, but it turns out that one of the common reasons for problems logging into SQL Server stems from the fact that, in many cases, Windows will validate the client’s identity before SQL Server even sees the login request. This process has to occur because the network libraries use a method for running code on a server called remote procedure call,or RPC.How RPC works is not relevant to this discussion, but what is important to understand is that Windows NT and 2000 requires authentication of the user’s identity before the operating system will allow the user to execute code on the server.
Furthermore, only by looking at the network traffic will you know what components have to be available in order for a client to find and then log into SQL Server. If you want your database server to support a web server, a multitiered application, or any other type of application, you have to know what components must be available on each segment of the network.
Finally, if you want to use any of the encryption methods I discuss in this book, you should also verify that they work.
NOTE Looking at the contents of the network packet is the best way to make sure that the data stream is safe. As a general rule, if you cannot read it, neither can anyone else.
Fortunately, Network Monitor 2.0 (usually called NetMon) does most of the work of turning obscure network packet content into human-readable format. There are other packet sniffers that will read the network traffic quite well, but Microsoft has done a good job of making NetMon a complete analyzer for the traffic found on Windows networks. The actual capture files and setup instructions used for this book can be found in the download file for this book at http://www.WinNetSecurity.com. You will also find instructions for loading the capture files into other network analyzers if you do not have NetMon.
The Test Network Figure 2-1 shows the configuration of the test network used for this section.
Figure 2-1. The test network for SQL Server 6.5
Each of the machines shown here is actually a virtual machine running on VMware’s GSX Server product (http://www.vmware.com) on a private, closed network. Here is a description of each server’s role in the testing environment:
- NT4DC is a Windows NT 4.0 Service Pack 6 domain controller for the NTTEST domain.
- W2KDNS is a Windows 2000 Service Pack 2 member server running Windows Internet Naming Service (WINS), Domain Name System (DNS), and Dynamic Host Configuration Protocol (DHCP). It is not a member of the domain.
- SS65 is a Windows NT 4.0 Service Pack 6 member server running SQL Server 6.5 with Service Pack 5a and the post–Service Pack 5a hotfix. It is a member of the NTTEST domain.
- W2KCLIENT is a Windows 2000 Professional Service Pack 2 client computer with the SQL Server 6.5 Service Pack 5a client tools installed. It is a member of the NTTEST domain. (Note that none of the following explanations would change if the client were running Windows NT Workstation, or even Windows 9 x, instead of Windows 2000 Professional.)
- MONITOR runs Windows 2000 Professional Service Pack 2 and acts as the monitoring station where NetMon runs. It is not a member of the NTTEST domain, and it has been specially configured to produce very little network traffic.
The main reason to put the WINS, DNS, and DHCP services on a computer other than the domain controller is that this configuration makes it easier to see the whole process. One of the assumptions made when deciding how to configure the test network was that TCP/IP would be the sole network protocol. Part of the login process involves finding the database server, and without WINS or DNS, your clients will be forced to use the IP address. If your network uses some other protocol, you will have to translate the references to WINS and DNS into whatever mechanisms your network uses to translate human-readable computer names into network addresses.
Now that you have had a brief introduction to the test network, you can look at the traffic generated when a user logs in using the TCP/IP network library.
 This is from SQL Server Security Distilled, second edition, by Morris Lewis (Apress, ISBN 1590592190). Check it out at your favorite bookstore today. Buy this book now. |
Next: Logins Using TCP/IP >>
More MS SQL Server Articles
More By Apress Publishing
/ 17 
