Сброс пароля пользователя в Active Directory по учетной записи администратора домена или другой учетной записи службы

В Active Directory вы можете устанавливать и применять правила, в которых пользователи должны использовать надежные пароли, не могут использовать последние 5+ паролей, которые у них уже были, обеспечивать сложность паролей. Есть ли способ применить такие параметры, чтобы, если учетная запись службы (веб-служба сброса пароля) пыталась установить новый пароль для пользователя, она проверялась на соответствие политике и была либо принята, либо отклонена?

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

Хотя программист может запрограммировать проверку сложности, последняя проверка использованных паролей не может быть проверена в веб-интерфейсе, поскольку веб-сервис не знает последних паролей.

Можно ли принудительно сделать так, чтобы такое изменение пароля учетной записью службы также было ограничено, как при обычном изменении пароля пользователя?

В AD есть два типа операций для изменения пароля пользователя - изменение , которое может быть выполнено анонимно, поскольку для него требуется старый пароль, как часть запроса, и сброс , который не требует старого пароля и должен выполняться пользователь с доступом для сброса паролей для целевой учетной записи.

В этом случае приложение выполняет операцию сброса, не зная старого пароля пользователя, но при этом аутентифицируясь как предположительно учетная запись службы с необходимыми правами.

С точки зрения AD пароль в административном порядке сбрасывается; В этом случае история паролей никогда не применяется, так как администратор, выполняющий сброс, не должен знать старые пароли пользователя - если у него есть привычка устанавливать новый проход, скажем, Thursday1если он не соответствует политике в операции сброса, быть довольно запутанным.

Несмотря на плохое взаимодействие с пользователем, лучшим механизмом, который я могу придумать для этого, было бы сделать так, чтобы веб-приложение сбрасывало пароль (возможно, на что-то, что они не вводят, только генерировали), а затем устанавливало «необходимо изменить пароль при следующем входе в систему». msgstr "пометить учетную запись, чтобы заставить пользователя немедленно выполнить операцию смены пароля, которая будет приводить в исполнение историю.

Там какое - то обсуждение с использованием API - интерфейсов LDAP в .NET для достижения цели обеспечения соблюдения истории на этом виде сброса здесь , но я не уверен , если это будет вариантом для вас , в зависимости от используемого приложения; если вы управляете кодом и используемая библиотека LDAP поддерживает элементы управления, то это должно быть выполнимо.