The following code has been tested on Windows 2003 SP2.  The calling user account must have 'Assign Primary Token' and 'Increase Quota' permissions to properly execute CreateProcessAsUser; see MS KB285879. 

          
            Public
            Function RunProc(ByVal CMD AsString, ByVal ARG AsString) AsStringDim er As Int16 Dim exitCode As System.UInt32 = Convert.ToUInt32(123) Dim saThreadAttributes As SECURITY_ATTRIBUTES =New SECURITY_ATTRIBUTES
saThreadAttributes.nLength = Marshal.SizeOf(saThreadAttributes) Dim impToken As System.IntPtr = IntPtr.Zero Dim priToken As System.IntPtr = IntPtr.Zero If LogonUser("DomainUser", "Domain", "Passwd",
LogonType.LOGON32_LOGON_INTERACTIVE, _ LogonProvider.LOGON32_PROVIDER_DEFAULT, impToken) ThenIf DuplicateTokenEx(impToken,
&H2000000, Nothing,
SecurityImpersonationLevel.SecurityDelegation, TOKEN_TYPE.TokenPrimary, priToken) ThenDim pi As PROCESS_INFORMATION =New PROCESS_INFORMATION Dim si As STARTUPINFO =New STARTUPINFO
si.cb = Marshal.SizeOf(si)
si.lpDesktop = IntPtr.Zero Dim saProcessAttributes As SECURITY_ATTRIBUTES =New SECURITY_ATTRIBUTES
saProcessAttributes.nLength = Marshal.SizeOf(saProcessAttributes) IfNot CreateProcessAsUser(priToken,
CMD, CMD & "
" & ARG, saProcessAttributes, _ saThreadAttributes, False,
0, IntPtr.Zero, "c:\",
si, pi) Then er = Marshal.GetLastWin32Error
RunProc = ("err
runas " & er) Else WaitForSingleObject(pi.hProcess,
Infinite) GetExitCodeProcess(pi.hProcess, exitCode) EndIf CloseHandle(priToken)
CloseHandle(impToken) CloseHandle(pi.hProcess) CloseHandle(pi.hThread) EndIfEndIfEndFunction
        

Let's pretend that Joe Smith working for company A just got an offer from company B to steal company A's products database for one million dollars.  However company A already has aleady secured their system pretty tightly.  All external storage such as USB has been blocked, there are no floppies and Joe does not even have outside email access.  Joe, however, does have CIFS access to the precious database.  So he decides to bring a laptop from home, plugs into the network and obtains an IP from the DHCP server.  He attempts to join Company A domain but is denied since he is not an administrator.  Joe decides to navigate to '\\FileServer\Databases'.  Windows prompts him for a username and password, so Joe types in 'CompanyA\JoeSmith' and his usual domain password.  Voila, he gained access to the Databases share and now is copying data from the file server onto his laptop; hands the data to company B and receives a million dollars.  Scary, isn't it?

Wouldn't it be much better if Joe brought his laptop, obtained and IP but when he tried to access the shared folder all he would receive was an Access Denied message?  Here is how:

First of all this setup works because the Windows machine itself is a security principal with an account name and password in Active Directory Services.

We need to create two IPSEC policies, one for the file server and the second one for all clients. 

File Server Setup:

IP Filter List will contain the following source ports:
TCP 137
TCP 139
TCP 445
UDP 137
UDP 139
The source IP address will be the file server's IP address and the destination subnet will be any client grouping you choose. 

The Filter Action will be a custom filter to negotiate security.  Inside the Custom Security Methods use MD5 to protect 'data and address integrity without encryption'.  Note: Enabling encryption will affect SMB/CIFS performance.

Client Setup:
The IP Filter List will contain the same source ports as the File Server setup did.  However the source address will be the File Server's IP address and the destination address will be My IP Address.
The Filter Action will be the same custom filter as in the setup above.

After applying the IPSEC policy through GPO, you can use the IPSEC Monitor MMC to view statistics and associations.  Sniffing the cable should produce ISAKMP protocol between the client and server.  Any existing CIFS connections will not survive IPSEC taking effect, so remember to do this overnight or force a client reboot.  Turning up event logging is also a good way to debug any failed key exchanges.

Another approach is individual share protection by using the 'NTLM Authenticator' user.