2

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?

Anand Patel
  • 6,031
  • 11
  • 48
  • 67
  • 1
    Possible duplicate of [What's the difference between a Primary Token and an Impersonation Token](http://stackoverflow.com/questions/35027524/whats-the-difference-between-a-primary-token-and-an-impersonation-token) – conio Mar 05 '16 at 19:12

1 Answers1

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.

arx
  • 16,686
  • 2
  • 44
  • 61
  • 2
    You're mixing up a lot of unrelated issues and writing stuff that is completely incorrect. Both today and 17 (or 20) years ago. Whether a principal wanting to authenticate to a service (as himself or otherwise) has to know a password is completely unrelated to the kinds of tokens. NTLM (in workgroup environments) requires knowing the password (or the "password-equivalent hash") while Kerberos (or the bizarre configuration of NTLM in a domain, using NTLM pass-through) does not. – conio Feb 20 '16 at 22:46
  • 2
    An impersonation token **does not** "represent[ing]s an authenticated user who is actually logged on to another computer". Tokens always represent **local** logon sessions. The `_TOKEN` struct have a `TokenId` field which is a `LUID` which stands for **locally** unique identifier. That should be a big enough hint. It also has a `LogonSession` field pointing to the corresponding `_SEP_LOGON_SESSION_REFERENCES` struct. All of this represents local logons. – conio Feb 20 '16 at 22:47
  • 1
    Every time you call `ImpersonateSelf()` you get an impersonation token attached to the current thread and there’s certainly no “authenticated user who is actually logged on to another computer”. Same goes for `ImpersonateAnonymousToken()` or `DuplicateToken()`. I could go on, but see the correct answer in my question [here](http://stackoverflow.com/a/35027525/306930). – conio Feb 20 '16 at 22:47