2016-08-16 3 views
4

Я пытаюсь получить следующий код для работы, проблема есть, иногда это происходит, иногда это не так. , когда он терпит неудачу, он дает ошибку 0x800704F1 «система не может связаться с контроллером домена для обслуживания запроса на аутентификацию» Я бы сказал, что около 90% времени он терпит неудачу. Я попытался дать ему статический DC, добавив его за контекст, который, к сожалению, не помог. На пользователя admin он работает всегда .. однако я верю, что пользователи должны иметь возможность изменять свой собственный пароль. Ошибка запускается пользователем. Изменить строку пароляC# Изменить пароль AD Directoryservices

Надеюсь, что у кого-то еще есть яркая идея.

 using (var context = new PrincipalContext(ContextType.Domain)) 
     { 
      using (var user = UserPrincipal.Current) 
      { 
       try 
       { 
        user.ChangePassword(txt_old.Text, txt_new.Text); 
        user.Save(); 

       } 
       catch(Exception p) 
       { 
        if (p.HResult.Equals("0x800708C5"))//Not secure enough according to password policy 
        { 
         MessageBox.Show("Volgens het systeem is uw nieuwe wachtwoord niet veilig genoeg, voldoet het aan alle eisen?", "Niet gelukt", MessageBoxButtons.OK, MessageBoxIcon.Warning); 
         return; 
        } 
        else if (p.HResult.Equals("0x80070056")) //Wrong current password 
        { 
         MessageBox.Show("U heeft een verkeerd huidig wachtwoord ingevult, probeer het nogmaals", "Verkeerd wachtwoord", MessageBoxButtons.OK, MessageBoxIcon.Warning); 
         return; 
        } 
        else if (p.InnerException.ToString().Contains("0x80070775")) //Temporarly locked out. 
        { 
         MessageBox.Show("Uw account is tijdelijk vergrendeld door te veel pogingen tot in te loggen met een foutief wachtwoord. Probeer het over 15minuten nogmaals of neem contact op met de helpdesk.", "vergrendeld.", MessageBoxButtons.OK, MessageBoxIcon.Warning); 
         return; 
        } 
        else 
        { 
         MessageBox.Show(System.Security.Principal.WindowsIdentity.GetCurrent().Name + Environment.NewLine + p.HResult + Environment.NewLine + p.Message); 
         return; 
        } 
       } 
      } 
     } 

ответ

9

Два обновления Windows 3177108 и 3167679 изменили поведение ChangePassword.

Существует поток здесь об этой проблеме: https://social.msdn.microsoft.com/Forums/vstudio/en-US/77dc733e-a13d-4349-9088-8065b85d5c3f/userprincipalchangepassword-stops-working-after-windows-updates-3177108-and-3167679?forum=netfxbcl

Кажется, что теперь вы должны указать действительный UPN при создании PrincipalContext.

Прежде чем вы сможете использовать IP как конечную точку при создании контекста, теперь, похоже, оно также должно быть правильным доменным именем.

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

System.DirectoryServices.AccountManagement.PrincipalOperationException: Система не может связаться с контроллером домена для обслуживания запроса проверки подлинности . Пожалуйста, повторите попытку позже. (Исключение из HRESULT: 0x800704F1)

UPDATE 04-10-2016: Исключение отображается выше действительно при вызове Changepassword после обновления общей/общая ошибка, полученной за что угодно. Если, например, некоторые из портов, задействованных в протоколе, блокируются брандмауэром, вы также получаете это (применимо, если вы вызываете с сервера/машины, не присоединенной к домену).

Хороший ресурс для необходимых портов: https://technet.microsoft.com/en-us/library/dd772723(v=ws.10).aspx Обратите внимание, что требуется также динамический диапазон.

Если пользователю не разрешено изменять пароль (политика домена, обход по настройке ДОЛЖЕН ИЗМЕНИТЬСЯ В СЛЕДУЮЩЕМ ЛОГОТИПЕ), вы также получите это исключение.

+0

Спасибо, что с помощью действующего UPN он сработал. – Kage

2

Возможно, проблема связана с нарушением политики паролей. То есть, например, если у вас есть политика паролей, где пользователи не могут изменить свои пароли, чтобы быть одним из своих последних 5, в качестве примера, если они попытаются перейти на один из последних 5, вы увидите это ошибка, брошенная в моем опыте.

ошибка как раз перед исключением вы сообщаете (в моем случае) выглядит следующим образом: TargetInvocationException: COM ошибка при попытке изменить пароль Active Directory ..

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

+0

