Ошибка 0x800706BA при создании пользователя в PDC. Кто-нибудь видел это раньше?

Question

Я пытаюсь создать нового пользователя, используя следующий фрагмент кода.

using (var ad = 
   new PrincipalContext(ContextType.Domain, 
                        "<domain>", 
                        "<ad user>", 
                        "<ad pass>"))
{
    using (var aduser = new UserPrincipal(ad, "dummy", "password", false))
    {
        aduser.Save();
    }
}

Однако я получаю сообщение RPC Unavailable с кодом ошибки 0x800706BA.

Кто-нибудь видел его раньше?

И, что еще важнее, решил это!

Answer 1

Хотя интерфейсы AccountManagement, предоставляемые .NET 3.5, не помогли мне решить проблему, откат к верному LDAP сработал. Так что я пишу здесь для потомков.

/*
 * First we need to create the user...
 */
using (var dirEntry = new DirectoryEntry("LDAP://<IP/name>", 
                                         "<admin>", 
                                         "<admin pass>", 
                                          AuthenticationTypes.ServerBind))
{
  using (var newUser = dirEntry.Children.Add("CN=dummy", "user"))
  {
      newUser.Properties["samAccountName"].Value = "dummy";
      newUser.CommitChanges();
  }
}

/*
 * Then set its password!
 *
 * If the password is set in the same 
 * transaction as the creation an error occurr.
 */
using (var user = new DirectoryEntry("LDAP://<IP/name>/CN=dummy,DC=corp", 
                                     "<admin>", 
                                     "<admin pass>"))
{
  user.Invoke("SetPassword", new object[] { "password" });
  user.CommitChanges();
}

Answer 2

На самом деле это общая проблема настройки домена. Могу поспорить, что вы также не можете использовать оснастку «Active Directory - пользователь и компьютер» для создания нового пользователя на своем компьютере. Я предлагаю вам загрузить Средства администрирования Windows 2003 или Средство удаленного администрирования Windows 2008 и попробовать сначала выполнить это вручную с компьютера.

Как только вы докажете, что это общая проблема с настройкой домена, я думаю, вы можете попытаться опубликовать свой вопрос на ServerFault.com. Там вы быстрее и лучше ответите.

Во многих операциях AD, таких как сброс пароля, операция выполняется через MS-RPC, но не через LDAP. Поэтому я не удивлен, увидев сообщение об ошибке RPC server unavailable при создании нового пользователя AD.

Существует множество причин, по которым RPC server unavailable вызывается, вы можете проверить этот Артикул MSDN и посмотреть, повезет ли вам.

Если вы не настраивали Active Directory раньше, вот некоторая основная информация, которую вам необходимо знать.

1) Вам необходимо убедиться, что вы используете правильный DNS-сервер. Active Directory хранит много полезной информации о DNS. Это не только ваше доменное имя и имя PDC. У него есть некоторые служебные записи. Если целевой PDC - это просто тестовый домен, который вы настраиваете, многие программисты делают ошибку, просто изменяя локальный файл хоста, чтобы преобразовать PDC в IP-адрес. Это не сработает и вызовет некоторые проблемы в будущем.

2) Необходимо убедиться, что часы на вашей машине для разработки синхронизированы с вашим PDC. Проверка подлинности Kerberos чувствительна ко времени. Active Directory использует проверку подлинности Kerberos. Обычно это не будет проблемой, но некоторые программисты любят использовать VM. Я видел, что есть некоторые проблемы с запаздыванием, если на одном хосте работает много виртуальных машин.

3) Убедитесь, что ваша служба RPC на PDC действительно работает и не заблокирована брандмауэром. Если вы обращаетесь к производственному домену, сетевой администратор может заблокировать доступ к порту 135 по соображениям безопасности.

Это лучший совет, который я могу дать. Надеюсь это поможет. Если ничего из вышеперечисленного не помогает, я думаю, что вам нужно устранить неполадки, посмотрев на сетевые пакеты. Захватите трассировку сети, используя wireshark. Убедитесь, что вы изменили свой код, чтобы не использовать шифрование, указав ContextOptions.SimpleBind при создании вашего PrincipalContext

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

System.DirectoryService.AccountManagement namepsace использует DirectoryEntry для внутреннего использования. DirectoryEntry использует ADSI для внутреннего использования. ADSI имеет сложную логику для установки пароля пользователя. Существует три способа установить пароль пользователя в Active Directory в следующем порядке

1. Обновление пароля LDAP по каналу SSL
2. Kerberos установить пароль с использованием протокола Kerberos
3. вызов MS-RPC через порт 135

ADSI не будет использовать обновление пароля LDAP, если не настроен SSL. К сожалению, SSL не настроен должным образом из коробки. Вам нужно сделать дополнительную настройку, чтобы она работала. Он не настроен, потому что сама Windows вообще не нуждается в использовании SSL. У него Kerberos работает очень хорошо. Так что, в вашем случае, я уверен, что вариант 1 не будет использован.

Вариант 2 также не будет работать, потому что вы не указали правильный DNS. Вы используете свой собственный локальный файл хоста.

Теперь, перейдя к варианту 3, вызов может быть успешным, только если ваш текущий контекст безопасности потока разрешен. Из вашего описания звучит так, будто ваша рабочая станция вообще не присоединена к этому целевому домену. Итак, я не ожидаю, что у вас есть токен Kerberos. Как правило, он должен использовать NTLM. Если у вас есть пользователь домена с тем же именем пользователя и паролем, что и ваша учетная запись, используемая на вашей рабочей станции, он должен работать. Вы также должны убедиться, что учетная запись пользователя домена имеет соответствующие права. Во всяком случае, это не в моих знаниях.

Дело в том, что вы получаете RPC server unavailable. Вы, должно быть, ошибаетесь во всех трех вариантах.

Да, вы сделали это с помощью запроса LDAP. Возможно, это работает только потому, что вы используете простой LDAP без SSL вообще. Это означает, что ваш пароль в текстовом формате на проводе.

Я предлагаю исправить вашу рабочую станцию, чтобы использовать DNS на этом контроллере домена. Все должно просто работать.

ОБНОВЛЕНО

Я не читал ваше опубликованное решение, прежде чем ответить вам. Если у вас DirectoryEntry подход работает, я не понимаю, почему AccountManagement подход не работает. Чтобы понять разницу, нам может понадобиться разобрать ее.