The ICPServ and ICPclnt sample demonstrates how to go about writing a client and server application that uses the P&M Membership Authentication Service along with the user names and passwords stored in a corresponding Membership Directory Service for authentication and authorization of users. The client and the server both use the Security Support Provider Interfaces (SSPI) to undergo a security handshakewhereby the server notifies the client that credentials are required for a particular resource, and the client responds by attempting to collect the credentials and send them to the server. The example demonstrates the use of two of the Security Support Provider (SSP) packages that can be used with the Membership Authentication Service: the Distributed Password Authentication package (DPA) and the clear text/basic package (MBS_BASIC). All security communication exchanges between the client and server are through standard TCP/IP sockets.
The source for the client and server can be found in the directory <sdk install root>\Samples\Site Server\Personalization & Membership\Security\ICPProject\. A complete Microsoft® Developer Studio® project and workspace are included with both the client and the server examples to make building and testing the samples easy. You can compile the samples on the command line using nmake, or through the DevStudio project’s Build option.
The server code contains a standard TCP/IP server process implementation for communication with the client. The server binds a socket using a predefined port value of 12700. It then idles, waiting for clients to connect. When a client connects, the client and server enter a standard SSPI handshake dialog, using either the DPA (default) or the Security Support Provider (SSP) specified on the command line. After the client has presented credentials, the server attempts to verify the credentials. If successful, the server can attempt to access the file specified by the client process, impersonating the client on the local machine. The local path to the file is specified as a command-line switch for the client executable program. After the attempt, the server returns a success or failure message to the client, and then closes the connection.
The Security Support Provider Interfaces (SSPI) functions needed are included in various DLLs with different names depending on the platform. For Microsoft® Windows NT®, the standard SSPI DLL is Security.dll.
For Microsoft® Windows® 95 machines, it is Secur32.dll.
The DPA implementations are located in the library msapssps.dll.
The msapssps.dll DLL exports the SSPI functions used by the server to make SSPI calls to the Membership Authentication Service instance. The necessary functions can be loaded and bound directly if the [-l] switch is used when starting the server, or implicitly through security.dll.
(You can use "Quick View" or the dumpbin.exe executable program that comes with Microsoft Developer Studio to examine the exported functions of these libraries if desired.)
If you are unfamiliar with SSPI and want more information, it is available in the Platform SDK under Windows Base Services under Security. Look for the section labeled Security SPI.
The server application takes the following command-line switches:
| Switch | Meaning |
| [-v] | Verbose output from the server. |
| [-s MemID] | Specifies the Membership Authentication Service instance to use for authentication of the client’s credentials. |
| [-?] | Show this message. |
| [-l] | Load msapssps.dll directly. |
| [-k SSPI-pkg-name] | Specifies the SSPI package to use. Currently DPA or Basic. |
Note that both “-“ and “/” work for specifying switches.
icpserv.exe /v /s 3 /k DPA
The client process initiates the communication with the server. The command-line switches for the sample client are as follows:
| Switch | Meaning |
| [-?] | Show the help message. |
| [-d milliseconds] | Delay after sending a message. |
| [-k SSPI-Package] | The SSPI package to use when authenticating with the server process. |
| [-h hostname] | The name of the host running the server process (required unless local). |
| [-n] | Don’t use encryption (optional). |
| [-u AccountName] | Specify a user name (optional). |
| [-p Password] | Specify a password (optional). |
| [-f filename] | The file name to access on the server machine (optional). |
| [-v ] | Verbose output. |
icpclnt.exe /v /f “c:\myfiles\test.doc” /h someserver /k DPAThe client process also defaults to the DPA SSP. If the client specifies the user name, password, and domain (for NTLM), then the corresponding login screen will not appear.
Here are a few SSPs you can try with the sample.
In this case, the Membership Authentication Service is not used to perform authentication. This example is listed to elucidate the various options available. In this case, the NTLM is used to authenticate the client, and it requires the client executing the client process to have a valid Windows NT domain account.
Server: icpserv.exe /k NTLM /v
Client: icpclnt.exe /NTLM /v /f “c:\path to file”
The message returned to the client if the ACLs allow it to access the requested file on the server machine is “You have access to file: <file name>”
Server: icpserv.exe /v /s 3
Client: icpclnt.exe /f “c:\file” /v /h hostname /u username /p password
or
Server: icpserv.exe /v /s 3
Client: icpclnt.exe /f “c:\file” /v /h hostname
In the second example, the DPA login screen appears on the client machine requesting the user name and the password from the user. These must match a user name and password in the Membership Directory Service #3. The customui sample included with the SDK demonstrates how to customize this login screen, and could be used with this example.