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