DirectoryServices.AccountManagement «старый» пароль еще проверяет после смены пароля

Question

После сброса пользовательского пароля в Active Directory, если пользователь пытается войти в систему, используя свой старый пароль, следующий код проверяет, как True:

Dim up As UserPrincipal = GetAdUser(objContext, arg_strBA, arg_strUsername) 

If up IsNot Nothing Then 

    Dim valid As Boolean = up.Context.ValidateCredentials(
    up.UserPrincipalName, arg_strPassword, ContextOptions.Negotiate) 


    If (valid) Then strReturn = up.SamAccountName 

End If 

Мы сбросить пароль, используя следующий код:

Dim objUser As New DirectoryEntry(arg_strLDAPPath) 

If Not objUser Is Nothing Then 
    objUser.AuthenticationType = AuthenticationTypes.Secure 


    objUser.Invoke("SetPassword", arg_strNewPW) 
    objUser.CommitChanges() 
end if 

пароль сброса работает нормально, и пользователь может войти с новым паролем, но их старый пароль не должен еще проверить.

Когда вышеуказанные ValidateCredentials работают для старого пароля, мы назначаем учетные данные вызову веб-службы, который затем терпит неудачу с ошибкой «401: Несанкционированный».

Кто-нибудь видел что-нибудь подобное?

Благодаря Dirk

Answer 1

Я кладезь ответ Here

Из ссылки ...

«Тем не менее, важно то, что делает ContextOption не обеспечить использование Kerberos только. Оказывается, что при определенных ситуациях (например, если вы указываете AD, а не локальный, и у вас есть достаточно современный сервер), код предпочитает делать переговоры независимо от того, что. В этом смысле указание Sealing, вероятно, означает, что оно будет использовать Kerberos, но не обязательно исключительно. Флаг, который действительно имеет значение, подстегивает несколько слоев под этим. Под обложками этот метод заканчивается установкой LdapCo nnection, установив сетевые учетные данные для подключения, установив AuthType (фактический флаг, который имеет значение!) и, наконец, вызов метода Bind(). Метод LdapConnection.Bind() устанавливает аутентифицированное соединение с одним из серверов AD с использованием указанных учетных данных. Проблема в том, что когда PrincipalContext.ValidateCredentials устанавливает этот вызов (в вашем сценарии), он всегда устанавливает AuthType = Negotiate. В этом случае Kerberos действительно используется, и заканчивается неудачей, но система возвращается к NTLM. "

Answer 2

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

Марк

Answer 3

Я предполагаю, что вы ValidateCredentials выполняется на клиентской машине. Если это так, то он имеет старый (успешный) пароль, кэшированный. Это делается для того, чтобы пользователи могли войти в систему, если Active Directory отключен или недоступен. Распространение изменений требует определенного времени.

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

Answer 4

Это работает - см. РЕШЕНИЕ ниже - Пожалуйста, дайте мне знать, если вы найдете это полезным, поскольку наш магазин разделен о том, является ли это решением ОК.

Решение для Active Directory, разрешающего старый пароль работать после изменения. Мне очень хотелось бы получить обратную связь о принятии этого решения, поскольку оно использует ChangePassword во время аутентификации входа в систему Это необычная вещь, но она работает. В настоящее время наш магазин не использует это решение, поэтому, если кто-нибудь скажет мне, используют ли они это или нет, это будет оценено по достоинству.

Спасибо Ch

Active Directory и старые пароли возвращающиеся правомочно (15 минут + - час). Это происходит при вызове SetPassword или ChangePassword.

История:

Я считаю, что это называется «Feature» АД и дизайном, встроенной в AD, так что, когда пользователь изменяет пароли есть своего рода льготный период, который позволяет все ресурсы, используя эти пароли для перехода на новый.

