В административных целях мне иногда нужно войти в систему как другой пользователь, чтобы диагностировать проблему с его учетной записью. Я хотел бы иметь возможность делать это, не меняя их пароль, чтобы мне не приходилось их беспокоить. В Unix я могу просто сохранить зашифрованный пароль из файла passwd, изменить пароль, а затем отредактировать старый зашифрованный пароль обратно в файл passwd. Есть ли способ сделать что-то подобное в AD?
Поскольку MarkM уже объяснил Зачем мы не должны заменять и восстанавливать пароли пользователей, я постараюсь решить как система не позволяет нам вносить эти изменения.
В Unix хэши паролей изначально хранились в /etc/passwd и может быть прочитан кем угодно. Понимая, что это позволяет любому пользователю потенциально украсть пароли, новые системы unix хранят хэши паролей в /etc/shadow который доступен для чтения только root.
Windows пошла по тому же пути. В среде домена хэши паролей пользователей домена хранятся в кусте реестра SAM на каждом контроллере домена. Вероятно, вы уже знакомы с такими ульями, как HKLM и HKCU.
Начиная с Windows 2000, куст SAM зашифрован 128-битным ключом шифрования пароля, который сам зашифрован с помощью SYSKEY. Должно быть очевидно, что, поскольку операционная система должна считывать содержимое куста для аутентификации пользователей при входе в систему, ключ шифрования должен быть сохранен где-нибудь на компьютере. Для более подробного описания используемых техник обфускации, ознакомьтесь с SysKey и SAM.
Windows изо всех сил пытается помешать администраторам напрямую читать / записывать хэши, и обычно только lsass.exe работает как SYSTEM пользователь может читать хеши.
Однако я уверен, что вы сталкивались с инструментами, которые обходят эту защиту. Например, fgdump может экспортировать хэши паролей из реальной системы путем внедрения кода в lsass.exe, хотя это потенциально может привести к сбою всей системы. И существует множество загрузочных инструментов, которые могут перезаписывать хэши паролей, когда Windows не работает.
Хотя теоретически возможно заменить пароли пользователей, сначала вам нужно обойти широкий спектр средств защиты, встроенных в операционную систему Windows. Любой из этих методов может дестабилизировать вашу систему и никогда не должен использоваться в производственной среде.
Нет, не можешь.
Пища для размышлений: если вы работаете в компании среднего размера, скорее всего, существует политика, запрещающая сотрудникам ИТ (или других сфер) выдавать себя за других пользователей без их явного согласия. Если в вашей компании нет такой политики, вам следует ее серьезно рассмотреть.
Я никогда не видел, чтобы это делалось только с паролем, хотя вы могли бы сделать резервную копию / восстановить объект AD.
Другой способ - сбросить пароль с помощью инструмента администрирования пользователей и компьютеров AD. Это позволит вам обойти ограничения безопасности повторного использования паролей.
Это невозможно. Пароли хранятся с использованием необратимого шифрования. Однако вы можете изменить это поведение, установив флажок рядом с «Хранить пароль с помощью обратимого шифрования» на вкладке «Учетная запись» в диалоговом окне «Свойства» нужного объекта пользователя. Любые будущие изменения пароля будут храниться с использованием обратимого шифрования.
Что касается экспорта этой информации из базы данных AD, я не думаю, что это возможно.
Если ваш вопрос верен, вы должны просто спросить у пользователя его пароль, а затем попросить его сбросить его, как только вы закончите «диагностику». таким образом вы будете прозрачны, и пользователь будет четко осознавать, что происходит в фоновом режиме.
Секрет, к которому вы можете прийти, - это сброс пароля через ADUC для вашего использования и его повторный сброс, чтобы пользователь мог вернуть свой собственный пароль. Однако я не уверен, что здесь будут действовать ограничения на повторение пароля.
В качестве альтернативы, почему бы не использовать такой инструмент, как AMMYY взаимодействовать с сеансом пользователя? Или, если проблема связана с самим компьютером, пусть они выйдут из системы и войдут в RDP как администратор.