Windows 令牌有哪些不同类型以及它们有何不同？
最近我一直在处理Windows LogonUser API。 LogonUser api 根据传递给 API 的 dwLogonType 返回不同的令牌。该文件提到：
• 该函数返回模拟令牌，而不是主令牌。你 不能直接在 CreateProcessAsUser 函数中使用此令牌。 但是，您可以调用 DuplicateTokenEx 函数来转换 令牌转换为主令牌，然后在 CreateProcessAsUser 中使用它。
• 如果您将令牌转换为主令牌并将其用于 CreateProcessAsUser启动一个进程，新进程无法访问 其他网络资源，例如远程服务器或打印机，通过 重定向器。一个例外是，如果网络资源不可用 访问受控制，然后新进程将能够访问它。
我对不同的令牌类型完全感到困惑。我想了解什么是不同的 Windows 令牌类型以及它们有何不同？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
从历史上看（比如 17 年前）：
如果以用户 U 的身份在服务器 B 上运行的进程想要以同一用户的身份连接到服务器 C，则服务器之间的身份验证协议要求服务器 B 知道用户 U 的密码。
如果用户 U 登录到服务器 B，则这不是问题（用户必须输入密码）。
然而，假设用户 U 实际上在客户端 A 上登录并连接到服务器 B（可能是邮件服务器）。然后服务器 B 可以安全地确定它确实是用户 U 在连接，但服务器 B 永远不会看到 U 的密码，因此它无法代表 U 连接到服务器 C。
这种区别自然会产生两种用户令牌：
回到今天，事情变得更加复杂，因为例如 Kerberos 身份验证支持跨多个服务器的委派，但除非您明确启用此功能，否则上述相同限制仍然适用。
回到您的问题，您提到的限制仅在您请求
LOGON32_LOGON_NETWORK令牌时才适用。正如文档所说，这是对不需要访问其他网络资源的网络服务器的快速登录；如果您确实需要此访问权限，请选择其他登录类型。为了进一步阅读，本文已过时，但确实涵盖了各种模拟和委托选项。
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:
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_NETWORKtoken. 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.