2013-07-05 3 views
3

Как видно из названия, у меня возникла проблема с соблюдением политики паролей при настройке пароля пользователя, в частности, ограничения истории паролей.DirectoryServices UserPrincipal.SetPassword игнорирует политику паролей (история паролей)

Сценарий - это сброс пароля пользователя, когда пользователь не знает свой текущий пароль. Я использую следующее:

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); 
    } 
} 

... который работает, как ожидалось, и проверяет против всех ограничений политики паролей.

Кому-нибудь приходилось иметь дело с этим?

Приветствия :)

ответ

3

Это дизайн, насколько я использовал его. SetPassword намерен действовать как администратор, который сбрасывает пароль пользователя - политика сложности выполняется, но нет никаких ограничений на историю. Предположим, что admin сбрасывает ваш пароль, видит, что «невозможно установить один и тот же пароль» - один из ваших паролей скомпрометирован.

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

+0

Я был уверен, что это было по дизайну, и это была моя запланированная работа, если не было другого способа обойти ее. Спасибо за быстрое понимание :) – nokturnal

+0

Любопытный. Я работаю над кодом some.net, который создает новых пользователей домена, который использует 'UserPrincipal.SetPassword()' для установки своего пароля, и когда пароль не соответствует требованиям к сложности пароля для домена, вызывая 'UserPrincipal.Save()' выдает «System.Runtime.InteropServices.COMException» с сообщением, в котором говорится: «Пароль не соответствует требованиям политики паролей. Проверьте минимальную длину пароля, сложность паролей и требования к истории паролей. (Исключение из HRESULT: 0x800708C5)» ' , Сумасшедшая вещь заключается в том, что учетная запись STILL CREATED! – STLDeveloper

+0

@ wiktor-zychla Я тоже сталкивался с той же проблемой. Однако есть ли официальная документация вокруг этого поведения? Просто хотите проверить, упоминается ли это в любой документации Microsoft? Заранее спасибо! – Pranay

0

Указать имя пользователя не найдено через FindByIdentify, вы можете также сначала проверить его на null!

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)); 
     } 
    } 
} 
Смежные вопросы