В нашем случае история паролей не включена. и минимальный возраст пароля - 0 дней. кроме того, такая проблема может привести к тому, что «система не может связаться с контроллером домена для обслуживания запроса проверки подлинности»? – Kage

+0

Кроме того, пользователи еще не используют его. Я просто сделал это и сейчас тестирую его. – Kage

+1

Я слышал, что вы говорите, и понимаете, что в этом случае это не политика. Я знаю, что я получаю сообщение об ошибке «система не может связаться с контроллером домена для обслуживания запроса на аутентификацию», если она не имеет никакого отношения к тому, может ли система найти контроллер домена или нет, а сбой пароля по другой причине. Есть ли у вас другая информация об ошибке? (Внутреннее исключение, дополнительная информация о подробностях?) Тот факт, что вы можете изменить w/admin, конечно, предлагает проблему с разрешениями. – robertpb

2

UPDATE: 10/12/2016: Microsoft обновила эту статью: https://support.microsoft.com/en-us/kb/3177108. Здесь они дали нам проблемы, созданные оригинальными «исправлениями», а также некоторые советы по работе с Kerberos и сброс пароля самообслуживания.

С 11 октября 2016 г. Microsoft повторно выпустила исправления, связанные с https://technet.microsoft.com/en-us/library/security/ms16-101.aspx, для устранения проблем, вызванных исходными обновлениями (которые вы можете прочитать в https://support.microsoft.com/en-us/kb/3177108, включая тот факт, что вы больше не можете изменять пароли на локальных учетных записях).


Я считаю, что у меня есть ответ. Microsoft недавно исправила Windows, так что NTLM больше не может использоваться для изменения паролей.

Решение №1 («молоток»): Попробуйте удалить один или оба этих обновления KB на своем сервере, на котором запущен код.

https://support.microsoft.com/en-us/kb/3177108

https://support.microsoft.com/en-us/kb/3167679

Когда вы говорите, вы можете изменить пароль в качестве администратора, вы имеете в виду только тогда, когда приложение формы работает на компьютере в качестве администратора? Является ли проблема, когда приложение работает на машине без администратора?

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

using (var user = UserPrincipal.FindByIdentity(context, IdentityType.SamAccountName, "test.user0001")) 

и

using (var user = UserPrincipal.FindByIdentity(context, IdentityType.UserPrincipalName, "[email protected]")) 

Использование либо одной из этих линий, а также ваша (получение текущего пользователя) Я смог изменить пароли администратора и не admin. Мой вопрос заключается в том, произошла ли ваша ошибка, когда у вас есть приложение форм, запущенное на машине без администраторов.

+0

Я действительно мог бы использовать образец точно, но это не приложение aspx: o его формы окон, как бы я мог настроить его для использования kerberos? – Kage

+0

Я отредактировал ответ после тестирования вашего кода в приложении Windows Forms. – robertpb

+0

Приложение всегда работало на моей администраторской машине, но когда я пробовал на регулярном сервере терминалов, как обычный пользователь, у него возникла проблема. Я также попробовал ваши варианты, которые вы там поместили, но у обоих тоже есть проблема. Возможно, это какое-то разрешение Active Directory, которое неправильно? – Kage

1

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

Одна заявка была поставляемой поставщиком с закрытым исходным кодом (CyberArk's Privileged Session Manager), в то время как другая была внутренним приложением, разработанным заказчиком, в котором я сейчас работаю; во втором случае я смог взглянуть на код, который действительно был похож на тот, который использовался в исходном вопросе.

К сожалению, на самом деле исправление кода не было вариантом в обоих случаях: для первого приложения нам приходилось сообщать об ошибке поставщику приложения, а для второго нам приходилось сообщать об ошибке для внутренней рабочей группы разработчиков в приложении, мы не смогли бы получить немедленное решение в любом случае. Менеджмент хотел, чтобы оба приложения работали сейчас, поэтому нам пришлось удалить оскорбительные обновления (я знаю, это плохо, а не решение, но ленивое и опасное обходное решение, и я старался изо всех сил избегать этого, но управление - это управление, поэтому ... meh).

Во всяком случае, причина я прыгать с этим ответом: помимо удаления KB3177108 и KB3167679, в моем случае (оба случая), мы также должны были удалить KB3175024 и KB3174644; в то время как эти два обновления были установлены, функция изменения пароля по-прежнему отказывалась работать даже после удаления первых двух.

Итак, если вы оказались в ситуации, когда вы не можете исправить код, и удаление KB3177108 и KB3167679 не решило проблему, вы можете попробовать удалить также KB3175024 и KB3174644.

Смежные вопросы