正如标题所示,我在设置用户密码时遇到了关于密码策略的问题,特别是密码历史记录限制。
当用户不知道他当前的密码时,该方案是用户密码重置。我使用以下内容来完成此任务:
using (PrincipalContext context = new PrincipalContext(ContextType.Domain, "XXXX", "ADMINUSER", "ADMINPASSWORD")) {
using (UserPrincipal user = UserPrincipal.FindByIdentity(context, IdentityType.SamAccountName, username)) {
user.SetPassword(password);
}
}
这适用于每个策略MINUS密码历史记录限制。
现在采取这种情况,当用户想要更改密码并知道我正在使用的当前密码时:
using (PrincipalContext context = new PrincipalContext(ContextType.Domain, "XXXX.XXX.com")) {
using (UserPrincipal user = UserPrincipal.FindByIdentity(context, IdentityType.SamAccountName, username)) {
user.ChangePassword(currentPassword, newPassword);
}
}
...按预期工作,并根据所有密码策略限制进行验证。
有没有人不得不这样做?
干杯:)
答案 0 :(得分:4)
据我所知,这是设计使用的。 SetPassword意图像管理员一样重置用户密码 - 复杂性策略成立但对历史没有限制。假设管理员重置了您的密码,看到“无法设置相同的密码” - 您的一个密码被泄露。
我们的解决方法是允许管理层仅通过我们的某个Web子系统并保留哈希历史记录,以便验证历史记录的责任放在自定义子系统而不是广告上。
答案 1 :(得分:0)
如果未通过FindByIdentify找到用户名,您可能还想先将其检查为空!
using (PrincipalContext ctx = new PrincipalContext(ContextType.Domain, "XXXX.XXX.com")) {
using (UserPrincipal user = UserPrincipal.FindByIdentity(ctx, IdentityType.SamAccountName, username))
{
if (user != null)
{
user.ChangePassword(currentPassword, newPassword);
}
else
{
throw new Exception(string.Format("Username not found: {0}", username));
}
}
}
答案 2 :(得分:0)
我知道这是一篇过时的文章,但我们从未找到可接受的答案。我们的系统人员不喜欢存储自己的历史哈希值的想法。我们最终实现了这样的解决方案:
using (PrincipalContext context = new PrincipalContext(ContextType.Domain,
"XXXX","ADMINUSER", "ADMINPASSWORD"))
{
using (UserPrincipal user =
UserPrincipal.FindByIdentity(context,IdentityType.SamAccountName, username))
{
string tempPassword = Guid.NewGuid().ToString();
user.SetPassword(tempPassword);
user.ChangePassword(tempPassword, password);
}
}
我们将用户的密码重置为我们的代码可以识别的足够长且复杂的随机密码。然后,我们使用用户输入的新密码在更改过程中使用该密码作为旧密码。如果该过程未能通过策略检查(包括密码历史记录),则会将该错误传递给最终用户,他们必须再次尝试