J3qx

information archive

LDAP Policy в Active Directory

Posted by j3qx на Октябрь 9, 2012

LDAP Policy в Active Directory

Привет.

Вместо предисловия

Данная статья – про Active Directory. Поэтому предполагается, что Вы знаете, что такое CN, DN, RDN, КВН, LDAP, DC, GC, не путаете сайты Active Directory и то, что в IE, а также понимаете, что браузер – это вначале ADSI и только после – всё остальное.

Не надо сразу бежать и применять то, что тут написано, на практике. Ряд приведённых настроек при быстром и решительном применении могут превратить процесс тюнинга службы каталогов в доработку резюме на сайте хехе.ру. Лучше подумайте, спланируйте, продумайте последовательное применение и аккуратно, понемногу проводите изменения.

Вперёд.

Что такое политики LDAP в Active Directory и зачем они нужны

Под термином “политики” в связи с Active Directory обычно имеются в виду групповые политики – мощное и легко расширяемое средство для централизованного управления многими настройками ОС и приложений.

Однако, у этого термина есть и другие варианты применения – например, благодаря объектам, которые относятся к классу queryPolicy, существует возможность тонкой настройки работы контроллеров домена (DC) и серверов глобального каталога (GC), а также ощутимого повышения скорости, надёжности и безопасности их функционирования. Давайте разберёмся что это, и как это можно (и нужно) эффективно использовать.

Базовые операции с политиками

ЦЕЛЬ

Сам класс queryPolicy представляет из себя объект, содержащий в себе “пачку” настроек, которые читаются LDAP-хранилищами. Пачка реализована как многострочные атрибуты lDAPAdminLimits и lDAPIPDenyList, которые можно редактировать вручную, прямо в объекте, а можно “по-красивому”, через утилиту dsmgmt (ранее – через ntdsutil).

Утилита dsmgmt идеологически “более правильная” по причине, что ntdsutil изначально предназначался для работы именно с Active Directory, а dsmgmt позиционируется как более общее решение, которое должно работать со всеми службами LDAP-каталогов, включая AD LDS. А вообще, можно это всё править и через оснастку ADSI Editor. И через вкладку “Attributes” у объекта queryPolicy. И через древнюю утилиту ldp.exe. Особой разницы нет – LDAP – достаточно демократичная штука.

Объекты этого класса находятся в специальном контейнере, который расположен в разделе леса Configuration по DN-адресу
CN=Query-Policies,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=далее-контекст-Вашего-леса-Active-Directory
Вы можете увидеть их глазами, если откроете стандартную оснастку Active Directory Sites & Services и выберете в верхнем меню пункт View -> Show Services Node.

Примечание: Достаточно логично, что эти объекты находятся в разделе configuration, который реплицируется на все контроллеры в лесу. Ведь данные политики применяются не только на контроллеры конкретного домена, а и на GC, и на сайты, которые привязки к доменам не имеют.

Изначально в Active Directory создан единственный объект LDAP-политик с именем Default Query Policy, который содержит настройки “по умолчанию”. Его лучше не трогать. Никогда. Далее мы поговорим о том, как эти объекты применяются на свою “целевую аудиторию” (DC/GC) и создаются.

СХЕМА ПРИМЕНЕНИЯ

Объекты queryPolicy могут привязываться к сайту Active Directory, а могут и (что неочевидно) к конкретному контроллеру. Какая же будет логика применения нескольких политик queryPolicy?

  1. Контроллер домена смотрит раздел леса Configuration, открывает там контейнер Sites, находит себя и в своём дочернем объекте c CN=NTDS Settings и типом nTDSDSA смотрит на атрибут queryPolicyObject. Если там есть DN политики – настройки применяются и обработка прекращается. Т.е. не как в групповой политике, когда результирующая политика представляет собой “сумму наложений” всех политик на объекте, а сразу – раз политику нашёл, то применил и обработку остановил.
  2. Если своей политики у контроллера домена нет, он берёт свой сайт, открывает его дочерний объект с CN=NTDS Settings и типом ntDSSiteSettings, находит там атрибут queryPolicyObject (которого там может и не быть, он опциональный), и, в случае наличия, берёт DN объекта LDAP-политики из него. В этом случае обработка также останавливается.
  3. Если не нашлось ничего – контроллер не унывает и идёт читать дефолтный объект с именем Default Query Policy. Поэтому, если Вы придумали свои новые и отличные настройки – всегда делайте новый объект, а не редактируйте дефолтный, чтобы иметь возможность лёгкого возврата настроек (что-то не работает – удалили ссылку на свой объект, контроллер стал читать дефолтный).

