Делегирование токена с помощью LOGON32_LOGON_NETWORK_CLEARTEXT

Насколько безопасно использовать LOGON32_LOGON_NETWORK_CLEARTEXT ?

У нас есть следующий сценарий:

Веб-сервер A использует Win32 LogonUser. Затем ему нужно вызвать метод asmx на сервере B.

Если используется тип входа в систему LOGON32_LOGON_INTERACTIVE, он работает хорошо. Однако заказчик отклоняет это, поскольку для этого требуется интерактивный доступ.

Если мы используем LOGON32_LOGON_NETWORK, это не позволяет делегировать токен на удаленный сервер, и мы получаем 401 (как и ожидалось, согласно MSDN).

Попытка использовать DuplicateToken для «обновления» токена до интерактивного не удалась. Эта попытка была основана на этой статье, где говорится:

«Когда вы запрашиваете интерактивный вход, LogonUser возвращает первичный токен, который позволяет вам создавать процессы во время олицетворения. Когда вы запрашиваете вход в сеть, LogonUser возвращает токен олицетворения, который можно использовать для доступа к локальным ресурсам, но не для создания процессов. < strong>При необходимости вы можете преобразовать токен олицетворения в первичный токен, вызвав функцию Win32 DuplicateToken."

Но кажется, что если мы используем LOGON32_LOGON_NETWORK_CLEARTEXT, как указано в эта старая ветка, делегирование работает. Но насколько это безопасно для использования? Согласно MSDN:

«Этот тип входа сохраняет имя и пароль в пакете проверки подлинности, что позволяет серверу устанавливать соединения с другими сетевыми серверами, выдавая себя за клиента. систему по сети и по-прежнему обмениваться данными с другими серверами».

Являются ли учетные данные, используемые в этом формате, видимыми для снифферов (мы используем встроенную безопасность Windows, иногда с SSL, но не всегда).

Пожалуйста, порекомендуйте.


token winlogon
person ewolfman    schedule 20.11.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

У меня был тот же вопрос, и хотя я не нашел окончательного ответа, я провел некоторое расследование и прочитал между строк, и это мой вывод (исправления приветствуются):

Идеальный/самый безопасный вариант использования, если ваш код выглядит как этот псевдокод:

success = LogonUser(username, domain, password,
    LOGON32_LOGON_NETWORK_CLEARTEXT, provider, out token)
if (success) {
    StartImpersonation(token)
    remoteConnection = AuthenticateToRemoteServer()
    StopImpersonation()
    CloseHandle(token)

    // continue to use remoteConnection
}

Учетные данные открытого текста, связанные с сеансом LogonUser, будут уничтожены, когда вы закроете его дескриптор (я не нашел ссылки на это, но мне не кажется, что это не так). Таким образом, на время жизни токена была копия учетных данных пользователя, и она использовалась для аутентификации на удаленном сервере. Но ваше приложение уже имело учетные данные в памяти в виде открытого текста (в переменных username, domain и password), поэтому на самом деле это не представляет дополнительной угрозы безопасности.

Любая аутентификация на удаленном сервере, использующем аутентификацию Windows, будет использовать NTML или Kerberos, и ни один из протоколов не отправляет учетные данные по сети, так что это не проблема. Я не могу точно сказать, что произойдет, если удаленный сервер запросит обычную аутентификацию, но я думаю, что более вероятно, что это не удастся, чем будут отправлены ваши учетные данные.

Если вам нужно хранить токен дольше, в документации указано, что учетные данные хранятся в виде открытого текста (где-то). Я сделал дамп тестового процесса и не смог найти их в файле дампа, поэтому я не знаю, означает ли это, что они хранятся в памяти ядра или что-то в этом роде. Я бы немного волновался, если бы мне пришлось долго хранить этот токен.

person bmm6o    schedule 11.02.2015
comment
В основном меня беспокоит два вопроса: можно ли каким-либо образом перехватить учетные данные, когда сервер A подключается к серверу B, как описано в исходном вопросе, и может ли дамп процесса их каким-либо образом раскрыть. Меня больше беспокоит сниффинг сети. Я очень разочарован тем, что MS не предоставляет дополнительной информации об этом токене (или, по крайней мере, я не смог найти никакой информации об этом токене). - person ewolfman; 23.04.2015
comment
Безопасность проводного протокола является ортогональной проблемой. Если серверу требуется открытый текстовый пароль, то вам нечего делать, если вы хотите аутентифицироваться. Но даже если это так, вы можете зашифровать весь канал с помощью TLS. Если у вас нет контроля над сервером, вы можете хотя бы поговорить с поставщиком о его требованиях. Было бы неплохо, если бы вы могли наложить вето на отправку своих учетных данных, но я не могу представить себе реалистичный сценарий, в котором это вызывает беспокойство — если вы не доверяете серверу, почему вы выполняете аутентификацию на нем? - person bmm6o; 16.07.2015