SecurityIdentifiers в аутентификации NTLM от Cassini-dev - PullRequest
Новая
       97

SecurityIdentifiers в аутентификации NTLM от Cassini-dev

2 голосов
/ 23 ноября 2011

В этом блоке кода в классе аутентификации NTLM Cassini-dev, вызовы, сделанные в SECUR32.DLL (через Interop ), выполняются для аутентификации закодированных в base64 данных в заголовках Authorization HTTP-запроса.Это имеет смысл, когда оба AcceptSecurityContext () и QuerySecurityContextToken () возвращают 0, клиент авторизован.В конце токен контекста безопасности извлекает из него SecurityIdentifier (переменная _sid ).(Немного о общих идентификаторах безопасности )

Вот соответствующий раздел NtlmAuth Class 

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;

В запросе Класс , в методе TryNtlmAuthenticate(), где используется NtlmAuth, после успешного завершения 3 шагов аутентификации NTLM перед возвратом либо окончательного 403 или выполнения запроса выполняется одна последняя проверкаmade: 

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

Здесь _host.GetProcessSid () - это SecurityIndentifier владельца процесса Cassini (me) и auth.SID SecurityIdentifier пользователя, который был аутентифицирован ( _sid из класса NtlmAuth выше).Если эти 2 SID не совпадают, возвращается 403, и аутентификация прекращается, в противном случае запрос передается в браузер.

Мои вопросы:

  1. Почемувам нужно сравнить SecurityIndentifiers 2 разных пользователей?Это завершается ошибкой (возвращает 403), когда я пытаюсь NTLM аутентифицироваться с помощью пользователя / пароля, который не пользователь, которому принадлежит процесс Cassini.
  2. Если это действительно предполагаемое поведение,если Cassini будет работать как служба Windows, никто не сможет войти в систему, потому что SID хоста будет S-1-5-18 (или, возможно, что-то похожее в зависимости от версии ОС), и никто не сможетвойдите как операционная система.Является ли это только частью реализации аутентификации NTLM в Cassini, и я неправильно использую Cassini?
  3. Если это явно не предполагаемое поведение, какую роль в этом контексте играет SecurityIndentifiers?Нужно ли проводить дополнительные проверки, чтобы убедиться, что идентификаторы SID хоста относятся к определенному классу или группе, чтобы принимать идентификаторы SID клиента определенного класса / группы?Существуют ли последствия версии ОС (XP / Vista / 7) при работе с идентификаторами безопасности хоста / клиента?
  4. Или здесь нет применимых применений SecurityIdentifiers, поскольку они не хранятся, не передаются и не используютсядля дальнейшей идентификации пользователя / клиента?

Обновление: Похоже, что кто-то на форумах cassinidev предложил патч, который удаляет эту проверку SID (патч № 6604) еще в 2010 году, но он все еще оценивается.

1 Ответ

1 голос
/ 01 декабря 2011

Не ответ, но я просто замечаю похожую проблему, но немного другое проявление: при размещении в службе Windows и Cassini-dev настроен на использование аутентификации Windows, HttpContext.Current.User является учетной записьюсервис запущен, а не пользователь, который сделал запрос.

Мне кажется, что это ошибка в cassini-dev.

...