Один из примеров AD, который поддерживает концепцию, согласно которой AD знает последний пароль, - это изменение пароля для входа на ПК - в этом случае компьютер не разрешит вход в старый пароль. Хотя у меня нет ответа на этот вопрос (за исключением Microsoft, чтобы заставить это работать), я считаю, что это не так просто, как может показаться, поскольку ПК задействован, и на нем есть пароли.

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

Использование удаленного рабочего стола с Windows 7 ПК на R2 поле Windows Server 2008. Войдите в систему из окна «Безопасность Windows», затем нажмите «ОК», нажмите «ОК» и вы вошли в систему. Теперь измените свой пароль для пользователя, которого вы использовали для удаленного, в поле с (отличным от вашего пользователя Kirkman?), Выйдите из системы и войдите в систему снова со старым паролем (в течение 15 минут до часа + -). Старый пароль приведет вас к окну Windows Security и к окну OK. Когда вы нажмете OK, произойдет сбой. Если вы начнете работу с удаленного рабочего стола и попробуйте плохой пароль, вы будете остановлены в окне Windows Security Box с сообщением «Ошибка входа в систему». По истечении срока действия вы не пройдете окно безопасности Windows со старым паролем. (убедитесь, что вы запускаете с Remote Desktop каждый раз, когда НЕ переключают пользователей, которые будут действовать так, как ожидалось, что также показывает, что ПК в чем-то вовлечен). По крайней мере, это не вход пользователя в систему, но это показывает, что (то, что кажется AD) на некотором уровне позволяет старым паролям проходить аутентификацию до некоторого уровня.

Исследование: Я нашел много ссылок на эту проблему и только одно потенциальное решение, которое до этого момента я не смог определить, можем ли мы его реализовать (это ссылка на вызов строго через Kerberos, а не NTLM, который не так просто, как может показаться в документации и моих исследованиях). Я нашел много ссылок на взаимодействие с AD в .NET, но не фактическое руководство AD.

РЕШЕНИЕ РЕШЕНИЯ РЕШЕНИЯ - прочитайте эту часть, если вы хотите РЕШЕНИЕ СОХРАНЕНИЯ !!! Настоящее: Я обнаружил (случайно при тестировании), что вызов ChangePassword в AD не позволит переданному OldPassword успешно сменить пароль на новый пароль. По моему мнению, этот тест, который действительно работает, на самом деле не известен, поскольку я не нашел ссылки на его использование. На самом деле я не нашел решения этой проблемы. Однажды утром в 3 часа ночи я понял, что могу использовать это использование ChangePassword, чтобы обеспечить решение этой проблемы - по крайней мере, обход, который мы можем использовать немедленно, пока не будет найден лучший подход.

Сначала я проверяю, что все верно, и AD возвращает, что пароль действителен. Затем выполняется вызов ChangePassword (имя пользователя, oldpassword, newpassword) со старым паролем и newpassword в качестве пароля, предоставленного пользователем (оба одинакового). Я знаю один из двух (возможно, три, но нарушение политики паролей останавливает его после успеха). Либо OldPassword хорош, и мы терпим неудачу, потому что политика паролей не выполняется (история, новый пароль не может быть одним из последних N паролей), или мы терпим неудачу, потому что старый пароль неверен (оба возвращены как ошибка исключения с текстом в сообщении).Мы проверяем это последнее условие, и если старый пароль недействителен, мы не разрешаем пользователю войти в систему.

Будущее: Возможно, второй комплект глаз поможет.
Я думаю, что решение находится в олицетворении или Kerberos. У меня не было успеха в том, чтобы найти достаточно одного из них в качестве решений. Очевидно, что AD может различать старые пароли, потому что это делает ChangePassword. То, что мы делаем, лежит в основе безопасности, поэтому не все открыто (например, возможность видеть историю паролей в AD, я не нашел способ получить к ней доступ).

Answer 5

Этот вопрос не имеет отношение к кодексу, а виновник более слышать является активным каталогом ...

Пожалуйста, обратитесь http://support.microsoft.com/kb/906305 для решения ...