. Причина, по которой следует отдавать предпочтение протоколу Kerberos в Windows 2000 Active Directory (AD) и более новых версиях — не только свойственный этой технологии более высокий уровень безопасности, но и более эффективный метод проверки подлинности. Каждая проверка по протоколу NTLM уникальна, даже при повторном применении к одному и тому же ресурсу по одному и тому же удостоверению. Kerberos предоставляет ресурсу с данным удостоверением многоразовый билет на доступ, так что повторная аутентификация не требует взаимодействия с сервером проверки подлинности или контроллером домена (DC). NTLM — более дорогостоящий и менее безопасный протокол.

Важно знать, когда произошел сбой в проверке подлинности, обусловленный ограничениями со стороны ресурсов и избыточным объемом операций аутентификации по протоколу NTLM. В данной статье речь идет о том, каким образом установить наличие такой проблемы в своей среде и как ее устранить.

Общие пояснения

Ограничения со стороны ресурсов могут возникать при запросе проверки подлинности по протоколу NTLM с компьютера Windows для некоторого пользователя. На рисунке показана обычная процедура проверки подлинности по протоколу NTLM между доменами. Те, кто знаком с архитектурой Windows, знают, что за обработку запросов проверки подлинности отвечает процесс Local Security Authority Subsystem (lsass.exe). Это верно для всех версий и ролей системы Windows. Внутри lsass.exe существуют потоки, выполняющие работу по исполнению кода. Для проверки подлинности по протоколу NTLM существует ограничение на число рабочих потоков, выполняемых единовременно при обработке задания. Заводские установки по умолчанию разрешают выполнение одного потока для рядового члена домена и двух потоков для контроллера домена (DC). На рядовом компьютере домена рабочий поток NTLM используется для отправки запроса на DC, а на DC — для подготовки ответа. Таким образом, в типовой транзакции участвует как минимум два компьютера, которые могут ощущать имеющееся ограничение. Во время единичной транзакции проверки подлинности между рядовым компьютером домена и контроллером этого домена рабочий поток клиента находится в состоянии ожидания до получения ответа от DC.

 

Стандартная процедура проверки подлинности по протоколу NTLM
Рисунок. Стандартная процедура проверки подлинности по протоколу NTLM

Если пользователь запрашивает проверку подлинности от доверенного домена, то в транзакцию вовлекается еще один DC. В этом случае в состоянии ожидания ответа от доверенного DC находится исходный клиент и его DC.

Сам рабочий поток транзакции NTLM выполняется очень быстро. Скорость становится проблемой только при возникновении большого числа одновременных запросов проверки подлинности или когда многие транзакции осуществляются с участием доверенных DC других доменов. Добавим сюда сервер, генерирующий большое число запросов проверки подлинности по протоколу NTLM для своих пользователей, и возникает проблема.

Параметр, ограничивающий число рабочих потоков проверки подлинности по протоколу NTLM, носит название MaxConcurrentApi (тип данных REG_DWORD). Установку этого параметра можно выполнить в разделе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters. Вступление в силу новой установки требует перезапуска службы Netlogon.

Параметр MaxConcurrentApi реализует код Windows, определяющий создание дополнительных рабочих потоков обработки новых запросов проверки подлинности по протоколу NTLM. При отсутствии рабочего потока обработки запроса на запрашивающем клиенте (например, удаленном компьютере) может истечь время ожидания, наступить состояние отсутствия ответа либо пользователю может быть выдано сообщение об отказе в доступе. Эта неоднозначность затрудняет определение основной причины.

Для всех версий Windows заводская установка по умолчанию для MaxConcurrentApi — 1 для рядового сервера и 2 для DC. В Windows Server 2003 и Windows Server 2008 установку MaxConcurrentApi можно увеличивать до 10. Server 2008 R2 при аналогичной установке по умолчанию допускает увеличение максимума до 150. Для исходной системы Server 2008 (не R2) можно установить исправление (см. статью Microsoft «You are intermittently prompted for credentials or experience time-outs when you connect to Authenticated Services» на support.microsoft.com/kb/975363), которое позволит увеличить максимальное значение до 150. Таким образом, мы рассмотрели механический аспект ограничения. Теперь перейдем к определению проблемы.