Примечание: Несмотря на одинаковое название – NTDS Settings, у сайта и у DC объект имеет разные типы – Site Settings (nTDSSiteSettings) и Domain Controller Settings (nTDSDSA).

Видите – всё ещё проще, чем в случае с групповыми политиками, где стандартную схему применения модицифируют многочисленные дополнительные инструменты. Теперь перейдём к самим настройкам.

ПАРАМЕТРЫ ФИЛЬТРАЦИИ ДОСТУПА К LDAP

Первое и самое простое – фильтрация доступа к контроллерам. Благодаря политикам LDAP Вы можете выбрать IP-адреса, доступ с которых будет заблокирован. Делается это достаточно просто – в каждом объекте queryPolicy есть атрибут lDAPIPDenyList, в котором можно указать нужное количество блокируемых адресов. Формат атрибута – массив строк, а каждая строка должна выглядеть просто – IPv4 адрес, пробел и маска. Например строка:

172.16.0.0 255.240.0.0

заблокирует все обращения к контроллеру с частных IPv4-адресов сетей класса B.

Примечание: Для IPv6 механизм не реализован. Нигде, включая Windows Server 2008 R2 SP1.

Примечание 2: В устаревшей документации можно встретить утверждение, что данный атрибут работает только для дефолтного объекта LDAP-политик, с CN=Default Query Policy. Это не так – работает и в других.

Думаю, что использование такого параметра вполне очевидно – в случае теоретической доступности контроллера со стороны “ненужных” сетей доступ можно заблокировать. Хотя на данный момент в Window Server 2008 R2 имеется Advanced Firewall, который, в общем-то, сам может это сделать, функционал блокировки адресов присутствует. Во многом по причине того, что когда данный функционал появился (в 1999 году, вместе с рождением Active Directory), встроенного Firewall в Windows Server не было.

Параметры функционирования LDAP

ФОРМАТ

Все параметры LDAP-политик имеют формат вида “Имя=Значение”. То есть если нужно присвоить атрибуту Parameter значение 7, результирующая строка будет Parameter=7.

Не все политики поддерживаются контроллерами всех версий ОС. Поэтому у каждой указано, на каких версиях ОС она применима. Если хотите посмотреть, какое подмножество политик умеет обрабатывать именно Ваша Active Directory – это несложно; запустите ADSI Editor, откройте контекст RootDSE, откройте единственный находящийся в нём объект с CN=Root DSE, и найдите там атрибут с названием supportedLDAPPolicies. В нём, через точку с запятой, будут перечислены политики, применимые в конкретном лесу Active Directory.

У некоторых параметров есть жестко зафиксированные, на уровне программного кода ядер NT 6.0 и старше, максимальные значения. В этом случае я это адресно указываю – мол, в любом случае, что бы Вы не выставили, параметр будет интерпретироваться как такой-то.

ПАРАМЕТР MAXACTIVEQUERIES

Версии ОС на контроллерах, которые обрабатывают: Только Windows 2000 Server; начиная с 2003 параметр игнорируется

Значение по умолчанию: 20

Что указывает: Когда использовался, указывал максимальное количество параллельно работающих операций поиска в LDAP на конкретном DC. По достижению этого числа DC выдавал при попытке “заказать” операцию поиска ошибку ERROR_DS_ADMIN_LIMIT_EXCEEDED. Сейчас не используется, потому что есть более “умная” настройка, ограничивающая количество параллельных операций не для DC, а для ядра процессора.

ПАРАМЕТР INITRECVTIMEOUT

