«Старый» пароль 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:Несанкционированная ошибка.

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

Answer 1

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

По ссылке...

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

Answer 2

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

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

Answer 3

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

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

Спасибо Ch

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

История:

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

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

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

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

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

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

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

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

Answer 4

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

Марк

Answer 5

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

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