Поиск и устранение проблемы

Самое трудное в определении узких мест, обусловленных ограничениями проверки подлинности, состоит в отсутствии соответствующих событий в журналах компьютеров. Все ошибки возникают внутри приложения, инициировавшего запрос на проверку подлинности. В зависимости от способа обработки ошибки данным приложением, информация может оказаться недостаточной для определения ограничений со стороны NTLM.

Поскольку события отсутствуют и информации об ошибке может не оказаться, приходится искать другие симптомы. Следует иметь в виду, что проблема может возникнуть с любым приложением, использующим протокол NTLM. Распространенные виновники — старые бизнес-приложения, использующие NTLM, поскольку в то время это был общепринятый стандарт.

Лучший способ определить, достигнут ли порог ограничений NTLM, — установить, являются ли отказы результатом избыточного объема запросов. Если отказы происходят в самые напряженные часы работы (например, в понедельник утром, когда начинается рабочий день), это может служить указанием — прямым, но недостаточным для окончательного вывода.

Воспользуйтесь журналом монитора производительности для службы Netlogon для анализа вызывающего сомнения сервера во время его интенсивной загрузки. Чтобы не упустить ни одного потенциального узкого места, это необходимо сделать для сервера ресурсов, при обращении к которым у пользователей возникают проблемы, а также для контроллеров домена (DC). В журнале производительности (.blg) необходимо обратить внимание на следующее (экран 1):

  • Semaphore Holders (держатели семафора) со значением, равным текущей установке MaxConcurrentApi в реестре;
  • Semaphore Timeouts (время ожидания семафора) с любым значением больше 0;
  • Semaphore Waiters (ожидающие семафора) с любым значением больше 0.

 

Полезная информация в журнале производительности
Экран 1. Полезная информация в журнале производительности

Ненулевые значения времени ожидания или ожидающих объектов семафора указывают на наличие узкого места проверки подлинности по протоколу NTLM.

Ранее уже говорилось о том, что вовлечение доверенных DC в транзакцию может увеличивать задержку и вызывать истечение времени ожидания. Определить, кроется ли причина в доверенных доменах, помогут те же данные о производительности в окне отчета (экран 2), где по каждому домену приведены четкие цифры.

 

Данные о производительности в окне отчета
Экран 2. Данные о производительности в окне отчета

Определение узкого места — лишь первый шаг. На следующем этапе необходимо устранить проблемы производительности, закрывающие пользователям доступ к службам, необходимым для выполнения работы. Самое простое решение — увеличить значение параметра MaxConcurrentApi на всех серверах, участвующих в транзакциях, до величины, позволяющей справляться с нагрузкой. Для Windows Server 2003 или 2008 это значение следует повысить до 10, а в случае Server 2008 R2 (или если установлено исправление) — до более высокого. После этого необходимо перезапустить службу Netlogon на всех участвующих серверах.

Если увеличение значения параметра MaxConcurrentApi не решает проблему, необходимо углубить анализ и выяснить, какие компьютеры и учетные записи пользователей посылают запросы проверки подлинности. Ответ на этот вопрос можно найти в журнале отладки службы Netlogon. Для получения более подробной информации прочтите статью Microsoft «Enabling debug logging for the Net Logon service» на support.microsoft.com/kb/109626. По умолчанию этот журнал не настроен на расширенную регистрацию, но фиксирование дополнительной информации включить несложно, и эти данные будут содержать полезные временные отметки.

