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