> On Win32, the client initiates authentication with the server by using a
> security support provider (Windows NT Lan Mananager Security Support Provider
> in this case) and calling AcquireCredentialsHandle(). The client then initates
> a series of calls to InitializeSecurityContext() passing and receiving buffers
> from the server. On the server side a similar call to
> AcquireCredentialsHandle() is followed by a series of calls to
> AcceptSecurityContext() recieiving and passing buffers to the client. The
> client never obtains a username or a password explicitly.
So that means that you have a network connection between two machines
(call them the client and the server), and the server is trying to
determine whether the client has access to some sort of account on the
This breaks down into two cases:
1) The account is a real system account, an entry in /etc/passwd, and
can own files on the server machine.
2) The account is virtual in some way and has meaning to user code in
the server but no special meaning to the operating system.
If you are dealing with case 1, take a look at other programs that need
to do the exact same thing. Things like 'login' and 'ftpd'. Alternately,
rig it so that the server code itself is invoked with that user's
privileges, for example using 'ssh' as a launcher. Your process can then
just call 'getuid()' to find out what user's privileges it has.
If you are dealing with case 2 (which should be more common), you can
do it any way that you want. You can exchange credential information
however you find most appropriate.