Версии ОС на контроллерах, которые обрабатывают: С Windows 2000 Server по Windows 2008 R2.

Значение по умолчанию: 120

Что указывает: Время в секундах, за которое клиент после подключения (фактически, после bind) должен отправить первый рабочий запрос на LDAP-операцию. Если тайм-аут проходит, а клиент молчит, его отключают.

Модифицируем: В случае использования внешнего ПО, которое любит “подключиться и думать, что сказать для начала”. К такому ПО относится ряд продуктов IBM (Lotus Domino например), а также продуктов Microsoft – тот же ILM 2007 и FIM 2010. Ситуация достаточно проста – если у Вас есть такое ПО, то, возможно, Вам имеет смысл увеличить тайм-аут хотя бы до 240 секунд (я увеличивал в случае с FIM 2010 до 600, это давало плюсы). Это не приведёт к какой-то дополнительной нагрузке на DC, скорее, наоборот – если ПО разработано так, что оно вначале находит ближайший/лучший DC и “цепляется” за него, после где-то у себя в голове ставит галочку “ОК, подключились, теперь будем, если что, запросы кидать”, и далее штатно делает с AD операции, то не имеет смысла держать тайм-аут таким, чтобы он регулярно сбрасывал подключение этого ПО, приводя ситуацию к “странно, вроде подключились, запрос кидать пробую – ошибка. наверное, AD нерабочая…”. Это может привести в хорошем варианте к повторной аутентикации ПО, в плохом – к неработоспособности и достаточно смутным ошибкам. Учитывайте, что существование данного параметра в не-дефолтном значении будет отрабатываться только в хорошо спроектированном ПО, которое работает с LDAP достаточно качественно. Поэтому в общем случае лучше увеличить этот параметр для “доверенного” ПО – пусть подключается и висит, нагрузки от единичных пустых LDAP-сессий нет, а траблшутить Лотус, который вначале подключается и через полчаса лезет почитать, что там интересного в Active Directory, дело очень унылое.

Зафиксируйте для себя, что данный механизм предназначен для защиты от DDoS, а не для воспитательно-карательных мер в отношении легального ПО. Не имеет смысла “наказывать” специфично спроектированное ПО тем, что сбрасывать его сессию.

Но в случае контроллера, работа с которым ведётся исключительно короткими сессиями (на нём не сидит админ с открытой консолью Active Directory Users & Computers весь день, с него лишь периодически “подкачивают” политику клиентские системы), имеет смысл понизить этот тайм-аут в целях своевременного “сброса” непонятных подключений. Нормальные клиенты подключаются и сразу же делают нужные операции. Опыт настройки в различных инсталляциях показал, что снижение до 15 секунд в такой ситуации является вполне эффективным и никак не влияет на применение групповых политик и LDAP-операции клиентов (даже географически удалённых и с медленными каналами связи).

Ещё раз – это ограничение _стартового_ тайм-аута – т.е. ожидания _первой_ операции клиента. Idle timeout рассматривается дальше.

ПАРАМЕТР MAXCONNECTIONS

Версии ОС на контроллерах, которые обрабатывают: С Windows 2000 Server по Windows 2008 R2.

Значение по умолчанию: 5000

Что указывает: Максимально возможное количество одновременных LDAP-подключений на DC. Заметьте – не после ldap connect, не после ldap bind, а вообще, т.е. в случае с обычным DC это будет математическая сумма подключений по портам TCP 389 и TCP 636. Что интересно, при появлении “лишнего” подключения (в дефолтном случае – 5001го) контроллером будет сброшено какое-то из существующих. Критерий сброса в документации не указан, эксперименты показали, что вроде как сбрасывается самое “старое” подключение, однако не всегда – на одной и той же инсталляции DC иногда сходил с ума и начинал дропить без видимой логики выбора.

