为什么 LogonUser(...) 不适用于域帐户?
我一直在尝试使用 LogonUser(...)
获取用户帐户的访问令牌,如 此 MSDN 示例。
// Call LogonUser to obtain a handle to an access token.
bool returnValue = LogonUser(userName, domainName, Console.ReadLine(),
LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT,
out safeTokenHandle);
当我运行示例(具有管理员权限)时,如果给定域 .
以及本地用户帐户名和密码,它可以正常工作,但无论我做什么,我都会收到错误代码 1326 (如果我尝试使用域帐户,则登录失败:未知的用户名或错误的密码)。如果我为域输入垃圾,我会得到相同的结果,这让我想知道它是否真的在联系 DC。
什么可能会阻止这个工作?
I've been trying to use LogonUser(...)
to get an access token for a user account, as in this MSDN sample.
// Call LogonUser to obtain a handle to an access token.
bool returnValue = LogonUser(userName, domainName, Console.ReadLine(),
LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT,
out safeTokenHandle);
When I run the sample (with Administrator privileges) it works fine when given a domain of .
and a local user account name and password, but no matter what I do I get error code 1326 (Logon failure: unknown user name or bad password) if I try to use a domain account. I get the same result if I enter garbage for the domain, which makes me wonder if it's actually contacting the DC at all.
What could be stopping this from working?
就我而言,问题与提问者类似,是我尝试验证的帐户位于我当前计算机不属于的域中。与原始海报不同,我的机器不应该也不可能成为另一个域的一部分。不过,我希望登录对该域上的资源执行操作。
答案如下,
并定义了以下常量:
希望这能帮助其他在类似情况下迷失的人。
编辑:如下面的评论中所述,此登录类型允许调用者克隆其当前令牌并为出站连接指定新凭据。新登录会话具有相同的本地标识符,但对其他网络连接使用不同的凭据。因此,即使密码错误,“成功”也会返回 true。除了“成功”之外,您还需要进行额外的检查,以确认凭据确实良好。
在我最初的用例中,这不是一个问题,因为我们在另一个函数中使用当前网络用户的凭据从安全存储中提取明文密码。因此,除非系统和活动目录之间存在不一致,否则它永远不会出错,在这种情况下我们会遇到更大的问题。
In my case the issue, similar to the question asker, was that the account I was trying to authenticate to was in a domain that my current machine did not belong to. Unlike the original poster, my machine should not and could not be part of this other domain. I wanted the login to perform action on a resource on this domain though.
The answer was the following
with the following constants defined:
Hopefully this will help others who are lost in a similar situation.
Edit: As mentioned in the comments below, this logon type allows the caller to clone its current token and specify new credentials for outbound connections. The new logon session has the same local identifier but uses different credentials for other network connections. As a result of that fact, "success" will return true even if the password is bad. You will need an additional check beyond "success" to confirm that the credentials are actually good.
This was not a concern in my initial use case as we used the current network user's credential in another function to pull the plaintext password from secure storage. So it would have never been wrong unless there was an inconsistency between that system and active directory in which case we had bigger problems.