Проверка подлинности исполняемого файла Windows

Обыскивая методы и протоколы проверки подлинности Windows, я решил понять точную разницу между Negotiate, Kerberos и NTLM, используемыми в простом исполняемом файле, прежде чем использовать его с IIS и веб-аутентификацией.

Я достиг хороших результатов, НО мне все еще нужно больше подробностей о Negotiate и Kerberos.

У меня такой сценарий:

Я создал очень простое приложение Windows Forms C #, которое показывает окно сообщения, отображающее значение для:

System.Security.Principal.WindowsIdentity.GetCurrent().AuthenticationType

Обратите внимание, что я пользователь домена с правами администратора на моем локальном компьютере, у меня есть следующие результаты:

  1. Когда я запускаю exe-файл (двойной щелчок) при активном подключении к DC, я получаю сообщение «Negotiate».

  2. Когда я запускаю exe-файл (запускается как другой пользователь / с использованием локального пользователя), когда я активно подключен к контроллеру домена, я получил NTLM.

  3. Когда я запускаю exe-файл, используя «Запуск от имени администратора» или «Запуск от имени другого пользователя», я получаю «Kerberos».

  4. Когда я запускаю exe-файл, когда я локально вошел в систему, используя локальную учетную запись, я получил "NTLM".

Я понимаю, что LSA будет использовать NTLM для локальных учетных записей. Также я понимаю, что Active Directory использует Kerberos для аутентификации пользователей и компьютеров домена.

У меня вопрос: почему я получаю тип аутентификации Negotiate, когда я запускаю exe, используя свою учетную запись, либо (двойной щелчок), либо «запуск от другого пользователя», используя ту же учетную запись?

Обновление: я заметил следующее:

- Если локальный пользователь запускает exe, то это NTLM
- Если пользователь домена запускает исполняемый файл, тогда это Согласование (если этот пользователь является локальным администратором), но это Kerberos (если этот пользователь не является локальным администратором)
- Если администратор домена запускает исполняемый файл, то это Kerberos.

Я просто поясняю это поведение.


windows-authentication kerberos ntlm windows-security negotiate
person Khaled Obaid    schedule 22.03.2016    source источник
comment
Вопрос непонятный. Пакет аутентификации, используемый для аутентификации пользователя, отличается от протокола, используемого для аутентификации пользователя, и каждый из них отличается от объекта, который выполняет аутентификацию. Нет отношений "один-к-одному". NTLM и Kerberos (и согласование) актуальны только при аутентификации на удаленном компьютере. Аутентификация на удаленном компьютере в среде, не относящейся к домену, будет использовать NTLM, а аутентификация на удаленном компьютере в домене будет использовать Kerberos или NTLM. Что именно вы пытаетесь выяснить?   -  person conio    schedule 03.04.2016
comment
Это неправда. Локальный компьютер также использует пакет аутентификации для аутентификации учетных данных для входа, собранных Winlogon через GINA. Winlogon вызывает LsaLogonUser, который использует пакет проверки подлинности для создания сеанса входа в систему. LSA использует NTLM (Msv1_0.dll) для поиска учетной записи в SAM на локальном компьютере в случае локального входа в систему; удаленный компьютер не нужен.   -  person codekaizen    schedule 04.04.2016
comment
Вы даже не близко. Тот факт, что некоторые страницы (например, та, которую вы указали в своем ответе) неправильно описывают MSV1_0 как NTLM, не означает, что используется протокол NTLM, описанный в [MS-NLMP]. . (Правильное описание: Microsoft Authentication Пакет v1.0, кстати.) Я не знаю, как я могу быть более ясным по этому поводу. Когда вы аутентифицируетесь в локальном SAM, никто не создает проблемы и никто не создает ответ на этот запрос на основе хэшей пароля LM или NT.   -  person conio    schedule 04.04.2016
comment
А GINA устарела почти десять лет и больше не существует в течение двух лет минус 5 дней.   -  person conio    schedule 04.04.2016
comment
Это близко, даже если детали изменились в текущих версиях Windows. LSA использует пакеты аутентификации для аутентификации. Пакет MSV1_0 реализует протокол NTLM, а также использует локальный SAM для поиска информации об учетной записи. Когда-то не было большой разницы между протоколом и реализацией, поскольку все было скрыто. Проблема / ответ - пустяк - LSA по-прежнему делегирует аутентификацию определенным для провайдера способом, в зависимости от провайдера, который был предметом вопроса и ответом.   -  person codekaizen    schedule 07.04.2016
comment
Да, похоже, что в Vista вместо GINA появились поставщики учетных данных, которые предоставляют ту же функцию - предоставляют учетные данные. Они передаются в пакет аутентификации таким же образом. Я так понимаю, вы читали книгу Кита Брауна. Возможно, вы захотите перечитать его, чтобы понять общую архитектуру.   -  person codekaizen    schedule 07.04.2016