Модифицируем: Всегда, если думаем о безопасности Active Directory. По сути, данный параметр надо увеличивать хотя бы раз в 10 сразу, потому что иначе атака вида DoS на контроллер домена может быть вполне успешно и оперативно реализована – подключаясь в цикле (даже авторизуясь при этом – кто мешает, читать-то AD могут Authenticated Users, а иногда и Everyone) можно легко “догнать” суммарное количество сессий до лимита, а после, продолжая инициировать подключения, заставить контроллер сбрасывать рабочие сессии. При этом с точки зрения системы DC загружен не будет (процессор не нагружен, память не кончилась, сетевой интерфейс не загружен, очереди диска нет), а легальные клиенты испытают проблемы. Правда, когда легальный клиент переподключится, то он “выбьет” одну из фейковых сессий LDAP и, в зависимости от нагрузки, может успеть сделать что-то полезное, пока его, в свою очередь, не “выбьет” скрипт, генерящий фейковые сессии.

ПАРАМЕТР MAXCONNIDLETIME

Версии ОС на контроллерах, которые обрабатывают: С Windows 2000 Server по Windows 2008 R2.

Значение по умолчанию: 900

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

Модифицируем: В случае наличия ПО, которое постоянно держит открытой подключение на контроллеры домена (тот же Exchange) тайм-аут можно и увеличить, но 15 минут обычно вроде как достаточно. Замечу, что этот тайм-аут сбрасывает только уже аутентицированного клиента. Поэтому в случае, например, “жесткой” привязки Exchange на DC/GC вполне можно этот тайм-аут увеличить – уменьшите количество переподключений. В случае же работы с внешними сервисами (трудно придумать сходу – ну, например, реализуя публично доступный LDAP-каталог (lol)) тайм-аут можно сократить в разы, хоть до 15 секунд – обычно в таких сценариях клиент подключается, делает штучный запрос, и всё – его можно отключать. Надо – ещё раз придёт.

ПАРАМЕТР MAXDATAGRAMRECV

Версии ОС на контроллерах, которые обрабатывают: С Windows 2000 Server по Windows 2008 R2.
Значение по умолчанию: 4096
Что указывает: Максимальный размер датаграммы, которую обрабатывает DC. Т.е. если придёт датаграмма (это которая UDP, как понятно) размером больше указанного, контроллер должен её отбросить
Модифицируем: Не трогаем. Никакого особого КПД найти в ограничении размера UDP-пакета не получится, а раз не получится – то надо взять за правило не трогать параметры без явно подтверждённых на то причин. Есть сценарий, в котором повышение этого размера до 64K может быть позитивным, но он мало относится к теме статьи.

Кстати, ранее (в Windows 2000 Server) это значение было меньше в 4 раза, 1024 байта.

ПАРАМЕТР MAXNOTIFICATIONPERCONN

Версии ОС на контроллерах, которые обрабатывают: С Windows 2000 Server по Windows 2008 R2.
Значение по умолчанию: 5
Что указывает: Максимальное количество стоящих в очереди запросов клиента. Т.е. суть проста – клиент подключается, авторизируется, и делает запрос. Клиенту подтверждают, что запрос начинает выполняться, а клиент уже запрашивает следующий. Формируется очередь LDAP-запросов, а данный параметр ограничивает её. Очередь работает по логике FIFO, а действие этого параметра – обычный tail drop, а клиент получает не подтверждение о постановке запроса в очередь, а ERROR_DS_ADMIN_LIMIT_EXCEEDED
Модифицируем: Очень осторожно. С одной стороны – снижение этого числа может достаточно эффективно ликвидировать возможность хитрого DoS’а – фейковый клиент подключается, подтверждает подлинность и начинает доставать сервер запросами – “хочу всех пользователей, у которых поле X похоже на Y”, специально подбирая запросы по таким полям, которые и индексируются, и содержат наиболее обширные данные. Да и ANR тут только ухудшит ситуацию. Вопрос вообще достаточно тонкий, требует понимания и тюнинга всей системы индексации атрибутов объектов в Active Directory и в отрыве от этого рассматриваться не должен. Но в общих чертах – да, уменьшение этого числа для DC, с которыми не работают сервисы типа Exchange, а только обычные клиенты, может оказаться превентивной мерой для описаных выше специфических атак.

