Как программно найти контроллер домена / основной контроллер домена?

Я хотел бы знать, как определить в работающем приложении контроллер домена / основной контроллер домена рабочей станции Windows или сервера, на котором выполняется приложение, с помощью API Win32.

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

Я видел фрагмент кода C #, который якобы делает это, но не знаю, есть ли какое-либо отношение к API Win32. . Существует множество веб-страниц о том, как получить DC, но все они вызывают командные сценарии, а не API.

Рад иметь код, но готов сделать домашнюю работу по извлечению шагов, если кто-то укажет мне правильное направление.

Есть ли аналог в линуксе? (например, собственные вызовы для поиска сервера имен? Я не предполагаю контекст Linux с контроллером домена Windows).

(Ага ... только что обнаружил этот вопрос: Получите доменное имя компьютера из Windows API. Покопаемся в нем немного подробнее. РЕДАКТИРОВАТЬ: Может быть, мне нужна функция NetDCName? Где мне взять нужные ему параметры?).

ИЗМЕНИТЬ 19 апреля: Я закодировал / протестировал NetDCName, используя подсказки Эрика. Да, он выдает имя контроллера домена, если он есть, и сигнал ошибки, когда его нет, что является правильным функциональным поведением.

Однако кажется, что вызов функции занимает несколько секунд! Почему это могло быть? Это приводит к неприемлемой, видимой для пользователя задержке при проверке, которую я пытаюсь выполнить.


person Ira Baxter    schedule 18.04.2014    source источник


Ответы (1)


NetGetDCName - один из вариантов; если вам нужна дополнительная функциональность, DsGetDcName тоже вариант.

В документации MSDN четко указано, что NULL используется для обозначения значения по умолчанию, поэтому

nStatus = NetGetDCName(NULL, NULL, (LPBYTE *) &lpDcName);

вернет контроллер домена для домена по умолчанию на локальном компьютере.

person Eric Brown    schedule 18.04.2014
comment
Спасибо за подтверждение ответа. Однако вызов функции, похоже, занимает несколько секунд! Почему это могло быть? - person Ira Baxter; 19.04.2014
comment
@IraBaxter Я подозреваю, что это тайм-аут RPC. Поищите его на msdn.com (к сожалению, по мере того, как я печатаю, он не работает), и вы, вероятно, найдете что-то полезное. - person Eric Brown; 20.04.2014
comment
Хм, да, есть довольно длинное объяснение support.microsoft.com/kb/247811 включая тот факт, что существует множество поисков на основе RPC. Я не видел явной ссылки на тайм-аут RPC, но я вижу, как, если все эти поисковые запросы будут выполнены и не все получатели будут активными, что-то будет тайм-аутом. Но разве такое поведение можно было бы ожидать при нормальных обстоятельствах? Статья непонятна. Он действительно говорит, что что-то кэширует ответ, очевидно, чтобы избежать всей этой работы в следующий раз. Я много раз пробовал поиск в нашей внутренней сети; все задержки. - person Ira Baxter; 20.04.2014