Пароли SecureString для ADUser

В настоящее время я создаю учетные записи ADUser на сервере, и одним из стандартов здесь является то, что учетные записи должны иметь пароль, даже если это пароль по умолчанию, который используется всеми новыми учетными записями.

Меня немного смущает параметр -AccountPassword в командлете New-ADUser и его связь с SecureString. На данный момент мне удалось выжать подходящий пароль для сценария-тестирования, но я понимаю, что это, вероятно, далеко не подходящий пароль для учетной записи, учитывая странные параметры, которые я установил для его работы:

$password = ConvertTo-SecureString "Password1" -AsPlainText -Force

Затем я использую это с New-ADUser: -AccountPassword $password.

Может ли кто-нибудь посоветовать, как справиться с такой ситуацией? Подходит ли мой подход для пароля по умолчанию, или я тут как-то напортачил? Я не реализовал это, поэтому трудно сказать, будет ли это работать эффективно.


passwords powershell active-directory securestring
person Maxime Franchot    schedule 25.07.2017    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Если при установке пароля по умолчанию у вас установлен параметр «Пользователь должен сменить пароль при следующем входе в систему», такой подход вполне нормален. Если ваша задача также не сделать пароль по умолчанию видимым в виде обычного текста, вы можете использовать технику сохранения / загрузки для SecureString, который читается как более 100 шестнадцатеричных символов и может быть сохранен в виде файла. Вы записываете защищенную строку в файл один раз, затем читаете ее из файла и используете как допустимую защищенную строку в New-ADUser. Основным ограничением файлового подхода является то, что строка зашифрована данными пользователя с использованием пользователя, который сгенерировал строку, поэтому вы не можете сохранить SecureString как пользователь A, затем прочитать его как пользователь B и успешно расшифровать.

person Vesper    schedule 25.07.2017
comment
Спасибо, это многое прояснило! В какой-то момент я распечатал защищенную строку, поэтому я думаю, что могу даже жестко закодировать хешированную строку прямо в документе. Если нет, то, учитывая, что учетная запись с паролем создает учетные записи только один раз, и эти учетные записи содержат свои собственные пароли, то проблема User-A-User-B все еще возникает? - person Maxime Franchot; 25.07.2017
comment
Что ж, проблема все еще существует, но если у пользователя A и пользователя B есть свои собственные пароли, даже декодирование исходного пароля по умолчанию не повредит их безопасности. Проблема в том, что если вы генерируете строку как один пользователь, затем сохраняете, затем читаете как другой пользователь, а затем пытаетесь расшифровать, вы получите мусор. Это сделано намеренно. Когда мне приходилось использовать безопасную строку в любом скрипте, я выполнял преобразование из обычного текста, а затем сохранял его в файл, запущенный как пользователь, который будет использоваться для запуска основного скрипта, этот подход никогда меня не подводил. - person Vesper; 25.07.2017
comment
Не сохраняет ли команда New-ADUser пароль пользователя (взятый из -AccountPassword) где-нибудь в его учетной записи / данных учетной записи, а не на пользователе, который запускал учетную запись скрипта? - person Maxime Franchot; 25.07.2017
comment
Да, это так, но как только этот пользователь меняет свой пароль по умолчанию, эта информация перезаписывается. Таким образом, этот подход является жизнеспособным для установки пароля по умолчанию для пользователей, при условии, что они вынуждены сразу же его изменить. - person Vesper; 25.07.2017