ПАРАМЕТР MAXPOOLTHREADS

Версии ОС на контроллерах, которые обрабатывают: С Windows 2000 Server по Windows 2008 R2.
Значение по умолчанию: 4
Что указывает: Количество потоков на _одном_ логическом процессоре, доступном DC/GC. Это будут как потоки для обслуживания входящих из сети запросов, так и потоки для обработки LDAP-поиска. То есть, говоря проще, если Вы поставите DC/GC в виртуальную машину и дадите этой виртуальной машине 2 процессора, данный параметр ограничит число параллельных потоков выполнения до 2*4=8. Потоков, заметьте, а не процессов.
Модифицируем: Вполне разумно увеличить этот параметр, если у Вас достаточно производительные процессоры. Теоретически можно придумать DoS-атаку, которая выдаст столько запросов (и достаточно “долгоиграющих”), что контроллер запустит их параллельно, и их количество будет достаточно, чтобы “положить” систему. Смотрите и думайте сами, я лишь могу предложить увеличивать этот параметр для систем с быстрыми CPU.

ПАРАМЕТР MAXRECEIVEBUFFER

Версии ОС на контроллерах, которые обрабатывают: С Windows 2000 Server по Windows 2008 R2.
Значение по умолчанию: 10,485,760 (10 МБайт)
Что указывает: Размер буфера для одиночного запроса. Если думаете, что это много, просто вспомните, что запрос – это не обязательно текстовая строчка вида (&(l=Кремль)(|(givenName=Дима)(givenName=Вова))).
Модифицируем: Данный параметр тесно связан с количеством одновременно возможных запросов. По сути, вся его оптимизация – это экономия потенциально выделенной памяти в количестве MaxReceiveBuffer * MaxConnections. Заметьте, память выделяется динамически, поэтому наличие этого буфера в 10МБ и количества подключений в 5000 не говорит о том, что DC/GC попытается выделить 50ГБ под буферизацию LDAP-запросов. Т.е. такое возможно в теории, на практике под каждый запрос сразу 10МБ не выделяется. Лучший вариант – мониторинг Вашей инсталляции Active Directory и, в случае отсутствия запросов подобных размеров, снижение этого числа (которое в реальности сделано с большим запасом). На практике в достаточно больших инсталляциях (несколько тысяч хостов, порядка 20 серверов Exchange) данный параметр, будучи установленым в 1МБ, не вызывал никаких проблем.

Кстати, в своё время (в Windows Server 2003) была ошибка, связаннае с тем, что сервер некорректно выделял память под буфер, если его размер в байтах больше странного числа 10737418. Ошибку давно поправили, лечилась она форсированной установкой буфера в 10485760 байт.
Верхний лимит параметра: 20971520 (в случае попытки выставить параметр выше по факту будет применено это значение).

ПАРАМЕТР MAXPAGESIZE

Версии ОС на контроллерах, которые обрабатывают: С Windows 2000 Server по Windows 2008 R2.
Значение по умолчанию: 1000
Что указывает: Параметр достаточно неочевиден. Суть в том, что это не максимальный размер возвращаемых запросом результатов, а размер одной страницы с этими результатами. Если при поиске будет возвращено большее количество объектов, то они будут возвращаться блоками, которые и называются страницами. Сервер держит эти блоки в RAM пока клиент не заберёт их все либо не сделает unbind.
Модифицируем: В случае, если хорошо понимаем LDAP и то, что этот параметр, по сути, меняет баланс между “сформировать много страниц ответа и отдавать по одной быстро” vs “сформировать мало страниц и отдавать подольше, но реже”. Интересным является тот факт, что “родной” клиент LDAP в Windows всегда делает paged-запросы, поэтому в принципе сломать что-то этим параметром трудно. Учтите, что тут есть строгая зависимость от того, какие запросы делает клиент – т.е. в случае наличия “глупого” ПО, которое делает не-paged запросы, Вы реально можете ему помешать работать. Если такого ПО нет, я бы рекомендовал снизить этот параметр до 100 исключительно по причине того, что очень малое число запросов к AD возвращают более 100 объектов, а выделять лишнюю память для буферизации смысла нет.
Верхний лимит параметра: 20000 (в случае попытки выставить параметр выше по факту будет применено это значение).
Вообще, нужно учитывать достаточно простую логику Microsoft – все ldap-запросы должны быть с поддержкой paging, поэтому не-paged запросы в общем-то являются потенциально unsupported. Подробнее, если Вы разработчик, можно найти в документации на ldap_create_page_control.

