DirectoryServices.AccountManagement «старый» пароль все еще проверяется после смены пароля - PullRequest
4 голосов
/ 16 апреля 2009

После сброса пароля пользователя в 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

Ответы [ 5 ]

5 голосов
/ 06 февраля 2012

Эта проблема не связана с Кодексом, но виновником перехвата является Active directory ...

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

2 голосов
/ 01 июля 2011

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

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

Спасибо Ch

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

История:

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

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

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

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

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

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

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

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

1 голос
/ 17 апреля 2009

Я нашел ответ Здесь

По ссылке ...

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

0 голосов
/ 16 апреля 2009

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

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

0 голосов
/ 16 апреля 2009

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

Марк

...