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

查看:98
本文介绍了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.

有人曾经处理过吗?

干杯:)

推荐答案

据我所知,这是设计使然。 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.

我们的解决方法是允许管理人员通过一个只是我们的Web子系统的一部分,并且保留哈希的历史记录,因此验证历史记录的责任放在了定制子系统上,而不是广告上。

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天全站免登陆