Cassini-dev的NTLM身份验证中的SecurityIdentifiers [英] SecurityIdentifiers in Cassini-dev's NTLM authentication

问题描述

在在卡西尼 - Dev的NTLM身份验证类的代码，以找到Secur32.dll的调用该块（通过互操作）由HTTP请求的授权头。这是有道理的，当两个 AcceptSecurityContext（）和 QuerySecurityContextToken（）返回 0 ，客户端已被授权。最后，安全上下文令牌有一个的SecurityIdentifier 从它（ _sid 变量）提取。 （约常见的安全ID的位）

In this block of code in Cassini-dev's NTLM authentication class, calls made to SECUR32.DLL (via Interop) are made to authenticate the base64 encoded data in an HTTP request's Authorization headers. This makes sense, when both AcceptSecurityContext() and QuerySecurityContextToken() return 0, the client has been authorized. At the end, the security context token has a SecurityIdentifier extracted from it (the _sid variable). (A bit about common Security IDs )

下面是的 NtlmAuth类

int num = Interop.AcceptSecurityContext(ref _credentialsHandle, zero,
                     ref _inputBufferDesc, 20,
                     0, ref _securityContext, ref _outputBufferDesc,
                     ref _securityContextAttributes, ref _timestamp);
if (num == 0x90312)
{
    securityContextAcquired = true;
    _blob = Convert.ToBase64String(inArray, 0, (int) _outputBuffer.cbBuffer);
}
else
{
    if (num != 0)
    {
        return false;
    }
    IntPtr phToken = IntPtr.Zero;
    if (Interop.QuerySecurityContextToken(ref _securityContext, ref phToken) != 0)
    {
         return false;
    }
    try
    {
         using (WindowsIdentity identity = new WindowsIdentity(phToken))
    {
         _sid = identity.User;
    }
}
finally
{
    Interop.CloseHandle(phToken);
}
_completed = true;

在请求类，在被使用后，成功完成3个步骤NtlmAuth的 TryNtlmAuthenticate（）方法NTLM身份验证的，在此之前返回一项最后的 403 的或完成请求，最后一次检查正在取得：

In the Request Class, in the TryNtlmAuthenticate() method where NtlmAuth is being used, after successfully completing the 3 steps of the NTLM authentication, before returning either a final 403 or fulfilling the request, one final check is being made:

if (_host.GetProcessSid() != auth.SID)
{
    _connection.WriteErrorAndClose(0x193);
    return false;
}

下面，在 _host.GetProcessSid（）是在 SecurityIndentifier 卡西尼过程的所有者（我）和 auth.SID 是的SecurityIdentifier 被认证的用户（ _sid 从上面的NtlmAuth类）。如果这些2的SID的是不一样的，一个403被返回和认证停止，否则该请求被提供给浏览器。

Here, the _host.GetProcessSid() is the SecurityIndentifier of the owner of the Cassini process (me) and auth.SID is the SecurityIdentifier of the user that was authenticated (_sid from the NtlmAuth class above). If these 2 SID's are not the same, a 403 is returned and authentication stops, otherwise the request is served to the browser.

我的问题是：

1. 为什么你会需要比较2不同用户的SecurityIndentifiers？这个失败（返回一个403），当我试图使用NTLM与用户/密码的验证是不是的拥有卡西尼进程的用户。


2. 如果这真的是预期的行为，如果是卡西尼作为Windows服务运行时，没有人能够登录，因为主机SID将 S-1-5-18 （或者根据类似的东西操作系统版本），没有人可以登录作为操作系统。这仅仅是卡西尼号的NTLM身份验证实施的一部分，我不能正常使用卡西尼？


3. 如果这显然不是预期的行为，并SecurityIndentifiers在这方面发挥什么作用？是否额外的检查需要做，以确保主机SID的需要在一定的阶级或集团，以接受客户端的SID的某一类/组？是否有OS版本（XP / Vista / 7的）影响，主机/客户端SID的？


4. 打交道时，还是有这里SecurityIdentifiers不适用的用途，因为他们没有被存储，也不传来传去，也不是用来进一步确定用户/客户端？

1. Why would you need to compare the SecurityIndentifiers of 2 different users? This fails (returns a 403) when I attempt to NTLM authenticate with a user/password that isn't the user that owns the Cassini process.
2. If this really is the intended behavior, if Cassini is to run as a Windows service, nobody would be able to log in because the host SID would be S-1-5-18 (or maybe something similar depending on the OS version) and nobody can log in as the operating system. Is this just part of Cassini's NTLM authentication implementation and I'm not using Cassini correctly?
3. If this is clearly not the intended behavior, what role does SecurityIndentifiers play in this context? Does extra checks need to be made to ensure host SID's need to be of a certain class or group in order to accept client SID's of certain class/group? Are there OS version (XP/Vista/7) implications when dealing with host/client SID's?
4. Or are there no applicable uses of SecurityIdentifiers here since they are not being stored nor passed around, nor are they being used to further identify the user/client?

更新：似乎有人在cassinidev论坛建议一个补丁，它移除此SID检查（补丁＃6604）早在2010年，但它仍然被评估。

---

Update: It seems that someone at the cassinidev forums proposed a patch which removes this SID check (patch #6604) back in 2010 but it's still being evaluated.

推荐答案

不是一个答案，但我只是注意到了类似的问题，但略有不同的表现：在Windows服务和卡西尼-dev的托管配置为使用Windows身份验证时，该HttpContext.Current.User是正在运行的服务帐户下，没有谁提出请求的用户。

Not an answer, but I'm just noticing a similar problem, but a slightly different manifestation: when hosted in a windows service and Cassini-dev is configured to use Windows authentication, the HttpContext.Current.User is the account the service is running under, not the user who made the request.

这似乎在卡西尼 - dev下我的错误。

This seems like a bug in cassini-dev to me.

这篇关于Cassini-dev的NTLM身份验证中的SecurityIdentifiers的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！