Ответы (1)


arrow_upward
7
arrow_downward

Во-первых, (что вы, кажется, понимаете в вопросе, но для ясности) EXE не имеет никакой аутентификации - это просто исполняемый файл. ОС создает объект процесса, который выполняет его в сеансе входа в систему, идентифицированном участником. Именно этот принципал был аутентифицирован NTLM или Kerberos (или каким-либо другим протоколом).

Далее, Negotiate означает, что при создании сеанса входа в систему Пакет проверки подлинности Negotiate использовался, чтобы решить, какой пакет проверки подлинности - Kerberos или NTLM - будет использоваться.

Когда вы запрашиваете значение WindowsIdentity.AuthenticationType, вы в конечном итоге вызываете функцию в Local Security Authority (LSA) с именем _ 2_. Это сообщает подробную информацию о сеансе входа в систему, использованном для запуска процесса, который вы выполняете. Способ создания этого сеанса входа в систему, вероятно, имеет наибольшее влияние на пакет проверки подлинности, используемый для проверки учетных данных.

При первом входе в Windows Winlogon.exe устанавливает интерактивный вход путем вызова LsaLogonUser. Он запрашивает пакеты аутентификации в HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Authentication Packages по порядку, пока не найдет тот, который может аутентифицировать данные учетные данные. После того, как интерактивный вход будет установлен, вы можете создавать новые процессы, используя неинтерактивный вход под разными учетными данными, и в этом случае _ 4_. Одним из параметров этой функции является dwLogonProvider, который имеет следующее значение по умолчанию (которое, вероятно, используется):

LOGON32_PROVIDER_DEFAULT 

Use the standard logon provider for the system. 
The default security provider is negotiate, unless you pass NULL 
for the domain name and the user name is not in UPN format. 
In this case, the default provider is NTLM.

Таким образом, пакет, указанный для сеанса входа в систему, в котором выполняется процесс, зависит от того, как был создан сеанс входа. (Из вашего вопроса неясно, как именно вы создаете сеансы входа в систему, которые вы тестируете ... выполняя "Запуск от имени" во всех случаях? Выход / вход в Windows в некоторых случаях?) Это также зависит от того, какой пакет Winlogon смог выполнить успешно пройти аутентификацию с первым для сеанса интерактивного входа в систему. В конечном счете, однако, обратите внимание, что все механизмы аутентификации вызывают некоторый пакет аутентификации, и если используется Negotiate, предпочтительнее использовать Kerberos, хотя сообщается о Negotiate.

Вот старая, но все еще актуальная диаграмма, которая показывает, как все аутентификации сочетаются друг с другом в Windows:

«Архитектура

Источник

person codekaizen    schedule 27.03.2016
comment
Re. ваша цитата из LogonUser документов - что, если я захочу использовать другой пакет аутентификации? LsaLogonUser позволяет это? Я также считаю, что документация вводит в заблуждение в нескольких аспектах: я предполагаю, что для пользователей домена используется MSV1_0 и MSV1_0, который проверяет кешированные учетные данные и в противном случае использует Negotiate, и это, безусловно, MSV1_0, который используется для локальных пользователей. Я готов поспорить, что используемый пароль сравнивается с паролем, хранящимся в SAM, вместо того, чтобы играть в глупую игру «запрос-ответ» в LSA. - person conio; 03.04.2016
comment
Да, вы можете указать любой пакет аутентификации во время входа в систему (фактически это то, что вы можете сделать, реализовав свой собственный GINA / пакет аутентификации). Winlogon получает идентификатор пакета через LsaLookupAuthenticationPackage, а затем передает значение, возвращенное в LsaLogonUser. Для пользователей домена вы можете использовать MSV1_0 (хотя сквозной трафик обрабатывается именно этим пакетом, а не LSA), или вы можете использовать Kerberos. Для локального входа в систему, как и в документе, вы передаете NULL для имени домена, а имя пользователя не в формате UPN, чтобы получить NTLM, а затем пакет NTLM (не LSA) будет использовать SAM. - person codekaizen; 04.04.2016