Глядя на трафик LDAP через Wireshark, мне было любопытно понять, как происходит диалог между клиентом Windows и Active Directory. Каждый диалог будет иметь размер менее 80 Кбайт. Но бывают случаи, когда размер разговора составляет 2,5–3 МБ. Может ли кто-нибудь объяснить типы запросов, которые запрашиваются в AD от клиента Windows, и, возможно, различные размеры обмениваемых пакетов? У меня есть захват пакетов с данными полезной нагрузки, но я не знаю, как его прочитать. Есть один известный мне способ начать беседу - это команда "gpupdate / force". Я также хотел бы узнать, какая другая внутренняя обработка в Windows инициирует запросы?
Active Directory необычен среди каталогов LDAP тем, что нередко имеет очень большие полезные данные. Фактически, максимальная полезная нагрузка, которую вы можете отправить, составляет 12 Мбайт. Это кажется невероятно большим, но вот и все.
На стороне ввода возможно, что кто-то может отправить запрос типа (| (samAccountName = jsmith) (samAccountName = jdoe) (...) (samAccountName = zsmith)) и указать отдельные подстановочные знаки или их вместе.
На стороне вывода одной из распространенных причин больших объемов полезной нагрузки является подкачка. Когда у вас есть запрос, который возвращает несколько результатов, ответ может быть огромным. AD имеет встроенную поддержку разбиения по страницам, и это довольно просто сделать, так что один простой запрос для всех объектов может вернуть ГБ ответа.
Другой сценарий не указывает фактические атрибуты, которые вам нужны в запросе. Если не указано иное, могут быть возвращены все атрибуты для объектов (за исключением сконструированных атрибутов), а объект AD может иметь МНОГО атрибутов.
Полезная нагрузка 3 МБ на самом деле интересна, поскольку, если у вас есть Exchange, это будет объем данных, возвращаемых контроллером домена на рабочую станцию, когда кто-то входит в систему. Это атрибуты схемы ADSI. Если вы находитесь в локальной сети, это, вероятно, не заметно, но если у вас есть удаленные клиенты и ограниченная пропускная способность сети, ежедневная загрузка атрибутов схемы ADSI может быть очень заметной.
Дополнительная информация о загрузке кэша схемы ADSI:
Когда пользователь входит на рабочую станцию, рабочая станция проверяет, не были ли загружены атрибуты схемы ADSI, или атрибут modifyTimestamp, сохраненный в реестре, старше, чем тот, который хранится в AD. Реестр выглядит так:
[HKEY_CURRENT_USER\Software\Microsoft\ADs\Providers\LDAP\CN=Aggregate,CN=Schema,CN=Configuration,DC=contoso,DC=com]
"Time"="20141114030449.0Z"
Атрибут AD, который сравнивается:
DN: CN = схема, CN = конфигурация, DC = contoso, DC = com
Атрибут: modifyTimestamp
modifyTimestamp - это «сконструированный» атрибут. AD использует самую последнюю дату whenChanged других атрибутов для определения modifyTimestamp. Вы можете увидеть даты whenChanged, запустив repadmin / showObjMeta CN = Schema, CN = Configuration, DC = contoso, DC = com
Разумный человек мог бы предположить, что пользователь загрузит кеш схемы ADSI один раз, и ему не нужно загружать его снова, потому что схема AD меняется не так часто. Однако ModifyTimestamp не указывает только на то, что схема AD обновляется, потому что клиент может выполнять свои собственные обновления схемы.
Проблема заключается в резервном копировании. Когда резервное копирование состояния системы выполняется на контроллере домена, информация о резервном копировании записывается в атрибут dsaSignature раздела. Это, в свою очередь, приводит к тому, что клиентские рабочие станции и рядовые серверы определяют, что им нужно снова загрузить кэш схемы ADSI. В локальной сети это не заметно, но если у вас есть глобальная сеть с ограниченной пропускной способностью, разделяющая ваших клиентов и контроллеры домена, это может быть очень болезненным.
Еще больше усложняет ситуацию то, что когда был выпущен 2008 R2 SP1, функция modifyTimestamp фактически не работала правильно. Корпорация Майкрософт исправила это исправлением, которое на самом деле могло вызвать снижение производительности кэша схемы ADSI.
В качестве обходного пути можно установить флаг для атрибута dsaSignature в разделе схемы, чтобы указать резервной копии не обновлять атрибут dsaSignature после завершения резервного копирования. Это предотвратит постоянное увеличение параметра modifyTimestamp и остановит загрузку атрибутов схемы ADSI. Обратной стороной является то, что ваше приложение для мониторинга может жаловаться на то, что не выполняется резервное копирование раздела схемы. Другой альтернативой является создание объекта групповой политики, чтобы пометить значение реестра «Время» датой в далеком будущем, но это будет клудж.