ПАРАМЕТР MAXQUERYDURATION

Версии ОС на контроллерах, которые обрабатывают: С Windows 2000 Server по Windows 2008 R2.
Значение по умолчанию: 120
Что указывает: То, что и в названии – максимальное время обработки одиночного запроса. Считается от момента поступления оного, а не от подключения клиента, что логично. Как только время закончится – запрос будет остановлен и клиенту будет возвращена ошибка ERROR_INVALID_PARAMETER error.
Тонкость – это произойдёт только если запрос всё выполняется. Если же он уже выполнен, вернул много результатов и их постранично забирает клиент, то клиента не отключат. Т.е. цель этого механизма – отключать запросы, которые “перегревают” DC, а не стирать через 2 минуты результаты уже готовых, которые сформированы и лежат в буфере.
Модифицируем: Можно реально уменьшить, и сильно. Две минуты на формирование результатов запроса – это надо иметь огромный лес, сложнейший запрос к GC и очень медленный сервер. Если это не так, запрос даже в 10 секунд – сложная в реальности штука. Опять же – измеряйте Вашу реальную ситуацию и модифицируйте настройки в случае необходимости.
Верхний лимит параметра: 1200 (в случае попытки выставить параметр выше по факту будет применено это значение. хотя трудно себе представляю штатный запрос к DC/GC, который в норме выполняется дольше 20 минут).

ПАРАМЕТР MAXRESULTSETSIZE

Версии ОС на контроллерах, которые обрабатывают: С Windows 2000 Server по Windows 2008 R2.
Значение по умолчанию: 262,144
Что указывает: Размер в байтах (в байтах, а не как иногда пишут – “в объектах”), выделяемых на все результаты всех активных сейчас paged-запросов. Т.е. ещё раз – на вообще все, которые на сервере сейчас уже выполнены, и клиенты их забирают. И именно на paged, которые постранично забирают клиенты. Если места на кэширование результатов нового запроса не хватает, то (ключевое) удаляются результаты старого. И если клиент продолжит его забирать, то надо бы его выполнить повторно.
Модифицируем: Лучше всего увеличить этот параметр хотя бы до мегабайта. В крупных инсталляциях хорошо срабатывает увеличение до 16 (число выбрано по причине мониторинга и обнаружения ситуаций, когда в буфере лежало до 10МБ результатов и взято с небольшим запасом). Цель – отсутствие ситуации, когда результаты нового paged-запроса затирают недополученные клиентом результаты более старого paged-запроса.
Кстати, в документации Microsoft есть опечатка – там параметр иногда называется MaxResultSize. Такого параметра нет, можете проверить. Вообще, конечно, параметр логичнее было бы назвать MaxResultSetsSize или какой-нибудь MaxTotalResultSetsSize, но увы.

ПАРАМЕТР MAXTEMPTABLESIZE

Версии ОС на контроллерах, которые обрабатывают: С Windows 2000 Server по Windows 2008 R2.
Значение по умолчанию: 10,000
Что указывает: Достаточно интересный параметр. Суть в следующем. Когда Вы выполняете достаточно сложный запрос, в котором есть логические операции (например, объединения или пересечения множеств), то возникает необходимость в формировании промежуточных таблиц с результатами выборок. В них лежат так называемые candidate object’ы – объекты, часть из которых попадёт в результат. Если размер промежуточной таблицы превзойдёт указанное число записей, то система перестанет обрабатывать запрос пошагово (выбрать множество -> выделить подмножество -> из него выбрать по критерию -> и т.д.) а перейдёт к т.н. direct scan (будет обрабатывать потенциальные объекты по-одному). Вот этот параметр – это максимальный размер такой таблицы для каждого из запросов.
Модифицируем: Подумайте, будут ли у Вас запросы, промежуточные результаты которых будут превышать это число, и, в случае наличия оных, увеличьте этот параметр. И обломайтесь – по факту он не увеличится. Производительность таких запросов серьёзно упадёт и Вы ничего сделать не сможете – в Windows Server 2008 R2 максимальное значение этого параметра как раз 10000. Увы, как ни странно, в Windows Server 2003 это можно было регулировать гибче.
Верхний лимит параметра: 10000 (в случае попытки выставить параметр выше по факту будет применено это значение).

