📄 readme.htm
字号:
<html>
<head>
<title>SSPI Workbench Docs</title>
</head>
<body>
<h1>SSPI Workbench</h1>
A free utility developed by <a href="http://www.develop.com/kbrown">Keith Brown</a>.
<p>
<img src="sspibench.gif"></img>
<table width=65%><tr><td>
<h2>Motivation</h2>
This tool was designed to assist readers of <a href="http://msdn.microsoft.com/msdnmag">MSDN Magazine</a>, the book <a href="http://www.develop.com/books/pws">Programming Windows Security</a>,
and attendees of the <a href="http://www.develop.com/courses/ents.htm">short course on security</a> that I wrote at DevelopMentor
(and anybody else who is interested in Windows security) in the understanding of network
authentication protocols and SSPI (the Security Support Provider Interface).
<h2>What is it?</h2>
It's a fancy user interface that acts as a state machine over SSPI. You run two copies
of the program (they can be on the same machine or different machines; no matter) that
communicate with each other via sockets. One copy acts as the server, the other acts
as the client. I've exposed some of the most interesting (IMHO) aspects of SSPI via the
user interface so that you can choose an SSP (i.e., Kerberos, NTLM, SPNEGO), choose
the credentials you want your SSP to use in representing you, and run an authentication
handshake. After the handshake, you can use the resulting session key (which is abstracted
by an SSPI context handle) to send encrypted/signed messages back and forth.
<p>
Let me emphasize that you must run <b><i>two copies</i></b> of the workbench (client and server) -
the workbench will ask you up front what role you want that particular copy of the workbench to play.
<h2>Getting Started</h2>
The best way to learn how the workbench works is to try using it.
<ol>
<li>If you haven't already, download and register (via regsvr32) the
<a href="http://www.develop.com/kbrown/security/samples.htm">token dump COM component</a> from my website.
<li>Run a copy of the workbench in the <b>server</b> role.
<li>Notice the title bar indicates that this is the server.
<li>Select NTLM.
<li>Select a set of server credentials (you can just use the default if you like).
<li>Choose a port (the default, 4242, will probably work fine).
<li>Press <b>Receive</b> to start listening.
<li>Run another copy of the workbench (on the same machine), this time in the <b>client</b> role.
<li>Notice the title bar indicates that this is the client.
<li>Select NTLM.
<li>Select a set of client credentials (you can just use the default if you like).
<li>Set the server principal name to an empty string (NTLM doesn't use this).
<li>Make sure all of the options (mutual authn, etc.) are unchecked (NTLM doesn't support
any of these options).
<li>Press Initialize to have the client SSP create the Negotiate message.
<li>Specify the server's host address (since the server is on the same machine, use the local loopback address of 127.0.0.1).
<li>Specify the server's port (you probably used the default of 4242).
<li>Press Transmit to send the message to the server.
<li>Switch over to the server - if the message was sent successfully you should
see something in the output window.
<li>Press <b>Accept</b> to process the NTLM Negotiate message and produce the Challenge message.
<li>Transmit this back to the client.
<li>Switch back to the client and press <b>Receive</b> to receive the Challenge message via sockets.
<li>Press <b>Initialize</b> to give the Challenge message to your SSP and it will produce the Authenticate message (the response).
<li>Transmit the response back to the server.
<li>Notice (in the client workbench) that the Compose button is now lit. <b>Don't use it yet</b>, but just notice this.
This indicates to you that your SSP has finished the authentication handshake for the client, and now has a session key
that you can use to secure the channel.
<li>Switch back to the server and press <b>Receive</b> to receive the Authenticate message.
<li>Press <b>Accept</b> to process the NTLM Authenticate message and establish a network logon session for the client.
<li>Note how the <b>Impersonate</b> button lights up indicating that the server-side SSP has successfully authenticated the client.
<li>Press <b>Impersonate</b> to impersonate the client's newly established security context and dump her token
to a temporary HTML file (the workbench tries to launch your browser to view this file; if all goes well, you should
see a browser pop up at this point).
<li>Press <b>Compose</b> to compose a message to send back to the client. Notice that the
output window now becomes an input window.
<li>Type a short message into the input window and press <b>Encrypt</b>.
<li>Press Transmit to send this message to the client.
<li>Switch back to the client workbench and press <b>Receive</b> to get the encrypted message.
<li>Press <b>Decrypt</b> to decrypt it.
</ol>
<h2>Tips</h2>
<ul>
<li>Kerberos requires the client to specify a server principal name (how else would the
client SSP know how to get a ticket for the server?)
</ul>
<h2>Caveats</h2>
<ul>
<li>The workbench is designed to talk to one and only one other workbench (so don't try
having multiple clients talking to one server, or vice versa).
<li>Once you've authenticated, you can send messages from the client to the server
or vice versa, but the workbench is only designed to deal with one message at a time
going in either direction, so don't try to simultaneously send a message from the client
to the server and from the server to the client. Keep it simple folks - this tool was
designed to show you how SSPI and authentication packages work, not how to build non-trivial
messaging systems ;-)
<li>I've only tested the workbench with Kerberos, NTLM, and SPNEGO. The workbench is
specifically <b>not</b> designed to work with SSL, in which SSPI is used in a very
different way. I plan on writing a similar tool that will specifically work with SSL
when I get some spare cycles.
</ul>
<h2>Selected Exercises</h2>
Use the workbench to help you answer these questions.
<ul>
<li>Draw the NTLM handshake between the client and server. How many legs are there?
<li>Draw the Kerberos handshake between the client and server both with and without
mutual authentication. How many legs are there?
<li>Using Kerberos, try changing the clock on the server's machine by a delta of 15 minutes.
Does authentication succeed? If so, how many legs are there? Chapter 7 of <a href="http://www.develop.com/books/pws">Programming
Windows Security</a> explains this interesting case.
<li>Again using Kerberos, try changing the clock on the server's machine by a delta of one day.
What happens now? Why?
<li>Use the negotiate package (both client and server must choose to negotiate). Specify
<tt><b>Kerberos,NTLM</b></tt> as the comma-delimited package list for both client and server.
What happens?
<li>After doing the previous exercise, specify only <tt><b>NTLM</b></tt> for the server's package list
(leave the client setting the same as before). What happens? Draw the handshake and identify
what's happening in each leg.
<li>Use the workbench with Kerberos and NTLM while running a network packet sniffer, and
draw the handshake including the packets sent to the authority (domain controller).
<li>Use the workbench with Kerberos in conjunction with the <a href="http://www.develop.com/kbrown/security/samples.htm">Ticket Viewer</a>
and try to figure out when new tickets are acquired (tip: use the ticket viewer to purge
the client's ticket cache first).
</ul>
<h2>Comments? Bugs?</h2>
Send mail to <a href="mailto:kbrown@develop.com?subject=SSPI Workbench bugs and comments">kbrown@develop.com</a>.
I don't have time to respond to all requests, but I do read them all.
</table>
</body>
</html>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -