DirectoryServices UserPrincipal.SetPassword 忽略密码策略(密码历史) [英] DirectoryServices UserPrincipal.SetPassword ignores password policy (password history)

查看:25
本文介绍了DirectoryServices UserPrincipal.SetPassword 忽略密码策略(密码历史)的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

正如标题所暗示的,我在设置用户密码时遇到了关于尊重密码策略的问题,特别是密码历史限制.

As the title suggests, I am having an issue regarding respecting the password policy when setting a users password, specifically, the password history restriction.

场景是用户密码重置,当用户不知道他当前的密码时.我正在使用以下方法来完成此操作:

The scenario is a user password reset, when the user does not know his current password. I am using the following to accomplish this:

using (PrincipalContext context = new PrincipalContext(ContextType.Domain, "XXXX", "ADMINUSER", "ADMINPASSWORD")) {
    using (UserPrincipal user = UserPrincipal.FindByIdentity(context, IdentityType.SamAccountName, username)) {
        user.SetPassword(password);
    }
}

这对每一项策略都适用,减去密码历史限制.

This works against every policy MINUS the password history restriction.

现在考虑这个场景,当用户想要更改他们的密码并且知道他们当前使用的密码时:

Now take this scenario, when a user wants to change their password and knows their current password I am using:

using (PrincipalContext context = new PrincipalContext(ContextType.Domain, "XXXX.XXX.com")) {
    using (UserPrincipal user = UserPrincipal.FindByIdentity(context, IdentityType.SamAccountName, username)) {
        user.ChangePassword(currentPassword, newPassword);
    }
}

...按预期工作,并根据所有密码策略限制进行验证.

... which works as expected, and validates against all password policy restrictions.

有人遇到过这种情况吗?

Has anyone ever had to deal this?

干杯:)

推荐答案

这是设计使然,就我所使用的而言.SetPassword 旨在充当重置用户密码的管理员 - 复杂性策略成立,但对历史记录没有限制.假设管理员重置您的密码,看到无法设置相同的密码" - 您的一个密码已泄露.

This is by design, as far as I have used it. The SetPassword is intented to act like an admin who resets user password - the complexity policy holds but there are no restrictions on the history. Suppose admin resets your password, sees "can't set the same password" - one of your passwords is compromised.

我们的解决方法是允许管理层仅通过我们的一个网络子系统并保留哈希历史记录,以便验证历史记录的责任放在自定义子系统而不是广告上.

Our workaround was to allow the management to go through one of our web subsystems only and persist the history of hashes so that the responsibility to verify the history was put on the custom subsystem rather than the ad.

这篇关于DirectoryServices UserPrincipal.SetPassword 忽略密码策略(密码历史)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