Программный поиск данных Active Directory быстрее, чем CSVDE или .NET - PullRequest
0 голосов
/ 05 декабря 2018

Я разработчик, который ищет наиболее эффективный способ получения данных Active Directory с контроллера домена.В прошлом я экспериментировал с .NET API, а также использовал инструменты командной строки CSVDE и LDIFDE.

Существует ли более эффективный и высокопроизводительный способ сделать это программно?Я даже хочу использовать C ++ для программирования на системном уровне, если это необходимо.

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

1 Ответ

0 голосов
/ 05 декабря 2018

.NET * System.DirectoryServices пространство имен (например, DirectoryEntry / DirectorySearcher) является оболочкой над собственным интерфейсом служб Windows Active Directory ( ADSI ).Единственным ударом по производительности является то, что это оболочка (компонент .NET поверх нативного C ++).

Но это не то, где узкое место в производительности.Всякий раз, когда вы создаете отчеты из AD, наибольшим ударом по производительности являются сетевые запросы, поэтому ключ к производительности заключается в том, чтобы сводить сетевые запросы к минимуму и / или запускать отчет как можно ближе к контроллеру домена, чтобы свести к минимуму раунд.-trip time.

Пространство имен System.DirectoryServices.AccountManagement (например, UserPrincipal) является оберткой поверх System.DirectoryServices и, по моему опыту, ужасномедленный, потому что вы теряете контроль над тем, сколько запросов отправляется в AD (например, он обычно получает все атрибутов для объектов AD, даже если вы их никогда не используете).

Если вы хотите повысить производительность,используйте System.DirectoryServices.Есть несколько вещей, которые нужно иметь в виду, чтобы поддерживать производительность:

  1. При использовании DirectorySearcher, всегда добавляйте что-то к PropertiesToLoad.Если вы ничего не просите, он вернет все атрибуты, которые имеют значение.
  2. DirectoryEntry использует кэш свойств.Если вы обращаетесь к DirectoryEntry.Properties, он проверит, есть ли у него свойство в своем кеше.Если нет, он запросит AD для каждого атрибута со значением.Чтобы избежать этого, вы можете заполнить кеш определенными атрибутами, используя DirectoryEntry.RefreshCache(), например:
de.RefreshCache(new[] {"company", "sAMAccountName"});
var company = de.Properties["company"]?.Value as string;
var username = de.Properties["sAMAccountName"].Value as string;
Из-за 1 & 2, просматривая результаты поиска, не используйте SearchResult.GetDirectoryEntry() только для чтения Properties.В противном случае вы в конечном итоге вернетесь в AD, чтобы получить атрибуты, которые вы могли получить во время поиска.Вместо этого используйте PropertiesToLoad. Если вы делаете отчет, вы, вероятно, работаете с несколькими учетными записями, что требует большой обработки.Это означает, что сборщик мусора в .NET не успеет запустить, пока цикл не закончится.Поэтому убедитесь, что вы избавляетесь от созданных вами DirectoryEntry объектов (либо вручную, либо помещаете их в оператор using), прежде чем переходить к следующей учетной записи.В противном случае ваша программа будет использовать тонну памяти (это случилось со мной). При использовании DirectorySearcher.FindAll(), убедитесь, что вы утилизируете результаты (опять же, либо вызвав .Dispose()или поместите это в using заявление).В документации сказано, что в результате вы получите утечки памяти.

Вероятно, можно сказать гораздо больше, но это зависит именно от того, что вы делаете.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...