Многие системы (например, Linux su или Meditech emulate) позволяют администратору динамически подражать другому пользователю.
Я новичок в среде сервера / домена Windows, как администратор может подражать другому пользователю (Active Directory)? Например, я хотел бы войти в систему / сервер Windows XP (в домене) как другой пользователь (не мой, с помощью эмуляции). Предположим, у меня есть права администратора.
Я понимаю, что есть "Запуск от имени ...", но это не то же самое, что вам все еще нужен пароль. Я просто хочу подражать среде, чтобы я мог воспроизводить проблемы пользователя без его присутствия. Я знаю, что есть такие вещи, как копирование папки профиля пользователя, но не захватывает все (реестр и т. Д.), И это несколько хакерский подход.
Не может быть сделано. Даже если бы вы могли, было бы очень маловероятно точно воспроизвести проблемы пользователя без их присутствия, чтобы показать вам, что именно они делают. RunAs - это самое близкое, но если вы хотите устранить проблемы с пользователями, это многоэтапный процесс, который я рекомендую:
1) Настройте рабочую станцию так же, как настроена машина пользователя, и 2) Войдите в систему с локальной непривилегированной учетной записью. Как только это будет сделано, 3) Попробуйте воспроизвести проблему. Это поможет вам сузить проблему до проблемы с компьютером, учетной записью или средой пользователя соответственно. Я знаю, что рассказываю вам то, что вы, вероятно, уже знаете, но мне казалось, что мой первый абзац сам по себе не дал бы исчерпывающего ответа.
Если вы хотите получить профиль пользователя с компьютера, есть инструмент USMT от Microsoft. Вот, который был сделан для передачи файлов и настроек пользователя с одной машины на другую.
Самое близкое, что вы можете сделать в Windows, - это создать тестового пользователя с тем же членством в группах. Если вам нужно отладить что-то с их профилем, принятый процесс - сделать это с помощью удаленного помощника или аналогичного инструмента, который позволяет пользователю следить за тем, что вы делаете.
Речь идет о контрольных журналах. Информация об учетной записи Windows часто используется при создании журналов и контрольных журналов, и по этой причине при использовании Active Directory для администратора совершенно неуместно входить в систему как пользователь. Вам нужно, чтобы имя администратора, а не пользователя, было связано с чем-либо, даже во время отладки проблемы.
Большая часть причин для этого - защита пользователей от администраторов. Когда я выдаю учетную запись пользователю, я как администратор все еще могу делать много вещей, но единственное, что я не могу сделать, - это подписывать что-то этим именем пользователя. Я даже могу завладеть учетной записью пользователя; просто для этого я должен сначала сменить их пароль.
Это хорошая вещь! Это помогает защитить конечных пользователей от администраторов-мошенников. Если администратор берет на себя учетную запись пользователя из-за плохих вещей, имя этого пользователя все равно попадет в любые журналы. Но пользователь будет знать, потому что у него больше не будет доступа к учетной записи. Администраторы никогда не узнают пароли пользователей, поэтому администратор не сможет восстановить учетную запись пользователя без уведомления. Это дает пользователю возможность зарегистрировать жалобу и защитить себя от действий администратора.
По крайней мере, это идея. С практической точки зрения, если бы я действительно был настолько закулисным и хотел бы, чтобы на чем-то было чье-то имя, я, вероятно, мог бы создать сценарий для выполнения этого действия и назначить его пользователю как сценарий входа в систему или что-то подобное. Кроме того, я подозреваю, что большинство администраторов могли бы отговорить себя от случая сброса пароля до того, как пользователь узнает, что произошло ... или даже доверить это специалисту службы поддержки уровня 1. Так что нет ничего идеального. Но, по крайней мере, в этом последнем случае запись сброса также где-то существовала.
Существует реальная потребность в администраторах домена или им подобных для подражания пользователям, но вы не можете сделать это прямо сейчас.
Примером может служить случай, когда пользователь не присутствовал, когда администратор / технический специалист были доступны для оказания помощи. Если администратор может подражать пользователю (войти в учетную запись пользователя без изменения пароля) и исправить любую проблему, нет ничего, что указывало бы на то, что контрольный журнал все еще не мог произойти, что указывает на то, что учетная запись пользователя была эмулирована каким-либо администратором. Учитывая, что администраторы по сути имеют полный контроль над всеми учетными записями пользователей, нет причин исключать эмуляцию как решение.
Как и все хорошие инструменты, злоумышленники могут злоупотреблять эмуляцией, считая, что они могут использовать ее для компрометации Windows. Возможно, для борьбы с этим можно включить или отключить эмуляцию с помощью групповой политики для системных администраторов, которые захотят ее использовать. Или, возможно, это можно было бы присоединить к учетной записи пользователя в AD таким образом, чтобы его можно было включать и выключать с помощью галочки, так же как можно включить или отключить учетную запись указанным образом.
Я отправил в Microsoft отзыв об этой потенциальной функции. Я надеюсь, что это будет реализовано.