Question

Recently I have been dealing with windows LogonUser API. The LogonUser api returns different token depending on the dwLogonType passed to the API. The document mentions:

• The function returns an impersonation token, not a primary token. You
cannot use this token directly in the CreateProcessAsUser function.
However, you can call the DuplicateTokenEx function to convert the
token to a primary token, and then use it in CreateProcessAsUser.

• If you convert the token to a primary token and use it in
CreateProcessAsUser to start a process, the new process cannot access
other network resources, such as remote servers or printers, through
the redirector. An exception is that if the network resource is not
access controlled, then the new process will be able to access it.

I am totally confused on different token types. I want to understand on what are different windows token types and how they differ?

Answer 1

Historically speaking (like 17 years ago):

If a process running on server B as user U wants to connect to server C as the same user, then the authentication protocol between the servers requires that server B knows user U’s password.

If user U is logged on at server B, this isn’t a problem (the user must have entered a password).

However, suppose that user U is actually logged on at client A and is connecting to server B (which could be a mail server say). Then server B can securely determine that it really is user U connecting, but server B never sees U’s password so it cannot connect to server C on U’s behalf.

This distinction naturally creates two kinds of user tokens:

• A primary token representing a user who is “really” logged on and can connect to other network resources.
• An impersonation token representing an authenticated user who is actually logged on to another computer so the token cannot be used to access other network resources (because the OS doesn’t know the password, and that’s required by the inter-server authentication protocol).

Back in the present day, things are more complicated because, for example, Kerberos authentication supports delegation across multiple servers, but unless you explicitly enable this the same restrictions outlined above still apply.

Going back to your question, the restrictions you mention apply only if you ask for a LOGON32_LOGON_NETWORK token. As the documentation says, this is a fast logon for network servers that don’t need to access other network resources; if you do need this access, choose a different logon type.

For further reading, this article is out of date but does cover the various impersonation and delegation options.