ПАРАМЕТР MAXVALRANGE

Версии ОС на контроллерах, которые обрабатывают: С Windows Server 2003 по Windows 2008 R2.
Значение по умолчанию: 1500
Что указывает: Максимальное число результатов, являющихся полями одного атрибута одного объекта, которые может вернуть один LDAP запрос. В общем-то ключевое, под что параметр заточен – это атрибут members у группы. Политика появилась в Windows Server 2003 вместе с изменениями в репликации multivalued-атрибутов (если помните, именно тогда был убран штатный для Windows 2000 Server конфликт репликации multivalued-атрибутов). Ранее, в Windows 2000 Server, значение было установлено на 1000 и не могло быть изменено штатным способом.
Модифицируем: В случае наличия групп с количеством участников выше 1500 данный параметр целесообразно увеличить соответствующим образом. Хитрый DoS, блокируемый этим параметром, придумать можно, но вот проблемы с отправкой почты на адрес “Все сотрудники” в случае линейного включения всех учетных записей пользователей в группу придумываются ощутимо быстрее. Хотите упростить ситуацию – ставьте сразу на 5000.
Верхний лимит параметра: 5000 (в случае попытки выставить параметр выше по факту будет применено это значение).

ПАРАМЕТР MAXRESULTSETSPERCONN

Версии ОС на контроллерах, которые обрабатывают: С Windows 2008 R2.
Значение по умолчанию: 10
Что указывает: Максимальное число хранимых со стороны сервера результатов поисковых запросов клиента.
Модифицируем: В случае, если у нас очень много параллельных запросов, этот параметр можно увеличить. Фактически, в хостинговых сценариях (например, хостинг Exchange). Кстати, в случае, если Ваш домен был установлен не сразу как Windows 2008 R2, параметр будет равен нулю (что по факту опять-таки превратит его на поддерживающих этот параметр контроллерах в 10).

ПАРАМЕТР MINRESULTSETS

Версии ОС на контроллерах, которые обрабатывают: С Windows 2008 R2.
Значение по умолчанию: 3
Что указывает: Минимальное число параллельных запросов для включения режима оптимизации paged-запросов, доступного в NT 6.1.
Модифицируем: Можно поставить единицу – тогда режим оптимизации будет инициироваться всегда.

Я всё прочитал и поменял все параметры. Что теперь?

Работу искать, я ж предупреждал.

Теперь, если всё продолжает работать, можно измерить производительность того, что мы наделали. Не наоборот. Т.е. после тюнинга LDAP-политик в первую очередь всё должно продолжить функционировать, а во вторую – улучшить какие-либо характеристики.

Надеюсь, что данный материал поможет Вам эффективнее работать с инфраструктурой на базе Active Directory, а также покажет, что в данном сервисе есть достаточно много такого, что гораздо интереснее, чем унылые инструкции про “Next->Next->Finish”.

Техники атаки и защиты LDAP-хранилищ достаточно оригинальны и разнообразны (например, неавторизованный пользователь может заказать априори огромный по количеству результатов запрос, притом запросить, чтобы он (результат запроса) ещё и был отсортирован по неиндексированному атрибуту), поэтому грамотный инженер должен хорошо понимать возможности Active Directory по тюнингу такого функционала.

Удач!

WBR, Ruslan V. Karmanov

 

http://kb.atraining.ru/ldap-policy-active-directory/

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

 
%d такие блоггеры, как: