Обновления компонентов служб каталогов
Автор: Джастин Тернер, старший инженер по эскалации поддержки с группой Windows
Примечание.
Этот материал создан инженером службы поддержки клиентов Майкрософт и предназначен для опытных администраторов и архитекторов систем, которым нужны более глубокие технические сведения о функциях и решениях в Windows Server 2012 R2, а не обычная информация, доступная в статьях на сайте TechNet. Однако он не был отредактирован согласно требованиям сайта, поэтому некоторые формулировки могут быть не такими выверенными, как на станицах TechNet.
В этом уроке описаны обновления компонентов служб каталогов в Windows Server 2012 R2.
Цели обучения
Объясните следующие новые обновления компонентов служб каталогов:
Объясните следующие новые обновления компонентов служб каталогов:
Функциональные уровни домена и леса
Обзор
В этом разделе приводится краткое введение в изменения уровня функциональности домена и леса.
Новые DFL и FFL
В выпуске существуют новые уровни работы домена и леса:
Функциональный уровень леса: Windows Server 2012 R2
Функциональный уровень домена: Windows Server 2012 R2
Функциональный уровень домена Windows Server 2012 R2 обеспечивает поддержку следующих функций:
Защита на стороне контроллера домена для защищенных пользователей
Защищенные пользователи, проверяющие подлинность в домене Windows Server 2012 R2, больше не могут:
проходить проверку подлинности с помощью проверки подлинности NTLM;
Использование наборов шифров DES или RC4 в предварительной проверки подлинности Kerberos
делегироваться в рамках неограниченного или ограниченного делегирования;
выполнять продление пользовательских билетов (TGT) и использовать их более 4 часов.
Политики проверки подлинности
Новые политики Active Directory на основе леса, которые могут применяться к учетным записям в доменах Windows Server 2012 R2, чтобы управлять тем, откуда размещена учетная запись, может выполнять вход и применять условия контроля доступа для проверки подлинности в службах, работающих в качестве учетной записи.
Приемники команд политик проверки подлинности
Новый объект Active Directory на основе леса, который может создать связь между пользователем, управляемыми службами и учетными записями компьютеров для классификации учетных записей для политик проверки подлинности или изоляции проверки подлинности.
Дополнительные сведения см. в статье "Настройка защищенных учетных записей".
Помимо описанных выше функций, функциональный уровень домена Windows Server 2012 R2 гарантирует, что любой контроллер домена в домене работает под управлением Windows Server 2012 R2. Функциональный уровень работы леса Windows Server 2012 R2 не предоставляет никаких новых функций, но гарантирует, что любой новый домен, созданный в лесу, будет автоматически работать на уровне функциональных возможностей домена Windows Server 2012 R2.
Минимальное применение DFL при создании нового домена
Windows Server 2008 DFL — это минимальный функциональный уровень, поддерживаемый при создании нового домена.
Примечание.
Прекращение использования FRS осуществляется путем удаления возможности установки нового домена с функциональным уровнем домена ниже, чем Windows Server 2008 с диспетчер сервера или с помощью Windows PowerShell.
Снижение функциональных уровней леса и домена
По умолчанию для нового домена и создания нового леса заданы уровни функциональности леса и домена Windows Server 2012 R2, но их можно уменьшить с помощью Windows PowerShell.
Чтобы повысить или снизить функциональный уровень леса с помощью Windows PowerShell, используйте командлет Set-ADForestMode .
Чтобы задать для contoso.com FFL режим Windows Server 2008, выполните следующие действия.
Set-ADForestMode -ForestMode Windows2008Forest -Identity contoso.com
Чтобы повысить или снизить функциональный уровень домена с помощью Windows PowerShell, используйте командлет Set-ADDomainMode.
Чтобы задать для contoso.com DFL режим Windows Server 2008, выполните следующие действия.
Set-ADDomainMode -DomainMode Windows2008Domain -Identity contoso.com
Продвижение контроллера домена под управлением Windows Server 2012 R2 в качестве дополнительной реплики в существующий домен под управлением DFL 2003.
Создание нового домена в существующем лесу
ADPREP
В этом выпуске нет новых операций леса или домена.
Эти LDF-файлы содержат изменения схемы для службы регистрации устройств.
Sch59
Sch61
Sch62
Sch63
Sch64
Sch65
Sch67
Рабочие папки:
- Sch66
MSODS:
- Sch60
Политики проверки подлинности и силосы
Sch68
Sch69
Нерекомендуция NTFRS
Обзор
FRS не рекомендуется использовать в Windows Server 2012 R2. Прекращение использования FRS осуществляется путем применения минимального уровня функциональности домена (DFL) Windows Server 2008. Это принудительное применение присутствует только в том случае, если новый домен создается с помощью диспетчер сервера или Windows PowerShell.
Для указания функционального уровня домена используйте параметр -DomainMode с командлетами Install-ADDSForest или Install-ADDSDomain. Поддерживаемые значения для этого параметра могут быть допустимым целым числом или соответствующим перечисленным строковым значением. Например, чтобы задать для уровня режима домена значение Windows Server 2008 R2, можно указать значение 4 или Win2008R2. При выполнении этих командлетов из Server 2012 R2 допустимые значения включают в себя windows Server 2008 (3, Win2008) Windows Server 2008 R2 (4, Win2008R2) Windows Server 2012 (5, Win2012) и Windows Server 2012 R2 (6, Win2012R2). Функциональный уровень домена не может быть ниже, чем уровень функциональности леса, но он может быть выше. Так как FRS устарел в этом выпуске, Windows Server 2003 (2, Win2003) не является распознаваемым параметром с этими командлетами при выполнении из Windows Server 2012 R2.
Изменения оптимизатора запросов LDAP
Обзор
Алгоритм оптимизатора запросов LDAP был переоценлен и оптимизирован. Результатом является улучшение производительности в эффективности поиска LDAP и времени поиска LDAP сложных запросов.
Примечание.
От разработчика:улучшения производительности поиска путем улучшения сопоставления из запроса LDAP к запросу ESE. Фильтры LDAP, превышающие определенный уровень сложности, препятствуют выбору оптимизированного индекса, что приводит к резкому снижению производительности (1000x или более). Это изменение изменяет способ выбора индексов для запросов LDAP, чтобы избежать этой проблемы.
Примечание.
Полный ремонт алгоритма оптимизатора запросов LDAP, в результате чего:
- Более быстрое время поиска
- Повышение эффективности позволяет контроллерам доменам делать больше
- Меньше вызовов поддержки в отношении проблем с производительностью AD
- Назад, перенесенное в Windows Server 2008 R2 (КБ 2862304)
Общие сведения
Возможность поиска Active Directory — это базовая служба, предоставляемая контроллерами домена. Другие службы и бизнес-приложения зависят от поиска Active Directory. Бизнес-операции могут прекратить работу, если эта функция недоступна. В качестве основной и активно используемой службы контроллеры домена эффективно обрабатывают трафик поиска LDAP. Алгоритм оптимизатора запросов LDAP пытается сделать поиск LDAP эффективным, сопоставляя фильтры поиска LDAP с результирующий набор, который можно удовлетворить с помощью записей, уже индексированных в базе данных. Этот алгоритм был переоценлен и оптимизирован. Результатом является улучшение производительности в эффективности поиска LDAP и времени поиска LDAP сложных запросов.
Сведения об изменении
Поиск LDAP содержит следующее:
Расположение (голова NC, подразделение, объект) в иерархии для начала поиска
Фильтр поиска
Список атрибутов для возврата
Процесс поиска можно суммировать следующим образом:
По возможности упростите фильтр поиска.
Выберите набор ключей индекса, возвращающий наименьший покрытый набор.
Выполните одно или несколько пересечений ключей индекса, чтобы уменьшить охваченный набор.
Для каждой записи в охваченном наборе оцените выражение фильтра, а также безопасность. Если фильтр оценивается как TRUE, а доступ предоставляется, возвращается эта запись клиенту.
Работа по оптимизации запросов LDAP изменяет шаги 2 и 3, чтобы уменьшить размер охваченного набора. В частности, текущая реализация выбирает повторяющиеся ключи индекса и выполняет избыточные пересечения.
Сравнение старого и нового алгоритма
Цель неэффективного поиска LDAP в этом примере — контроллер домена Windows Server 2012. Поиск завершается примерно в 44 секундах в результате сбоя поиска более эффективного индекса.
adfind -b dc=blue,dc=contoso,dc=com -f "(| (& (|(cn=justintu) (postalcode=80304) (userprincipalname=justintu@blue.contoso.com)) (|(objectclass=person) (cn=justintu)) ) (&(cn=justintu)(objectclass=person)))" -stats >>adfind.txt
Using server: WINSRV-DC1.blue.contoso.com:389
<removed search results>
Statistics
=====
Elapsed Time: 44640 (ms)
Returned 324 entries of 553896 visited - (0.06%)
Used Filter:
( | ( & ( | (cn=justintu) (postalCode=80304) (userPrincipalName=justintu@blue.contoso.com) ) ( | (objectClass=person) (cn=justintu) ) ) ( & (cn=justintu) (objectClass=person) ) )
Used Indices:
DNT_index:516615:N
Pages Referenced : 4619650
Pages Read From Disk : 973
Pages Pre-read From Disk : 180898
Pages Dirtied : 0
Pages Re-Dirtied : 0
Log Records Generated : 0
Log Record Bytes Generated: 0
Пример результатов с помощью нового алгоритма
В этом примере повторяется тот же поиск, что и выше, но предназначен контроллер домена Windows Server 2012 R2. Тот же поиск завершается менее чем за секунду из-за улучшений алгоритма оптимизатора запросов LDAP.
adfind -b dc=blue,dc=contoso,dc=com -f "(| (& (|(cn=justintu) (postalcode=80304) (userprincipalname=dhunt@blue.contoso.com)) (|(objectclass=person) (cn=justintu)) ) (&(cn=justintu)(objectclass=person)))" -stats >>adfindBLUE.txt
Using server: winblueDC1.blue.contoso.com:389
.<removed search results>
Statistics
=====
Elapsed Time: 672 (ms)
Returned 324 entries of 648 visited - (50.00%)
Used Filter:
( | ( & ( | (cn=justintu) (postalCode=80304) (userPrincipalName=justintu@blue.contoso.com) ) ( | (objectClass=person) (cn=justintu) ) ) ( & (cn=justintu) (objectClass=person) ) )
Used Indices:
idx_userPrincipalName:648:N
idx_postalCode:323:N
idx_cn:1:N
Pages Referenced : 15350
Pages Read From Disk : 176
Pages Pre-read From Disk : 2
Pages Dirtied : 0
Pages Re-Dirtied : 0
Log Records Generated : 0
Log Record Bytes Generated: 0
Если не удается оптимизировать дерево, выполните следующие действия.
Например, выражение в дереве было не индексировано столбцом
Запись списка индексов, которые препятствуют оптимизации
Предоставляется с помощью трассировки etw и идентификатора события 1644
Включение элемента управления Stats в LDP
Откройте LDP.exe и подключитесь и привязывайтесь к контроллеру домена.
В меню "Параметры" выберите "Элементы управления".
В диалоговом окне "Элементы управления" разверните раскрывающийся меню load Predefined , выберите "Статистика поиска" и нажмите кнопку "ОК".
В меню "Обзор" выберите "Поиск"
В диалоговом окне поиска нажмите кнопку "Параметры ".
Установите флажок "Расширенный" в диалоговом окне "Параметры поиска" и нажмите кнопку "ОК".
Попробуйте использовать LDP для возврата статистики запросов
Выполните следующие действия на контроллере домена или на сервере, присоединенном к домену, с установленными средствами AD DS. Повторите следующие действия, предназначенные для контроллера домена Windows Server 2012 и контроллера домена Windows Server 2012 R2.
Просмотрите статью "Создание более эффективных приложений с поддержкой Microsoft AD" и вернитесь к нему по мере необходимости.
С помощью LDP включите статистику поиска (см. сведения о включении элемента управления статистики в LDP)
Выполните несколько поисковых запросов LDAP и просмотрите статистические сведения в верхней части результатов. Вы повторите тот же поиск в других действиях, чтобы задокументируйте их в текстовом файле блокнота.
Выполните поиск LDAP, который оптимизатор запросов должен иметь возможность оптимизировать из-за индексов атрибутов.
Попытайтесь создать поиск, который занимает много времени (возможно, потребуется увеличить параметр ограничения времени, чтобы поиск не истекло).
Дополнительные ресурсы
Что такое поиск Active Directory?
Как работает поиск Active Directory
Создание более эффективных приложений с поддержкой Microsoft Active Directory
951581 запросы LDAP выполняются медленнее, чем ожидалось, в службе каталогов AD или LDS/ADAM и идентификаторе события 1644 может быть зарегистрировано
Улучшения, связанные с событием 1644
Обзор
Это обновление добавляет дополнительную статистику результатов поиска LDAP в идентификатор события 1644, чтобы помочь в устранении неполадок. Кроме того, существует новое значение реестра, которое можно использовать для включения ведения журнала на пороговое значение на основе времени. Эти улучшения были доступны в Windows Server 2012 и Windows Server 2008 R2 с пакетом обновления 1 (SP1) через 2800945 базы знаний и будут доступны для Windows Server 2008 с пакетом обновления 2 (SP2).
Примечание.
- Дополнительные статистические данные поиска LDAP добавляются в идентификатор события 1644, чтобы помочь в устранении неполадок с неэффективными или дорогостоящими поисками LDAP
- Теперь можно указать пороговое значение времени поиска (например. Событие журнала 1644 для поиска занимает больше 100 мс) вместо указания значений пороговых значений результатов для дорогостоящих и неэффективных результатов поиска
Общие сведения
При устранении неполадок с производительностью Active Directory становится очевидно, что действия поиска LDAP могут способствовать проблеме. Вы решили включить ведение журнала, чтобы вы могли видеть дорогостоящие или неэффективные запросы LDAP, обработанные контроллером домена. Чтобы включить ведение журнала, необходимо задать значение диагностика инженерии полей и при необходимости указать дорогие или неэффективные значения пороговых значений результатов поиска. После включения уровня ведения журнала "Инженерия полей" значение 5, любой поиск, соответствующий этим критериям, регистрируется в журнале событий служб каталогов с идентификатором события 1644.
Событие содержит следующее:
IP-адрес клиента и порт
Начальный узел
Фильтр
Область поиска
Выбор атрибутов
Серверные элементы управления
Посещаемые записи
Возвращенные записи
Однако ключевые данные отсутствуют в событии, например время, затраченное на операцию поиска, и то, что (если таковой) использовался.
Дополнительная статистика поиска, добавленная в событие 1644
Используемые индексы
Ссылки на страницы
Чтение страниц с диска
Предварительно прочитанные страницы с диска
Изменены чистые страницы
Измененные грязные страницы
Время поиска
Атрибуты, предотвращающие оптимизацию
Новое значение порогового значения на основе времени для ведения журнала события 1644
Вместо указания значений пороговых значений результатов поиска дорогого и неэффективного поиска можно указать пороговое значение времени поиска. Если вы хотите записать все результаты поиска, которые заняли 50 мс или больше, укажите 50 десятичных или 32 шестнадцатеричных значений (в дополнение к настройке значения "Проектирование полей").
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"Search Time Threshold (msecs)"=dword:00000032
Сравнение старого и нового идентификатора события 1644
OLD
Создать...
Попробуйте использовать журнал событий для возврата статистики запросов.
Повторите следующие действия, предназначенные для контроллера домена Windows Server 2012 и контроллера домена Windows Server 2012 R2. Просмотрите идентификатор события 1644s на обоих контроллерах домена после каждого поиска.
Используя regedit, включите ведение журнала событий 1644 с помощью порогового значения на основе времени в контроллере домена Windows Server 2012 R2 и старом методе контроллера домена Windows Server 2012.
Выполните несколько поисковых запросов LDAP, превышающих пороговое значение, и просмотрите статистические сведения в верхней части результатов. Используйте запросы LDAP, которые вы задокументировали ранее, и повторите те же поиски.
Выполните поиск LDAP, который оптимизатор запросов не может оптимизировать, так как один или несколько атрибутов не индексированы.
Улучшение пропускной способности репликации Active Directory
Обзор
Репликация AD использует RPC для транспорта репликации. По умолчанию RPC использует буфер передачи 8K и размер пакета размером 5K. Это имеет чистый эффект, когда экземпляр отправки будет передавать три пакета (примерно 15 КБ данных), а затем необходимо ждать сетевого кругового пути перед отправкой больше. Предположим, что время круглого обхода составляет 3 мс, максимальная пропускная способность составляет около 40 Мб/с, даже в сетях с 10 Гбит/с или 10 Гбит/с.
Примечание.
Это обновление настраивает максимальную пропускную способность репликации AD с 40 МБ до около 600 Мбит/с.
- Это увеличивает размер буфера отправки RPC, что уменьшает количество обходных путей сети
Эффект будет наиболее заметным для высокой скорости, высокой задержки сети.
Это обновление увеличивает максимальную пропускную способность до около 600 Мбит/с, изменив размер буфера отправки RPC с 8K до 256 КБ. Это изменение позволяет увеличить размер окна TCP за пределами 8K, уменьшая количество обходных путей сети.
Примечание.
Для изменения этого поведения нет настраиваемых параметров.