~OT: Logging someone on

I confess that I am not currently working on an FSD. However, the thing
that has my semi-mystified would, seemingly, be an issue for network
FSDs, so I don’t feel guilty sending this along to see if someone has a
pointer or an answer.

The general question concerns the interactions of LogonUser,
AcquireCredentialsHandle, and perhaps ImpersonateLoggedOnUser.

From first principles, you might expect AcquireCredentialsHandle to take
a token handle to specify, precisely, on whose behalf the credentials
are supposed to be. However it does not. No Microsoft document I can
find specifies how the first argument to ACH is related to the various
possible argument (or values retrievable from a token) of LogonUser. Can
anyone shed light?

More specifically: when using Kerberos (and others), ACH takes in a
structure with a name, password, and domain. Now, since ACH is clearly
documented to just get a handle to credentials, and not to logon or
otherwise create new credentials, what does it do with that information?

Even more specifically, I’ve had a number of problems duplicating the
documented scheme for making MIT Kerberos and W2K interoperate. I won’t
bore the list here. However, if anyone knows a good target for specific
questions about these issues, I’d be grateful.

>documented to just get a handle to credentials, and not to logon or

otherwise create new credentials, what does it do with that information?

The client side of SSP either logs on using the username/password saved by LSA for this resource (as in case of “net use …
/user:xxx” with explicit password) or using the current NT’s username and password, or using username/password explicitly specified
by the caller.
The server side of SSP at least provides the user identity checked and “approved” by LSA. It can also give the ability of
impersonating the account specified by the client.

Kerberos and NTLM are just networking protocols using to pass the sensitive information over the network in a safe way.

Max