Понимание трафика LDAP с ActiveDirectory
Просматривая трафик LDAP через Wireshark, мне было любопытно понять диалог между клиентом Windows и Active Directory. Каждый разговор будет варьироваться до менее 80 Кбайт. Но бывают случаи, когда разговор будет размером 2,5-3 МБ. Может ли кто-нибудь объяснить типы запросов, которые запрашиваются в AD от клиента Windows, и, возможно, различные размеры пакетов, которыми обмениваются? У меня есть захваты пакета с данными полезной нагрузки, но я не знаю, как их прочитать. Есть один способ, которым я знаю, чтобы начать разговор, это с помощью команды "gpupdate /force". Я хотел бы также узнать, какая другая внутренняя обработка в Windows инициирует запросы?
2 ответа
Active Directory является необычным среди каталогов LDAP в том смысле, что весьма часто имеют очень большие полезные нагрузки. На самом деле, наибольшая полезная нагрузка, которую вы можете отправить, составляет 12 Мбайт. Это кажется невероятно большим, но вы идете.
На стороне ввода возможно, что кто-то может отправить запрос типа (|(samAccountName=jsmith)(samAccountName=jdoe)(...)(samAccountName=zsmith)) и указать отдельные символы подстановки или сделать их вместе.
Что касается вывода, то одной из распространенных причин больших полезных нагрузок является пейджинг. Если у вас есть запрос, который возвращает несколько результатов, ответ может быть огромным. В AD есть встроенная поддержка подкачки, и это довольно легко сделать, поэтому один и тот же запрос для всех объектов может вернуть ГБ ответа.
Другой сценарий не указывает фактические атрибуты, которые вам нужны в запросе. Если не указано, все атрибуты для объектов могут быть возвращены (кроме созданных атрибутов), и объект AD может иметь МНОЖЕСТВО атрибутов.
Полезная нагрузка в 3 МБ на самом деле интересна, так как если у вас есть Exchange, это будет объем данных, возвращаемых DC на рабочую станцию, когда кто-то входит в систему. Это атрибуты схемы 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= Схема,CN= Конфигурация,DC=contoso,DC=com
Разумный человек предположил бы, что пользователь загружает кэш схемы ADSI один раз, и ему не нужно загружать его снова, потому что схема AD меняется не так часто. Тем не менее, modifyTimestamp не только указывает, когда схема AD обновляется, потому что клиент мог выполнить свои собственные обновления схемы.
Где это становится проблемой, это резервные копии. Когда резервное копирование состояния системы выполняется на контроллере домена, информация о резервном копировании записывается в атрибуте dsaSignature в разделе. Это, в свою очередь, приводит к тому, что клиентские рабочие станции и рядовые серверы определяют, что им необходимо снова загрузить кэш схемы ADSI. В локальной сети это не заметно, но если у вас есть глобальная сеть с ограниченной пропускной способностью, разделяющая ваших клиентов и контроллеры домена, это может быть очень болезненным.
Чтобы еще больше усложнить ситуацию, когда был выпущен 2008 R2 SP1, функция modifyTimestamp фактически работала некорректно. Корпорация Майкрософт исправила это с помощью исправления, которое может фактически привести к снижению производительности кэша схемы ADSI.
В качестве обходного пути можно установить флаг для атрибута dsaSignature в разделе схемы, чтобы указать резервной копии не обновлять атрибут dsaSignature после завершения резервного копирования. Это предотвратит непрерывное увеличение modifyTimestamp и остановит загрузку атрибутов схемы ADSI. Недостатком является то, что ваше приложение мониторинга может жаловаться на то, что раздел схемы не резервируется. Другая альтернатива - вы можете создать объект групповой политики, чтобы пометить значение реестра "Время" на дату в далеком будущем, но это будет клугом.
@грег
У меня очень похожая ситуация с удаленным сайтом с ограниченной пропускной способностью сети. У меня есть ок. 3000 конечных точек с небольшим обратным соединением с локальными контроллерами домена. Пропускная способность составляет ок. 60 Мбит/с. Мы заметили, что когда мы запускаем обновление схемы или подготовку домена/леса, это приводит к тому, что эти рабочие станции полностью насыщают это соединение вызовами ldap. Первый случай произошел во время обновления Exchange CU, и CU потребовал обновления схемы. Второй случай произошел, когда мы добавили в среду первый контроллер домена сервера 2019, и потребовалась подготовка домена/леса. Мы не можем понять, что именно загружают эти рабочие станции во время ограничения пропускной способности.
Требуется ли на рабочих станциях загрузка локальной копии схемы? Требуют ли они загрузки копии инструкций домена\леса при внесении изменений?