Странный DirectoryServices. Совет первый: выражайтесь яснее, где искать

В прошлый раз я вскользь упомянул про подводные камни, встречающиеся на пути программиста, решившего использоваться классы пространства имён System.DirectoryServices или DCOM объекты ADSI, что, по сути, то же самое. Данная тема заслуживает отдельного рассмотрения. Поэтому эту и несколько следующих заметок я посвящу ей.

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

Как делает большинство?
Рассмотрим стандартный код поиска с помощью классов из пространства имён System.DirectoryServices:

DirectoryEntry rootDSE = new DirectoryEntry("LDAP://rootDSE");
string domainContextLDAP = "LDAP://"
    + rootDSE.Properties["rootDomainNamingContext"].Value;

String[] properties = new String[] {
    "objectGUID",
    "displayName",
    "givenName",
    "sn" };
DirectorySearcher searcher = new DirectorySearcher(
    new DirectoryEntry(domainContextLDAP),
    "(objectClass=person)",
    properties,
    SearchScope.Subtree);

using (SearchResultCollection searchResultCol
    = searcher.FindAll())
{
// ...
}

Всё в порядке? Нет, нет и нет! В данном коде пропущена существенная деталь – не указан контроллер домена, на котором будет выполняться поиск. В этом случае может быть задействован любой контроллер домена в текущем сайте. И абсолютно не обязательно, что это будет ближайший к вам сервер. Сайт в большой организации может покрывать несколько офисов в пределах города, а каждый офис может иметь свой контроллер домена – любой из них может быть выбран для выполнения операции поиска. Вес и приоритет SRV записей домена могут повлиять на результат выбора, но в любом случае этот параметр не подлежит конфигурированию на стороне клиента и потому полагаться на него не стоит. Опасность заключается в том, что данный код вполне себе работоспособен, и наблюдать падение производительности вы можете лишь на определённых конфигурациях, причём характерных весьма большим предприятиям. Поэтому отдел контроля качества легко может пропустить данную проблему.

Мы пойдём другим путём.
Но постойте, как же указать сервер, если ни класс DirectoryEntry, ни класс DirectorySearcher не содержат в своих интерфейсах подобного свойства? Всё очень просто. В данном примере для инициализации объекта типа DirectoryEntry применяется так называемый serverless формат записи LDAP пути: LDAP://CN=Users,DC=neverhood,DC=org. Полный LDAP путь позволяет указать не только адрес или имя контроллера домена, но даже порт, на котором слушает сервис:

LDAP://[HostName[:Port]/]DistinguishedName

Пример: LDAP://dc1-nsib.neverhood.org/CN=Users,DC=neverhood,DC=org.

Содержимое объекта rootDSE чуть более предсказуемо, чем результат выбора контроллера домена по-умолчанию. И что более важно, оно зависит от контекста безопасности текущего потока, а не от настроек приоритетов серверов. В частности свойство dnsHostName содержит адрес контроллера домена, через который был осуществлён вход в систему. А это в свою очередь поддаётся конфигурированию на клиенте. И можно надеяться, что при грамотно настроенной конфигурации, сервер, используемый по умолчанию для входа в систему, всегда ближайший. Поэтому код, вычисляющий контекст поиска можно переписать следующим образом:

DirectoryEntry rootDSE = new DirectoryEntry("LDAP://rootDSE");
string domainContextLDAP = "LDAP://"
    + rootDSE.Properties["dnsHostName"].Value.ToString() + "/"
    + rootDSE.Properties["rootDomainNamingContext"].Value;

Чтобы не быть голословным, напоследок приведу простые замеры. Для тестирования использовалась топология, в которой сайт охватывал несколько территориально распределённых офисов. Каждый из офисов содержал свой контроллер доменов. Рабочая машина была сконфигурирована таким образом, что для входа в систему использовался ближайший из них. Приложение выполняла поиск и перебор всех объектов в домене. В первом случае использовалось serverless связывание, во втором контроллер домена указывался явно:

Search context: LDAP://DC=neverhood,DC=org
Time left: 00:00:24.5233572
Entities number: 6234
Press any key...

Search context: LDAP://dc1-nsib.neverhood.org/DC=neverhood,DC=org
Time left: 00:00:06.8716871
Entities number: 6234
Press any key...

По-моему цифры говорят сами за себя.