Альтернативы LogonUser для олицетворения сети (C++)

Question

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

Для исходных данных у меня есть: имя машины, имя пользователя (или домен \ имя пользователя), пароль открытого текста.

Я знаю, что есть способ установить соединение с помощью WNetAddConnection в \\ имя_индикатора \ ipc $, тогда большинство сетевых функций будут работать в контексте этой учетной записи, однако win2008 добавил еще один поворот, и некоторые функции по-прежнему используют учетную запись, которая поток работает под.

Я также знаю, что есть способ получить маркер олицетворения с использованием SSPI. Кто-нибудь экспериментировал с этими токенами, они хороши для доступа к общим ресурсам, SCM, удаленным реестрам и тому подобным? Это то, что использует WNetAddConnection?

EDIT: Чтобы уточнить, причину я не могу использовать LogonUser потому, что мне нужно выдавать пользователю не доверенным домен или рабочую группу

EDIT2: Еще одно уточнение: пункт Пытаюсь реализация аналогична psexec, например:

• Программа не должна изменять конфигурацию хоста или активного каталога (например: создание временных локальных пользователей и т. д.). Кроме того, нельзя предположить, что он работает на постоянном токе или нет
• не может быть никаких предположений о том, какое программное обеспечение предварительно установлено на удаленном хосте, только заданное условие заключается в том, что общий доступ к файлам Windows включен в цель
• Учетная запись/password, как известно, работает с целью, но целевая машина может находиться в локальном домене, чужом домене, а не в домене вообще.

EDIT3: Я бы очень хотелось услышать больше о опции ССПИ InitializeSecurityContext/AcquireCredentialsHandle. Есть ли кто-нибудь, кто много работал с этим API? Можно ли использовать токены, возвращенные с олицетворением, чтобы поток мог получить доступ к сетевым ресурсам и копировать файлы и т. Д.? Может ли кто-нибудь опубликовать фрагмент рабочего кода?

EDIT4: Благодаря Marsh Ray проблема решена. Если кто-то ищут, чтобы увидеть код проверки концепции, it is here

Answer 1

Если Вы желаете к «сети доступа к ресурсам» за пределы вашего леса, сделать это с WNetAddConnection2/3, как вы упомянули, или использовать стандартный RPC API, с RPC_ C__ AUTHN__ GSS__ NEGOTIATE и явная структура учетных данных.

Как правило, «олицетворение» - это то, что происходит на стороне сервера. Серверная сторона сможет олицетворять соединение как учетную запись, которую вы подключаете.

Но ключ заключается в следующем: олицетворение имеет смысл только для олицетворения учетной записи, доступ к которой сервер может получить в своем локальном каталоге SAM/domain/forest. Если клиент и сервер находятся в разных лесах, они явно не могут согласовать SID учетной записи для токена олицетворения (за исключением случаев известных идентификаторов безопасности, таких как администратор, которые служат, в основном, для путаницы такого рода вещей) и что необходимо проверить на DACL и т. д.

Возможно, вы хотите вызвать LogonUserEx с флагом LOGON32__ LOGON__ NEW__ CREDENTIALS. Это должно быть успешным (даже в другом лесу - он фактически не аутентифицирует учетные данные, которые вы ему даете), давая вам токен с указанным вами именем пользователя/паролем. Возможно, вам придется использовать DuplicateToken, чтобы превратить это в токен олицетворения. Затем вы можете использовать SetThreadToken для замены токена в вашем потоке.

IMHO на самом деле это не «олицетворение», вы просто используете учетные данные прямо, но это позволяет вам прозрачно получать доступ к сетевым ресурсам, как произвольное имя пользователя/пароль, который вы предоставляете.

Редактировать: О да, имейте в виду, что защита такого типа соединения не существует против человека в середине. Клиент особенно не может сильно аутентифицировать сервер (не хватает героиков, таких как IPSEC), поэтому теоретически вы не можете доверять чему-либо, о чем говорит вам сервер.

Answer 2

Теория гласит, что вы передаете полномочия в качестве SEC_WINNT_AUTH_IDENTITY структуры к функции AcquireCredentialsHandle, которая создает дескриптор, используемый в InitializeSecurityContext. Я никогда не пробовал это на иностранных доменах, хотя я не знаю, работает ли это.

Answer 3

Выполнение этого прямо и надежно через API Windows кажется практически невозможным, плюс Windows делает так много работы за кулисами, чтобы сделать доступ к сети «просто работающим». Плюс, олицетворяющая сторона вещей работает только для одного потока, который называется API.

Но ... вы можете запускать целую программу под другим пользователем ... например, при запуске службы.

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

Я понимаю, что это хак, но это кажется жизнеспособным;)

Answer 4

Вы можете открыть командную строку, сопоставьте диск с помощью открытого текста имени пользователя и пароля. Затем отсоедините привод:

net use m: \\machinename\share password /user:username 
... do stuff ... 
net use m: /delete 

http://technet.microsoft.com/en-us/library/cc756153(WS.10).aspx