Сброс пароля пользователя в Active Directory по учетной записи администратора домена или другой учетной записи службы
В Active Directory вы можете устанавливать и применять правила, в которых пользователи должны использовать надежные пароли, не могут использовать последние 5+ паролей, которые у них уже были, обеспечивать сложность паролей. Есть ли способ применить такие параметры, чтобы, если учетная запись службы (веб-служба сброса пароля) пыталась установить новый пароль для пользователя, она проверялась на соответствие политике и была либо принята, либо отклонена?
Похоже, что поскольку учетная запись службы принудительно меняет пароль, пользователь может вводить один и тот же пароль через веб-интерфейс и снова и снова использовать один и тот же пароль. Поскольку это служебная учетная запись, изменяющая пароль для него, она не проверяется по последним известным паролям, следовательно, правила пароля не применяются
Хотя программист может запрограммировать проверку сложности, последняя проверка использованных паролей не может быть проверена в веб-интерфейсе, поскольку веб-сервис не знает последних паролей.
Можно ли принудительно сделать так, чтобы такое изменение пароля учетной записью службы также было ограничено, как при обычном изменении пароля пользователя?
1 ответ
В AD есть два типа операций для изменения пароля пользователя - изменение, которое может быть выполнено анонимно, поскольку для него требуется старый пароль, как часть запроса, и сброс, который не требует старого пароля и должен выполняться пользователь с доступом для сброса паролей для целевой учетной записи.
В этом случае программное приложение выполняет операцию сброса, не зная старого пароля пользователя, но при этом аутентифицируясь как предположительно учетная запись службы с необходимыми правами.
С точки зрения AD, пароль сбрасывается в административном порядке; В этом случае история паролей никогда не применяется, поскольку администратор, выполняющий сброс, не должен знать старые пароли пользователя - если у них есть привычка устанавливать новый пароль, скажем, Thursday1 наличие такой несоответствующей политики в операции сброса было бы весьма запутанным.
Несмотря на плохое взаимодействие с пользователем, лучшим механизмом, который я могу придумать для этого, было бы сделать так, чтобы веб-приложение сбрасывало пароль (возможно, на что-то, что они не вводят, только генерировали), а затем устанавливало "необходимо изменить пароль при следующем входе в систему". msgstr "пометить учетную запись, чтобы заставить пользователя немедленно выполнить операцию смены пароля, что приведет к сохранению истории.
Здесь обсуждается использование API-интерфейсов LDAP в.Net для достижения цели принудительного ведения истории при таком сбросе, но я не уверен, будет ли это вариант для вас в зависимости от приложения, которое вы используете; если вы управляете кодом и используемая библиотека LDAP поддерживает элементы управления, то это должно быть выполнимо.