LogonUser 的开销?

发布于 2024-12-04 00:50:43 字数 747 浏览 1 评论 0原文

在阅读了大量有关用户身份验证的内容(无论是在 SO 领域还是在互联网上)之后,似乎相当明显的是,对用户进行身份验证的“最佳”方法(从而检测诸如过期密码等内容)是调用 Win32 LogonUser(),而不是尝试在 .NET 中使用 PrincipalContext.ValidateCredentials

然而,我并不完全清楚 LogonUser 实际做了什么 - 那么它会带来什么开销? MSDN 对此并不完全清楚 ,我最关心的部分就在最后,它说 LogonUser 调用 NPLoginNotify(),并且不完全清楚它的作用(除了准备登录脚本),也不完全清楚会发生什么到通话结果。

我最初担心 LogonUser 加载了用户的个人资料,但进一步阅读后,这个担忧就不再是问题了(除非我在这一点上错了,但据我所知,LogonUser 从未加载过配置文件 - 这会必须通过不同的函数调用显式加载)。

其背景是一个 Intranet Web 应用程序,需要能够针对 Active Directory 进行身份验证,因此应用程序将会有大量登录和注销:最初可能不会那么多,但将来可能会显着增加。看来,使用 LOGIN32_LOGIN_NETWORK 类型调用 LoginUser,然后立即丢弃它给我的令牌可能是最好的前进路线。

是否有任何我不知道的开销,或者我只是过度担心?

After doing a chunk of reading about authenticating users (both here in SO land and the internet generally), it seems fairly obvious that the "best" way to authenticate a user (and thus detect things like expired password, etc) is to call Win32 LogonUser(), rather than attempt to use PrincipalContext.ValidateCredentials in .NET.

However I'm not fully clear on though is what LogonUser actually does - and thus what overhead does it carry with it? The MSDN's not entirely clear on this, the part that mostly concerns me is right at the end which says that LogonUser calls NPLoginNotify(), and it's not entirely clear what this does (other than preparing logon scripts), nor what happens to the results of the call.

I was initially concerned that LogonUser loaded the user's profile, but some further reading has put that concern to bed as a non-issue (unless I'm wrong on this one, but from what I can tell LogonUser never loads the profile - this would have to be explicitly loaded through a different function call).

The context for this is an intranet webapp that requires the ability to authenticate against active directory, so there will be a number of logins and logouts to the app: probably not that many initially, but may ramp significantly in the future. It seems that calling LoginUser with a type of LOGIN32_LOGIN_NETWORK and then immediately discarding the token that it gives me may be the best route forward.

Is there any overhead I'm not aware of, or am I just worrying unduly?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

岁月静好 2024-12-11 00:50:43

MSDN 页面似乎很清楚:

LOGON32_LOGON_NETWORK 登录类型最快,但它有以下限制:

该函数返回模拟令牌,而不是主令牌。您不能直接在 CreateProcessAsUser 函数中使用此令牌。但是,您可以调用 DuplicateTokenEx 函数将令牌转换为主令牌,然后在 CreateProcessAsUser 中使用它。

如果将令牌转换为主令牌并在 CreateProcessAsUser 中使用它来启动进程,则新进程无法通过重定向器访问其他网络资源,例如远程服务器或打印机。一个例外是,如果网络资源不受访问控制,则新进程将能够访问它。

The MSDN page seems quite clear:

The LOGON32_LOGON_NETWORK logon type is fastest, but it has the following limitations:

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文