В журнале отладки службы Netlogon, как и в других местах, необходимо искать следующее.

  • NlpUserValidateHigher: Can’t allocate Client API slot. Эта текстовая запись в журнале Netlogon указывает на то, что в компьютере есть ожидающие запросы проверки подлинности по протоколу NTLM, но уже достигнут порог ограничения числа рабочих процессов. Предыдущие записи укажут вам имя пользователя и имя компьютера, откуда исходит запрос.
  • NlAllocateClientApi timed out. Эта текстовая запись в журнале Netlogon говорит о том, что один из клиентов, ожидавших проверки подлинности, отказался от дальнейшего ожидания по истечении 45 секунд. Появление этой записи означает, что пользователь соответствующего компьютера получил предложение ввести учетные данные, код ошибки или сообщение о неопределенном ожидании.
  • Нулевая запись. Нулевая запись в журнале Netlogon указывает на то, что унаследованный клиент в сети посылает запросы проверки подлинности по протоколу NTLM для пользователя домена, опуская информацию о домене этого пользователя, поэтому вместо записи ‘домен\пользователь’ отображается ‘(null)\пользователь’. В Windows 2003 это может приводить к избыточному использованию ресурсов, задействованных в проверке подлинности, и, следовательно, к перерастанию потенциальной проблемы в реальную. Для решения этой проблемы выключите посылку запросов отклика (ping), задав соответствующую установку параметра Neverping, как описано в статье Microsoft «The Lsass.exe process may stop responding if you have many external trusts on an Active Directory domain controller» (support.microsoft.com/kb/923241). Отметим, что для Server 2008 и более новых версий этой проблемы не существует.
  • Repeat offenders. Часто повторные попытки проверки подлинности (записи, начинающиеся с SamLogon), исходящие от одного и того же пользователя и компьютера, появляющиеся в журнале Netlogon, могут указывать на вредоносное или неэффективное приложение.
  • Kerberos PAC validation. Как ни странно, система безопасности Kerberos, реализованная в Netlogon, использует те же рабочие потоки, которые являются узким местом проверки подлинности по протоколу NTLM. Отражается это в событии, которое фигурирует в системном журнале событий под номером 7 с полем источника Kerberos. При наличии большого количества таких событий, а также если наблюдаются перемежающиеся перебои в выполнении запросов проверки подлинности пользователей, попробуйте временно отключить эту дополнительную функцию безопасности, пока не будут добавлены дополнительные серверы для обработки нагрузки. Отключать эту функцию навсегда не рекомендуется. Кроме того, это не вариант для Exchange Server или службы пула приложений IIS, поскольку для них отключение данной функции невозможно. Для других случаев в статье Microsoft «You experience a delay in the userauthentication process when you run a high-volume server program on a domain member in Windows 2000 or Windows Server 2003» (support.microsoft.com/kb/906736) описано, как это сделать. Если наличие узких мест, обусловленных ограничениями NTLM, подтверждается, то наилучшим решением было бы использование Kerberos вместо NTLM. Однако старые приложения вряд ли поддерживают Kerberos, что исключает такую возможность. Это может привести к необходимости ставить на обсуждение вопросы взвешивания затрат на приобретение нового программного обеспечения вместо обеспечения безопасности и расширяемости. В конечном счете перебои в работе и низкая производительность окажутся веским аргументом в пользу безопасности и расширяемости.

Тенденции

Эта тема достойна внимания ИТ-специалистов ввиду существования двух основных тенденций: ориентации технологий на потребителя и появления нового высокопроизводительного оборудования и программного обеспечения. Другими словами, пользователи хотят с неуправляемых или унаследованных клиентов подключаться к действительно быстрым службам в «облаке». Ваше дело — обеспечить, чтобы для них все это «просто работало», поэтому тщательно проанализируйте свою сетевую среду и не позволяйте унаследованным средствам проверки подлинности создавать вам проблемы.

Тим Спрингстон (tim.springston@microsoft.com) — старший инженер службы технической поддержки подразделения Commercial Technical Support в Microsoft, отвечает за систему безопасности и авторизацию