Ntlmv2 windows server 2003

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

Обычно имя пользователя и пароль, применяемые для аутентификации, вводятся на одном компьютере, а их подлинность проверяет другой. На начальном этапе развития сетей использовалась передача имени и пароля на удаленную систему в открытом виде, однако такой подход быстро был признан небезопасным, поскольку в IP-сетях существует множество способов, позволяющих злоумышленнику перехватить трафик и воспользоваться украденным паролем. В связи с этим разработчики операционных систем отказались от передачи пароля в открытом виде и предложили более защищенные алгоритмы. Например, в семействе Windows реализованы следующие алгоритмы аутентификации: Lan Manager, NT Lan Manager, NT Lan Manager version 2 и Kerberos version 5.

Вначале был LM

Протокол Lan Manager (LM), разработанный Microsoft совместно с IBM, даже в Windows NT был включен только для совместимости с устаревшей операционной системой Windows 95 и клиентами Lan Manager. Данный протокол реализует весьма слабую схему защиты пароля при пересылке по сети и при хранении в кэше системы. Существует множество программ, позволяющих за приемлемое время восстановить из хеша LM или перехваченных откликов исходный пароль. Наиболее известной из них является @stake LC 4 (предыдущее название L0phtCrack, http://www.atstake.com/research/lc/). Появилась даже система моментального взлома паролей NT — система с Web-интерфейсом, которая использует заранее рассчитанные таблицы соответствия значений хешей и паролей для практически моментального восстановления пароля из хеша LM (http://lasecpc13.epfl.ch/ntcrack, http://www.antsight.com/zsl/rainbowcrack/).

Несмотря на недостатки этого протокола, он зачастую используется в сетях с Active Directory. Многие администраторы мотивируют это необходимостью обеспечения «совместимости» с клиентами на основе Windows 9x или просто не уделяют должного внимания применению этого протокола в сети, что приводит к компрометации паролей пользователей и администраторов.

Процесс отказа от LM и перехода на более защищенные протоколы аутентификации в разнородной среде далеко не прост и, как правило, осуществляется в несколько этапов. На первом из них необходимо обновить все операционные системы до соответствующего уровня, т. е. установить на них модули поддержки протоколов NTLMv2. Для этого на операционные системы Windows 9x следует установить клиенты Active Directory Services (ADSC) (http://www.microsoft.com/windows2000/adclients). Операционная система Windows NT 4.0 поддерживает протокол NTLMv2 начиная с четвертого пакета обновлений (Service Pack 4). Но и на систему Windows NT 4.0, функционирующую в среде Active Directory, тоже желательно установить ADSC, поскольку его функции не ограничиваются только поддержкой NTLMv2. Получить более подробную информацию о клиенте ADSC и загрузить эту программу для Windows NT 4.0 можно с сервера Microsoft. Клиент для Windows 9x находится на компакт-диске с дистрибутивом Windows 2000 в папке Clients.

Развертывание клиента ADSC в корпоративной сети — задача, требующая большого количества времени и человеческих ресурсов. Чтобы ускорить процесс, целесообразно автоматизировать его. Для этого можно воспользоваться сценариями входа пользователей в систему, подобными сценарию, приведенному в листинге 1. Применение такого сценария требует создания в общей папке Netlogon контроллера домена (в данном случае используется машина с именем w2ksrv06) папки dsclients, в которой создаются папки w9x и nt4. В них копируются разархивированные дистрибутивы клиентов ADSC для Windows 9x и NT 4.0 соответственно. Чтобы облегчить работу пользователей, следует задействовать локализованную версию ADSC. Русская версия ADSC без проблем устанавливается и работает на англоязычной версии Windows NT 4.0.

Active Directory ds.bat
@echo off
if «%OS%»==»» GoTo :W9x
:NT
if not «%CommonProgramFiles%»==»» GoTo :Eof
if exist %windir%system32ActiveDS.dll GoTo
 :Eof
net use z: /delete /yes
net use z: w2ksrv06
etlogon /yes
z:
ifmember Administrators
if not errorlevel 1 (notepad.exe notadmin.txt
 & goTo :Eof)
notepad.exe z:dsinst.txt
regedit -s z:
t4.reg
cd dsclients
t4
setup /Q
GoTo :Eof
:W9X
if exist %windir%systemActiveDS.dll GoTo :Eof
net use z: w2ksrv06
etlogon /yes
regedit -s z:win98.reg
z:
cd dsclientsw9x
setup /Q
notepad.exe z:dsinst.txt
:Eof

Рассмотрим процесс работы сценария. При регистрации пользователя в системе сценарий по системным переменным определяет версию операционной системы. Поскольку в Windows 9x предопределенная переменная %OS% отсутствует, если значение этой переменной равно пустой строке, управление передается в секцию W9X. Далее сценарий определяет, установлен ли на данной машине клиент ADSC. Для этого выясняется, есть ли в системе файл %windir%systemActiveDS.dll. Если да, то сценарий завершает работу. В противном случае с буквой Z монтируется сетевой диск, содержащий файл для установки клиента, в реестр на основе данных файла win98.reg вносятся необходимые изменения, после чего запускается процесс установки клиента в фоновом режиме.

Желательно объяснить пользователям, что происходит с их системой (поскольку процесс установки ADSC занимает некоторое время и требует перезагрузки). Для этого в файле dsinst.txt, отображаемом в ходе процесса установки, необходимо описать выполняемые действия, попросить дождаться окончания процесса установки, а по его завершении перезагрузить систему. Полезно также предварить процесс установки рассылкой по электронной почте и согласовать возможные задержки с руководством предприятия.

В случае если переменная %OS% определена, выявляется наличие системной переменной %Common

ProgramFiles%. Данная переменная по умолчанию определена в операционных системах начиная с Windows 2000, поэтому в случае ее отсутствия управление передается процедуре установки клиента ADSC для операционной системы Windows NT 4.0.

Установка ADSC на Windows NT 4.0 должна выполняться в контексте безопасности пользователя, обладающего привилегиями администратора. Поэтому в случае если клиент не установлен, проверяется, является ли текущий пользователь членом группы Administrators (для локализированных версий NT необходимо добавить проверку на членство в группе «Администраторы»). Для этого используется утилита ifmember из состава Resource Kit, загрузить которую можно с сервера Microsoft (http://www.microsoft.com/windows2000/techinfo/ reskit/tools/new/ifmember-o.asp). В информации о загружаемом файле отобразится его размер, равный 1,16 Mбайт, однако это ошибка сервера и реальный объем равен 115 Кбайт. После загрузки утилиты ее исполняемый файл необходимо скопировать в папку Netlogon контроллера домена.

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

net localgroup Administrators %username% /delete

Кроме установки программных компонентов, для отключения LM необходимо реализовать поддержку NTLMv2, что достигается путем модификации параметров системного реестра, содержащихся в файлах win98.reg и nt.reg (см. листинг 2).

(win98. reg) 
REGEDIT4
[HKEY_LOCAL_MACHINESystemCurrentControlSet
ControlLSA]
«LMCompatibility»=dword:00000003
(nt.reg)
REGEDIT4
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSet
ControlLsa]
«LMCompatibilityLevel»=dword:00000003
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSet
ControlLsaMSV1_0]
«NtlmMinServerSec»=dword:00080000
«NtlmMinClientSec «=dword:00080000

В Windows 98 используемый протокол аутентификации определяется значением параметра HKEY_LOCAL_MACHINESystemCurrentControlSet ControlLSALMCompatibility, а в Windows NT 4.0 HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ControlLsaLMCompatibilityLevel. Кроме того, в NT 4.0 есть возможность настроить минимальный уровень совместимости для протокола NTLM. Подробнее об этих параметрах и их значениях рассказано в статьях базы знаний Microsoft под номерами Q147706, Q239869.

Отключение LM в Windows 2000

Для отключения поддержки LM в Windows 2000 удобно использовать групповые политики. Для этого параметру Computer Configuration — Windows Settings — Security Settings — Local Policies — Security Options — LAN Manager Authentication Level необходимо присвоить значение не ниже трех (Send NTLMv2 Response Only). После применения этой политики компьютеры перестанут использовать для аутентификации протокол LM.

После того как на всех компьютерах сети будут проделаны необходимые действия, можно отключить поддержку протокола LM на контроллерах домена. Для этого в групповой политике для OU Domain Controllers параметру LAN Manager Authentication Level присваивается значение не ниже четырех (Send NTLMv2 response only
efuse LM). Следует понимать, что после выбора данного значения клиенты, не настроенные на поддержку NTLM, не смогут проходить аутентификацию в домене и, соответственно, описанный выше сценарий развертывания ADSC и настройки NTLM работать не будет. Для того чтобы сохранить возможность автоматизированной настройки клиентов, можно выделить один компьютер, поддерживающий LM, и скопировать в одну из его общих папок сценарий ds.bat и сопутствующие файлы. Тогда после установки операционной системы Windows 98/NT 4.0 достаточно будет запустить сценарий с сервера, после чего начинать работу в домене.

Отключение поддержки LM на контроллерах домена и серверах не означает, что клиенты не будут посылать ответы LM, перехват которых злоумышленником может перевести к компрометации пароля. Например, в случае если злоумышленник работает за машиной Windows 98, он может беспрепятственно установить значение параметра реестра LMCompatibility равным 0, после чего под тем или иным предлогом заставить администратора провести процедуру аутентификации с его рабочей станции. В результате администратор не сумеет войти в систему, однако LM-хеш пароля (точнее, LM-ответ, сгенерированный на основе хеша) будет передан по сети, и злоумышленник сможет его перехватить и восстановить пароль. Об этом следует помнить и не входить в сеть под учетной записью администратора с рабочих станций пользователей.

Кроме того, Windows 9x кэширует пароли пользователей в файлах PWL, имеющих слабую защиту, что тоже может привести к компрометации пароля. В корпоративных системах эту функцию желательно отключить, для чего, согласно рекомендациям статьи Q137826, посредством системной политики или сценария регистрации в сети установить значение параметра реестра HKEY_LOCAL_MACHINESoftware MicrosoftWindowsCurrentVersionPoliciesNetwork DisablePwdCaching равным 1.

И последним этапом является отключение функции создания и хранения хешей LM на котроллерах домена (см. статью Q299656). Для этого на контроллерах домена необходимо установить пакет обновления Windows 2000 SP2 и выше, создать параметр реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ControlLsaNoLMHash и перезагрузить компьютер. Хеши LM будут удаляться из системы по мере смены пользователями своих паролей. Чтобы автоматизировать настройку этого параметра на вновь устанавливаемых контроллерах и серверах домена, можно воспользоваться расширениями набора параметров безопасности для объектов групповой политики (см. «Все и сразу», Windows & .NET Magazine, № 1 за 2003 год) или рекомендациями статьи базы знаний Microsoft 214752. Для этого в файл %windir%infSceregvl.inf необходимо добавить следующие параметры:

Затем требуется зарегистрировать сделанные изменения командой regsvr32 scecli.dll и настроить значение этого параметра в соответствующих объектах групповой политики.

После выполнения описанных процедур клиенты и серверы сети будут осуществлять аутентификацию на основе протокола NTLMv2. Вторая версия протокола NTLMv2, поддерживаемая Windows 9x+ADSC/NT SP4/2000/XP/2003, реализует довольно стойкую к взлому схему сетевой аутентификации и на сегодня рекомендована для использования в процессе аутентификации клиентов 9x/NT. Восстановление алфавитно-цифрового пароля, состоящего из восьми символов, в случае его перехвата на системе, производящей 4 млн. переборов в секунду (16-процессорный кластер на основе Athlon 1,4 ГГц), занимает примерно 21 месяц (http://www.blackhat.com/presentations/win-usa-02/urity-winsec02.ppt).

Затем необходимо настроить аутентификацию системных служб. Работа служб от имени привилегированной учетной LocalSystem существенно увеличивает возможности злоумышленника в случае компрометации этой записи, поэтому рекомендуется запускать службы от имени учетной записи пользователя. Кроме того, некоторые задачи, к примеру шифрование баз данных сервера SQL, невозможно выполнять, не применяя для запуска службы пользовательскую учетную запись. Обычно учетные записи, используемые для запуска служб, имеют высокие привилегии либо на конкретном узле, где работает служба, либо во всем домене. Но, несмотря на это, администраторы зачастую назначают учетным записям пароли, которые не меняются годами и за это время могут быть перехвачены и восстановлены злоумышленниками.

Рекомендуется периодически менять пароли для учетных записей служб, что удобно делать при помощи сценария (см. листинг 3)

Сценарий сначала меняет пароль доменной (или локальной) учетной записи, а затем пароль в параметрах запуска служб. Информация о службах берется из тестового файла (по умолчанию — services.txt). В файле указывается учетная запись, а также службы, запущенные от ее имени. Если таких учетных записей несколько, то информация о них начинается с новой строки. Ниже приведен пример файла конфигурации, меняющего пароли для учетных записей sqlsrv1 и sqlsrv2 в домене Dom, а также пароли для связанных с ними служб SQL Server на компьютерах SqlSrv, Cluster0 и Cluster1.

Domsqlsrv1
SqlSrvMSSQLSERVER
Domsqlsrv2
Cluster0MSSQLSERVER
Cluster1MSSQLSERVER

Еще одна проблема, которую приходится решать администратору при создании надежной системы аутентификации, связана с аутентификацией пользователя в сетевых приложениях. Многие приложения (SQL Server, Internet Information Server, Exchange Server) могут задействовать собственные, иногда более уязвимые механизмы аутентификации. К примеру, пользователь, проходящий аутентификацию на SQL Server, в случае применения метода SQL Server Authentication, пересылает по сети пароль в закодированном виде (перевод в UNICODE и операция XOR со строкой 0xA5). Сервер IIS при использовании метода аутентификации Basic требует от клиентского приложения передавать пароль в открытом виде, просто преобразовав его в кодировку usa-ascii при помощи раскладки BASE64. Очень часто администраторы, для того чтобы защитить свою сеть от распространения сетевых «червей» через анонимный сервер SMTP, включают на нем аутентификацию BASIC, что приводит к появлению в сети незашифрованных паролей. Это существенно облегчает злоумышленнику задачу, поскольку, перехватив закодированный пароль администратора при обращении, например, к серверу IIS или SMTP, он может моментально восстановить его и использовать для доступа к сети.

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

Кроме того, применение NTLM может вызвать проблемы в различных приложениях. Например, если в Web-приложении используется связка IIS + SQL и эти службы расположены на различных компьютерах, а сервер IIS требует задействовать аутентификацию NTLM, для соединения с сервером SQL придется использовать SQL Server Authentication или анонимный доступ, а также применять дополнительные приложения для имперсонации (см. Q248187). Все эти методы далеко не безопасны, а также сложны в реализации и эксплуатации.

Ставка на Kerberos

Для решения данной проблемы используется механизм делегирования аутентификации протокола Kerberos. Общая его идея заключается в том, что, если пользователь успешно аутентифицировался в одной из сетевых служб (к примеру, на сервере IIS), эта служба может работать в сети в контексте безопасности данного пользователя. Применение такого метода возможно, если пользователь прошел аутентификацию на сервере IIS с протоколом Kerberos (поддерживается IIS 5.0 и выше и Internet Explorer 5.0 и выше) и компьютер, на котором установлен IIS, является доверенным для делегирования. Подробное описание процедуры настройки делегированной аутентификации можно найти в статье базы знаний Micorosft Q319723. Причем, даже если IIS не настроен на поддержку метода аутентификации NTLM (NTAuthenticationProviders = Negotiate), в случае сбоя аутентификации по протоколу Kerberos (если, например, клиент обратился к серверу через IP-адрес, а не посредством FQDN) Internet Explorer будет использовать NTLMv2. Кроме того, в статье Q215383 не совсем верно описано применение сценария adsutil.vbs. Значение переменной метaбазы необходимо указывать без кавычек:

cscript adsutil.vbs set w3svc/NTAuthenticationProviders Negotiate,NTLM

В Windows Server 2003 появилась возможность выборочного делегирования и смены протокола аутентификации. При использовании выборочного делегирования появляется возможность указать, к каким службам сервер может обращаться от имени пользователя, что уменьшает возможный ущерб при компрометации сервера. Смена протокола аутентификации позволяет серверу работать от имени пользователя, даже если тот задействовал для первоначальной аутентификации протокол, отличный от Kerberos. Подробнее о расширениях протокола Kerberos в Windows Server 2003 рассказано в статье Жана де Клерка «Windows .NET Server и Kerberos» (Windows & .NET Magazine, 2003, №2).

Схема аутентификации, используемая в протоколе Kerberos v 5, реализованном в Windows 2000/XP/2003, защищена от восстановления пароля лучше, чем протоколы семейства Lan Manager, однако не является абсолютно неуязвимой. Она также подвержена атакам, направленным на взлом пароля после перехвата сессии аутентификации. Существует ряд утилит, собирающих запросы AS-билетов, в которых содержится зашифрованная ключом пользователя метка времени, для дальнейшего восстановления пароля посредством атаки по словарю или полного перебора. Однако, как уже говорилось, Kerberos более устойчив к подобным атакам. Например, для восстановления пароля, состоящего из восьми алфавитно-цифровых символов (a-z, A-Z, 0-9), понадобится непрерывная работа 100 компьютеров, эквивалентных Pentium IV на 1,5 ГГц в течение 247 дней. Но для восстановления пароля длиной шесть символов одному компьютеру Pentium IV на 1,5 ГГц понадобится 6,4 суток (http://www.brd.ie/papers/w2kkrb/feasibility_of_w2k_ kerberos_attack.htm). Таким образом, стойкость механизмов аутентификации целиком зависит от надежности используемых паролей.

Меняем отношение к паролю

Существует пять подмножеств символов, используемых в паролях: A-Z, a-z, 0-9, ~-+ (спецсимволы) и ALT-символы. ALT-символы вводятся путем нажатия кнопки ALT и набора на цифровой клавиатуре номера кода. Подробнее об ALT-символах и их применении можно узнать из Windows 2000 Security Hardening Guide (http://www.microsoft.com/technet/security/prodtech/ Windows/Win2kHG/03OSInstl.asp).

При создании собственных паролей следует учитывать два основных условия:

• пароль должен быть относительно прост для запоминания;
• пароль должен быть сложен для вскрытия.

Первое условие должно уменьшить вероятности потери пароля, в то время как сложность пароля снижает вероятность его компрометации. Рекомендуется использовать пароли длиной не менее восьми символов, содержащих символы как минимум трех из описанных выше пяти подмножеств. Желательно менять пароли не реже чем раз в три месяца.

В Active Directory присутствует ряд настроек, позволяющих регламентировать парольную политику предприятия. Изменяя значения параметров, содержащихся в разделе Computer Configuration — Windows Settings — Security Settings — Account Policies — Password Policy, можно устанавливать минимальную длину пароля, регламент его смены, продолжительность хранения истории паролей, а также включать процедуру проверки сложности пользовательского пароля. При необходимости можно создать свой модуль проверки сложности пользовательских паролей. Структура подобных модулей описана в статье Александра Эпштейна «Фильтры для пароля» (Windows & .NET Magazine/RE №3, 2003), и в статье базы знаний Microsoft Q151082.

Перед внесением изменений в политику паролей нужно создать соответствующий раздел в политике информационной безопасности предприятия. Пользователи сети должны быть ознакомлены с соответствующими пунктами, пройти инструктаж и подписать данный документ. Дополнительно к техническим параметрам паролей в политику безопасности рекомендуется внести следующие пункты:

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

Кроме описанных настроек, рекомендуется периодически проводить аудит надежности аутентификации в сети, причем не ограничиваться пассивным мониторингом сложности паролей, а прослушивать трафик на зеркальном порту коммутатора, подключенного к серверному сегменту при помощи специализированной «хакерской» программы, к примеру Cain & Abel (http://www.oxid.it/). Гарантирую, что за короткое время вы узнаете о стойкости аутентификации в своей сети много интересного.

Можно ли обойтись без пароля

Сложный пароль трудно запомнить и неудобно набирать. Поэтому зачастую использование сложных паролей приводит к тому, что они, несмотря на административные запреты, начинают появляться в самых неожиданных местах — под клавиатурой, на мониторе, на корпусе компьютера.

Значительно более надежными являются методы обеспечения безопасности, основанные на том, чем мы обладаем физически. Один из примеров — использование интеллектуальных пластиковых карт (Smart Card). Но, как показывает практика, применение подобных устройств не только не решает всех проблем, связанных с аутентификацией, но и порождает новые.

Сергей Гордейчик — инструктор учебного центра, MCSE. С ним можно связаться по адресу: Gordey@infosec.ru.

NTLM (NT LAN Manager) – это старый протокол аутентификации Microsoft, который появился еще в Windows NT. Несмотря на то, что еще в Windows 2000 Майкрософт внедрила более безопасный протокол аутентификации Kerberos, NTLM (в основном это NTLMv2) широко используется для аутентификации в Windows сетях до сих пор. В этом статье мы рассмотрим, как отключить протоколы NTLMv1 и NTLMv2, и переключиться на Kerberos в домене Active Directory.

Основные проблемы NTLMv1 – слабое шифрование, хранение хэша пароля в оперативной памяти в службе LSA (можно извлечь пароли из памяти Windows в открытом виде с помощью утилит типа mimikatz и использовать хэш для дальнейших атак с помощью сценариев Pass-The-Hash), отсутствие взаимной проверки подлинности клиента и сервера, что делает вполне реальными атаки перехвата данных и неавторизованного доступа к ресурсам сети (утилиты типа Responder могут перехватывать данные NTLM, передаваемые по сети и использовать их для доступа к сетевым ресурсам) и ряд других уязвимостей.

Часть этих недостатков исправлена в более новой версии NTLMv2, который использует более криптостойкие алгоритмы шифрования и позволяет предотвратить популярные атаки на NTLM. Начиная с Windows 7 / Windows Server 2008 R2 протоколы аутентфикации NTLMv1 и LM по умолчанию отключены.

Аудит событий NTLM аутентификации в домене

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

Для отслеживания учетных записей и приложение, которые используют NTLM аутентификацию, вы можете включить политики аудита на всех компьютерах с помощью GPO. Откройте Default Domain Controller Policy, перейдите в раздел Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options найдите и включите политику Network Security: Restrict NTLM: Audit NTLM authentication in this domain, установив ее значение на Enable all.

Картинка с сайта: winitpro.ru

Аналогичным образом включите следующие политики в Default Domain Policy:

• Network Security: Restrict NTLM: Audit Incoming NTLM Traffic – задайте значение Enable auditing for domain accounts
• Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers: задайте Audit all

Картинка с сайта: winitpro.ru

После включения данных политик события использования NTLM аутентификации записываться в журнал событий Event Viewer в секцию Application and Services Logs-> Microsoft -> Windows -> NTLM -> Operation.

Можно проанализировать события на каждом сервере, или собрать все события в центральный Event Log.

Вам нужно собрать события от Microsoft-Windows-Security-Auditing c Event ID 4624 – An Account was successfully logged on. Обратите внимание на информацию в секции “Detailed Authentication Information”. Если в строке Authentication Package указано NTLM, значит для аутентификации этого пользователя использовался протокол NTLM.

Также, если для аутентификации используется NTLM вместо Kerberos, в журнале появится событие Event ID 4776:

The computer attempted to validate the credentials for an account
Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0

Теперь обратите внимание на значение Package Name (NTLM only). Здесь должно быть указано какой протокол (LM, NTLMv1 или NTLMv2) использовался для аутентификации. Таким образом вам нужно идентифицировать все сервера/приложения, которые используют устаревший протокол.

Картинка с сайта: winitpro.ru

Например, для поиска всех событий аутентификации по NTLMv1 по всем контроллерам домена можно использовать такой PowerShell скрипт:

$ADDCs = Get-ADDomainController -filter * -Server dc01.winitpro.ru
$Now = Get-Date
$Yesterday = $Now.AddDays(-1)
$NewOutputFile = "c:\ps\Events\$($Yesterday.ToString('yyyyMMdd'))_AD_NTLMv1_events.log"
function GetEvents($DC){
Write-Host "Searching log on " $DC.HostName
$Events = Get-EventLog "Security" -After $Yesterday.Date -Before $Now.Date -ComputerName $DC.HostName -Message "*NTLM V1*" -instanceid 4624
foreach($Event in $Events){
Write-Host $DC.HostName $Event.EventID $Event.TimeGenerated
Out-File -FilePath $NewOutputFile -InputObject "$($Event.EventID), $($Event.MachineName), $($Event.TimeGenerated), $($Event.ReplacementStrings),($Event.message)" -Append
}


}
foreach($DC in $ADDCs){GetEvents($DC)}


После того, как вы идентифицировали пользователей и приложения, использующие NTLM в вашем домене, попробуйте перевести их на использование Kerberos (возможно с использованием SPN). Некоторые приложения достаточно донастроить для использования Kerberos (см. статьи Kerberos авторизация в IIS, использование Kerberos авторизация в браузерах, использования keytab файла Kerberos для аутентификации в AD). Из личного опыта: некоторые действительно большие коммерческие продукты до сих пор используют проверку подлинности NTLM и не поддерживают Kerberos, некоторые продукты требуют обновления или изменений конфигурации.

Потенциально проблемы при отключении NTLMv1 могут быть у небольших опенсорсных продуктов, различных старых моделей сетевых сканеров (который складывают сканы в сетевые папки), некоторых NAS устройств и другого устаревшего оборудования, ПО и ОС.

Те приложений, которые нельзя переключить на использование NTLM можно добавить в исключения, разрешив им использовать NTLM аутентификацию, даже если она отключена на уровне домена. Для этого используется политика Network security: Restrict NTLM: Add server exceptions for NTLM authentication in this domain. В список исключений нужно добавить имена серверов (NetBIOS имена, IP адреса или FQDN), для аутентификации на которых можно использовать NTLM (конечно, в идеале этот список исключений должен быть пустым). Можно использовать знак подстановки
*
.

Картинка с сайта: winitpro.ru

Для использования Kerberos аутентификации в приложении нужно указывать DNS имя сервера, а не IP адрес. Если вы указываете IP адрес при подключении к ресурсу, используется NTLM аутентификация.

Переключаемся на использование аутентфикации NTLMv2

Прежде чем полностью отказаться от NTLM в домене AD, сначала рекомендуется отключить его более уязвимая версия NTLMv1. Администратору домена нужно убедиться, что в его сети запрещено использовать NTLM или LM для авторизации, т.к. в некоторых случаях атакующий может с помощью специальных запросов получить ответ на NTLM/LM запрос.

Тип аутентификации можно задать с помощью доменной политики. Откройте консоль управления доменными политиками GPMC.msc и отредактируйте Default Domain Controllers Policy. Перейдите в раздел Computer Configurations -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options и найдите политику Network Security: LAN Manager authentication level (Сетевая безопасность: уровень проверки подлинности LAN Manager).

Картинка с сайта: winitpro.ru

В настройках политики есть 6 опций:

• Send LM & NTLM responses;
• Send LM & NTLM responses – use NTLMv2 session security if negotiated;
• Send NTLM response only;
• Send NTLMv2 response only;
• Send NTLMv2 response only. Refuse LM;
• Send NTLMv2 response only. Refuse LM& NTLM.

Политики использования NTLM аутентификации расположены в порядке возрастания их безопасности. По умолчанию в Windows 7 и выше используется настройка Send NTLMv2 response only (Отправлять только NTLMv2-ответ). При этой настройке клиентские компьютеры используют NTLMv2 аутентификацию, но контролеры домены принимают LM, NTLM, и NTLMv2 запросы.

NTLMv2 может использоваться, если не сработал протокол Kerberos и при некоторых операциях (например, при управлении локальными учетными записями и группами на доменных компьютерах), или в рабочих группах.

Вы можете изменить значение политики на более безопасную 6 опцию — “Send NTLMv2 response only. Refuse LM & NTLM”. При этой политике контролеры домена также будут отвергать запросы LM и NTLM.

Также вы можете отключить NTLMv1 через реестр. Для этого в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa нужно создать параметр DWORD с именем LmCompatibilityLevel и значением от 0 до 5. Значение 5 соответствует значению политики «Отправлять только NTLMv2-ответ. Отказывать LM и NTLM».

В этом же разделе GPO убедитесь, что у вас включена политика Network security: Do mot store Lan Manager hash value on next password change (Сетевая безопасность: не хранить хэш-значения LAN Manager при следующей смене пароля). Эта политика включена по умолчанию, начиная с Windows Vista / Windows Server 2008 и запрещает создание LM-хэша.

Картинка с сайта: winitpro.ru

Если вы убедились, что ваш домен и службы корректно работают без NTLMv1, вы можете пойти дальше и попытаться отказаться от NTLMv2. NTLMv2 хотя и более защищенный протокол аутентификации, но все равно существенно проигрывает Kerberos в плане безопасности (хотя уязвимостей в NTLMv2 намного меньше, чем в первой версии протокола, все-таки существуют возможности перехвата и повторного использования данных, и отсутствует взаимная mutual аутентификации).

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

Полное отключение NTLM и перевод аутентфикации на Kerberos в домене Active Directory

Чтобы проверить, как будет работать аутентификация в различных приложениях в домене без использования NTLM, вы можете добавить учетные записи необходимых пользователей в доменную группу Protected Users (группа доступна, начиная с Windows Server 2012 R2), членам которой можно аутентифицироваться только по протоколу Kerberos (нельзя использовать NTLM, Digest Authentication или CredSSP). Так вы можете проверить корректность Kerberos аутентификации пользователя в различных приложениях.

Теперь вы можете полностью отключить NTLM в домене с помощью групповой политики Network Security: Restrict NTLM: NTLM authentication in this domain.

В этой политике доступно 5 опций:

• Disable: политика отключена (NTLM аутентификация в домене разрешена);
• Deny for domain accounts to domain servers: контролеры домена запрещают попытки аутентификации NTLM для всех серверов под доменными аккаунтами, возвращается ошибка «NTLM заблокирован»;
• Deny for domain accounts: контролеры домена запрещают попытки NTLM аутентификации для всех учетных записей домена, возвращается ошибка «NTLM заблокирован»;
• Deny for domain servers: запрещены запросы NTLM аутентификации для всех серверов;
• Deny all: контроллеры домена блокируют все запросы NTLM для всех серверов и учетных записей.

Картинка с сайта: winitpro.ru

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

Также с помощью отдельных параметров Default Domain Policy вы можете запретить входящий и исходящий NTLM трафик на компьютерах домена:

• Network security: Restrict NTLM: Incoming NTLM traffic =
  Deny all accounts
• Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers =
  Deny all

После включения аудита, при использовании NTLM для аутентификации в Event Viewer также будет появляться событие EventID 6038 от LsaSRV с предупреждением:

Microsoft Windows Server обнаружил, что в настоящее время между клиентами и этим сервером используется проверка подлинности ntlm. это событие возникает один раз при каждой загрузке, когда клиент первый раз использует ntlm с этим сервером.
Microsoft Windows Server has detected that NTLM authentication is presently being used between clients and this server. This event occurs once per boot of the server on the first time a client uses NTLM with this server.
NTLM is a weaker authentication mechanism. Please check:
Which applications are using NTLM authentication?
Are there configuration issues preventing the use of stronger authentication such as Kerberos authentication?
If NTLM must be supported, is Extended Protection configured?

Картинка с сайта: winitpro.ru

Вы можете проверить, что для аутентификации пользователя используется Kerberos с помощью команды:

klist sessions

Картинка с сайта: winitpro.ru

Данная команда показывает, что для аутентификации всех пользователей используется Kerberos (кроме встроенного локального пользователя Administrator, для которого всегда используется NTLM).

Если после отключения NTLM вы столкнетесь с частыми событиями блокировки учетных записей пользователей, внимательно изучите события с EventID 4771 (
Kerberos pre-authentication failed
). Смотрите Failure Code в описании ошибки. Там будет указана причина и источник блокировки.

Для дальнейшего эшелонирования защиты в AD рекомендую познакомиться со статьями:

• Защита от извлечения пароля из памяти утилитами а-ля mimikatz
• Защита учетных записей администраторов
• Отключение LLMNR и NetBIOS over TCP/IP

NTLM is a challenge-response-based authentication protocol. It is the default authentication protocol of NT 4.0 and is—for backward compatibility—still supported in Windows 2000 and Windows Server 2003.

4.5.1 The protocol

Let’s look at the basic operation of the NTLM authentication protocol using the example of a user running Outlook XP who wants to access his or her mailbox on an Exchange server. The Exchange server is running Exchange 2000 and is installed on a Windows 2000 member server—it is a member of a Windows Server 2003 domain. The reason why we take an Outlook XP–Exchange 2000 scenario is because in Outlook 2003, Exchange 2003 Microsoft embedded support for the Kerberos authentication protocol.

In this example, the client, the Exchange server, and the domain controller will run through the following six authentication steps (as illustrated in Figure 4.9):

• Step 1: The client tells the Exchange server the user wants to access his mailbox.

• Step 2: The Exchange server sends an NTLM challenge (i.e., a random string) to the client.

  
  Figure 4.9: Basic NTLM authentication flow.

• Step 3: The NTLM response that the client sends back to the Exchange server consists of the server’s challenge, encrypted using the hashed version of the user password.

• Step 4: Because the Exchange server is not a domain controller and does not have access to a secured copy of the user’s credentials (the hashed password), it will forward the NTLM response (together with the NTLM challenge) to a domain controller. The latter process is known as NTLM pass-through authentication.

• Step 5: The domain controller validates the response it received from the domain controller by encrypting the original NTLM challenge with its local copy of the hashed user password. It then compares the result to the NTLM response that the Exchange receiver received from the client.

• Step 6: If the two values are identical, the domain controller will inform the Exchange server that the user is authenticated. If they are not, the domain controller informs the Exchange server that the credentials the user provided are not valid to authenticate the user.

The NTLM authentication protocol consists of two subprotocols: the NT and LM protocols. This basically means that in response to the server’s NTLM challenge, the client replies with two messages: an NTLM and an LM response.

Windows 9x, Windows 3.x, DOS, and OS/2 only support LM authentication. For backward compatibility, NT 4.0, Windows 2000, Windows XP, and Windows Server 2003 support both authentication flavors. This means they can authenticate requests coming from Win9x, Windows 3.x, DOS, and OS/2 clients. By default, every NT and Windows client responds to an NTLM challenge by sending back both an NT and an LM response. In doing so, they can also authenticate against Win9x, Windows3.x, DOS, and OS/2 machines.

In addition to the two NTLM authentication protocols (the NT and LM protocols), Microsoft also offers an enhanced version of NTLM— called NTLMv2—from NT4 SP4 on. One of the advanced security features that NTLMv2 provides is sealing a user’s authorization data in an NTLM pass-through message. It also better protects against man-in-the- middle attacks.

NTLMv2 is available on any NT machine running SP4 or later. Microsoft provides NTLMv2 support for Win9x with the Directory Services Client (dsclient.exe) that is available from the Windows 2000 CD (at the moment of the writing of this book, dsclient was not included on the Windows Server 2003 CD). How to enforce the use of the more secure NTLMv2 authentication protocol is explained in Section 4.5.2.

4.5.2 Controlling the NTLM subprotocols

Before NT4 SP4, no easy way existed to disable the LM portion of the NTLM authentication protocol. In all later Windows versions, administrators can control the NTLM subprotocols that Windows clients use, and Windows server administrators can set the NTLM subprotocols that they will accept.

To control the NTLM subprotocols, you can use a GPO setting or the LMCompatibilityLevel (REG_DWORD) registry entry. The registry entry is located in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Control\Lsa registry subkey. The GPO setting is called “Network Security: LAN Manager Authentication Level” and is located in Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options. Table 4.4 shows the LMCompatibilityLevel and the GPO settings and their meanings. The default LMCompatibilityLevel value for Windows Server 2003 is “Send NTLM Response Only.”

Table 4.4: LM Compatibility Level Settings

4.5.3 Removing the LM hashes from the credential database

The two NTLM authentication protocols NT and LM also use different hashing methods to securely store the user’s password in the Windows security database (SAM or AD). As a consequence, the Windows security database contains an LM hash and an NT hash (also known as the Unicode hash) for every user account’s password.

The LM hash is weak compared to the NT hash (see the following side note) and can easily be cracked using brute-force attacks (using, for example, LC4—as explained in Chapter 2). Because of the way LM hashing works, the effective password length is limited to seven characters (even if the user uses a longer password), and all characters are stored in uppercase (even if the user uses a combination of uppercase and lowercase characters). The LM hash weaknesses do not mean that the NT portion is unbreakable; it simply takes much more time to break it. For more details about the weaknesses of the LM hash, visit http://www.atstake.com/research/lc.

The only protocol using the LM hash is the LM authentication protocol (in both NTLM and NTLMv2). The NT authentication protocol (in both NTLM and NTLMv2) and the Kerberos authentication protocol both use the NT hash during their authentication sequence.

From Windows 2000 Service Pack 2 (SP2) on, Microsoft offers the capability to remove the LM hashes from the credential database. To do this you can use the NoLMHash registry hack or the “Network security: Do not store LAN Manager hash value on next password change” GPO setting. The NoLMHash (REG_DWORD) registry hack is located in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa registry key and should be set to 1 to disable LM hash storage. The GPO setting is located in Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options. Two other lesser known methods to disable LM hash storage are the following:

• Using a password that is longer than 15 characters

• Using ALT characters in your password

When you use one of these options, no more LM hashes will be stored in the credential database at the next user password change. In Windows 2000 the LM hash history entries in the security database will not be cleared when enabling the NoLMHash setting. They will be cleared in Windows XP and Windows Server 2003. If you enable the NoLMHash setting in a domain environment, you must enable it on all domain controllers of the domain.

Because the LM protocol is still used for authenticating Windows 9x (or older) Windows clients, you cannot use these settings when you have these client platforms in your Windows 2000 or Windows Server 2003 environment.

The LM Hash Versus the NT Hash Windows computes the LM hash as follows:

• Convert all lowercase characters in the password to uppercase.

• Pad the password with NULL characters until it is exactly 14 characters long.

• Split the password into two 7-character chunks.

• Use each chunk separately as a DES key to encrypt a specific string.

• Concatenate the two cipher texts into a 128-bit string and store the result.

  As a result of the way the LM hash is generated, it is very easy to crack. Most password cracking tools (such as LC4) will start by cracking the LM hashes.

  In AD the LM hash is stored in the DbcsPwd account property; the LM hash history is stored in the LmPwdHistory account property.

  The NT Hash is calculated by taking the plaintext password and generating an MD4 hash of it. The NT hash is much more resistant to brute-force attacks than the LM hash.

  In AD the NT hash is stored in the UnicodePwd account property; the LM hash history is stored in the NtPwdHistory account property.

Существует довольно распространенный миф, что платформа Windows является незащищенной по своей природе. Это принципиально неверно. Windows Server 2003 — одна из наиболее защищенных операционных систем. Она основывается на системе безопасности Windows 2000 и расширяет ее. Windows Server 2003 можно сделать защищенной на любом требуемом уровне (если администратор знает, как это сделать). В этой лекции описываются некоторые средства и процессы, используемые для защиты вашего сервера.

Аутентификация Windows Server 2003

Аутентификация — это проверка того, что данное лицо соответствует опознавательным данным, которые он предъявляет; тем самым, аутентификация является основным компонентом системы безопасности Windows Server 2003. Она подтверждает опознавательные данные («личность«) пользователя, который хочет выполнить вход на компьютер, в сеть или в домен. Используя Active Directory, Windows Server 2003 поддерживает единый вход для доступа ко всем сетевым ресурсам. Это позволяет пользователю выполнять вход в домен с помощью единственного пароля или смарт-карты и аутентифицироваться для любого ресурса в домене.

Windows Server 2003 поддерживает два основных протокола для аутентификации.

• Kerberos V5.Используемый по умолчанию протокол аутентификации для серверов Windows 2000, Windows XP и Windows Server 2003, если они являются членами домена Active Directory. Его можно использовать для интерактивного входа по паролю или смарт-карте.
• NTLM.Поддерживается для совместимости с Windows 95, Windows 98, Windows Me и Windows NT 4, которые используют NTLM для подсоединения к сети. Компьютеры, работающие с Windows Server 2003, используют NTLM при подсоединении или доступе к ресурсам в домене Windows NT 4.

Аутентификация NTLM

Операционные системы Microsoft Windows 9x и Windows NT не могут использовать Kerberos, поэтому они используют NTLM для аутентификации в домене Windows Server 2003. В защите NTLM имеются «слабые места», которые позволяют специалистам по взлому паролей дешифровать NTLM-аутентификацию. Чтобы воспрепятствовать этому, Microsoft разработала NTLM версии 2. Клиенты и серверы Windows 2000, а также Windows XP будут продолжать аутентифицироваться на контроллерах доменов Windows Server 2003 с помощью Kerberos независимо от того, что используется, — NTLM или NTLMv2.

Примечание. Подробнее об активизации NTLMv2 в более ранних версиях Windows см. в статье 239869 Microsoft Knowledge Base «How to Enable NTLM 2 Authentication for Windows 95/98/2000/NT» по адресу http://support.microsoft.com.

Аутентификация NTLM для telnet

Для клиента telnet (сетевого теледоступа) в Windows 2000 добавлена поддержка аутентификации NTLM. Это позволяет клиенту telnet в Windows 2000 или Windows Server 2003 выполнять вход на сервер telnet Windows Server 2003 с помощью аутентификации NTLM. Для доступа к серверу telnet пользователи могут использовать свое локальное пользовательское имя и пароль Windows 2000 или информацию доменной учетной записи. Если аутентификация NTLM не используется, то пользовательское имя и пароль передаются на сервер telnet в виде нешифрованного текста. В результате эти данные могут быть перехвачены злоумышленником в сети. При аутентификации NTLM клиент использует для аутентификации средства безопасности Windows Server 2003, и у пользователя не запрашиваются пользовательское имя и пароль. Пользовательское имя и пароль передаются на сервер в шифрованном виде. После аутентификации все команды передаются в виде нешифрованного текста.

Примечание. Microsoft Terminal Server является более защищенной по сравнению с telnet. Terminal Server можно блокировать, используя в основном те же процессы, что используются для усиления защиты серверов Windows.

Обзор Kerberos

Протокол аутентификации Kerberos обеспечивает взаимную защиту между клиентами и серверами, а также между серверами. Когда пользователь выполняет вход, используя пользовательское имя/пароль или смарт-карту, компьютер находит сервер Active Directory и службу аутентификации Kerberos. Затем Kerberos выдает так называемые билеты (ticket), чтобы разрешить доступ к сетевым службам. Эти билеты содержат шифрованные данные, включая шифрованный пароль, подтверждающий опознавательные данные пользователя для этой службы.

Главным компонентом Kerberos является Центр распространения ключей (KDC — Key Distribution Center). KDC запускается на каждом контроллере домена как часть Active Directory и используется для хранения паролей и информации учетных записей клиентов. Windows Server 2003 реализует KDC как доменную службу и использует Active Directory домена как ее базу данных с информацией учетных записей. В процесс аутентификации Kerberos входят следующие шаги.

1. Пользователь на клиентском компьютере аутентифицируется для KDC с помощью пароля или смарт-карты.
2. KDC выдает клиенту специальный билет, позволяющий получить билет (TGT — Ticket-granting ticket), чтобы разрешить ему доступ к предоставляющей билеты службе (TGS — Ticket-granting service) на контроллере домена.
3. TGS выдает клиенту билет на обслуживание.
4. Этот билет подтверждает опознавательные данные пользователя для службы и опознавательные данные службы для пользователя.

Реализация Kerberos в Windows Server 2003

По умолчанию Kerberos обладает свойствами прозрачности и защищенности в Windows Server 2003. Это освобождает вас от необходимости знать, каким образом реализован Kerberos.

Примечание. Администраторам домена или предприятия не следует вносить изменения в реализацию Kerberos по умолчанию без ясного понимания цели этих изменений, а также их влияния на домен. После внесения изменений на одном контроллере домена настройки реплицируются на все остальные контроллеры домена. Любые изменения политики Kerberos окажут влияние на все компьютеры домена.

Если вам необходимо внести изменения в политику Kerberos, выполните следующие шаги.

1. Откройте оснастку Active Directory Users and Computers.
2. В дереве консоли щелкните правой кнопкой на данном домене.
3. Выберите пункт Properties (Свойства) и затем щелкните на вкладке Group Policy (Групповая политика).
4. Щелкните на кнопке Edit.
5. В дереве консоли щелкните на Kerberos Policy (в последовательности Computer Configuration/ Windows Settings/Security Settings/Account Policies/Kerberos Policy).
6. Дважды щелкните на политике Kerberos, которую хотите модифицировать.
7. Внесите изменения в эту политику и затем щелкните на кнопке OK.

Имеется несколько относящихся к Kerberos политик, которые можно модифицировать, если это крайне необходимо.

• Enforce User Login Restrictions. Указывает, что KDC должен проверять наличие у пользователя права «Log on locally» (Локальный вход) или «Access this computer from the Network» (Доступ к данному компьютеру из сети). Если пользователь не имеет одного из этих прав, то билет на обслуживание не выдается. Эта политика включена по умолчанию.
• Maximum Lifetime That a User Ticket Can Be Renewed.Задает максимальный срок действия билета TGT или сеансового библиотека. По умолчанию 7 дней.
• Maximum Service Ticket Lifetime.Задает количество минут, в течение которых действителен билет на обслуживание. Это должно быть значение от 10 минут до времени, заданного в политике «Maximum User Ticket Lifetime». По умолчанию 600 минут.
• Maximum Tolerance for Synchronization of Computer Clocks. Задает максимально допустимое отличие в минутах между таймерами компьютера-сервера KDC и клиентского компьютера. Таймеры этих машин должны быть синхронизированы с максимально возможной точностью. По умолчанию 5 минут.
• Maximum User Ticket Lifetime. Задает количество часов, в течение которых действителен билет Kerberos TGT. По истечении этого времени должен быть получен новый билет или обновлен старый. По умолчанию 10 минут.

Имеется также небольшое число других опций Kerberos. Для доступа к этим опциям нужно выбрать пользователя в окне Active Directory Users and Computers и щелкнуть на Properties.

• Smart Card Is Required for Interactive Logon.Требует, чтобы пользователь выполнял вход с помощью смарт-карты. По умолчанию эта политика отключена.
• Use DES Encryption for This Account.Требует использования 56-битного DES-шифрования вместо 128-битного RC4, используемого в Microsoft Kerberos. Поскольку метод DES защищен намного меньше, чем RC4, использование DES не рекомендуется. По умолчанию эта политика отключена.

Хотя Kerberos существенно повышает защищенность по сравнению с прежними протоколами аутентификации, его безопасность в целом все еще основывается на пароле пользователя. В результате слабая политика паролей может обесценить все преимущества Kerberos. Один из способов разрешения данной проблемы — это использование смарт-карт.

Реализация смарт-карт

Windows Server 2003, как и Windows 2000, поддерживает использование смарт-карт для входа. На смарт-карте могут храниться сертификат пользователя и личный ключ, поэтому он может выполнять вход, установив эту карту в устройство чтения смарт-карт. После этого компьютер запрашивает у пользователя его личный идентификационный номер (PIN-код), чтобы разрешить этому пользователю вход в систему. Смарт-карты дают следующие преимущества по сравнению с паролями.

• Отпадает вопрос слабости использования пароля в Kerberos. Смарт-карты обеспечивают более сильную аутентификацию, чем пароли, поскольку для них используются шифрованные идентификационные данные.
• Требуется, чтобы пользователь лично установил смарт-карту для аутентификации в домене.
• Смарт-карта может быть блокирована после определенного числа неудачных попыток ввода PIN-кода. Это может воспрепятствовать словарным и «лобовым» атакам на смарт-карту.

Windows Server 2003 использует несколько политик, чтобы определить вход в систему с помощью смарт-карт. Политика Smart Card Is Required for Interactive Logon требует использования смарт-карты для интерактивного входа в систему. Если задана эта политика, то пользователь не может использовать пароль для входа по учетной записи. Эта политика касается только интерактивных и сетевых входов, но не входов удаленного доступа, для которых используется другая политика. Смарт-карты особенно рекомендуются для наиболее важных учетных записей, например, учетных записей Administrator. Политику Smart Card Is Required for Interactive Logon не следует использовать, если пользователь должен указать пользовательское имя, пароль и имя домена для доступа к сетевым ресурсам.

Инфраструктура открытых ключей и аутентификация Windows Server 2003

Windows Server 2003 использует сертификаты для разнообразных функций, таких как аутентификация по смарт-карте, аутентификация на веб-сервере, защищенная электронная почта, безопасность IP (Internet Protocol) и подписание кода (code signing). Сертификат — это цифровой документ, выданный каким-либо ответственным органом для подтверждения идентификационных данных обладателя сертификата. Он связывает открытый ключ (public key) с пользователем, компьютером или службой, которые владеют соответствующим личным ключом (private key). В сертификат обычно включается информация о пользователе или компьютере, которому выдан этот сертификат, информация о самом сертификате и (обычно) о так
называемом Центре сертификации (ЦС) (Certificate authority [CA]), который выдал сертификат. Сертификаты обычно содержат следующую информацию.

• Открытый ключ пользователя.
• Часть идентифицирующей информации о пользователе, например, его имя и адрес электронной почты.
• Срок действия этого сертификата.
• Информация о поставщике этого сертификата.
• Цифровая подпись поставщика, которая связывает открытый ключ пользователя и его уникальную идентифицирующую информацию.

Примечание. Хотя сертификаты использовались и в предыдущих операционных системах Windows, они не были широко распространены как средство системы безопасности. Эта ситуация изменяется с ростом числа организаций, развертывающих Active Directory.

Обычно сертификаты действуют только в течение указанного периода времени, который тоже включается в сертификат. По истечении периода действия сертификата пользователи должны запрашивать новый сертификат. При использовании сертификатов Windows Server 2003 доверяет тому, что поставщик сертификата удостоверил идентификационные данные пользователя сертификата. Сервер обозначает поставщика сертификатов как доверяемый корневой ЦС, помещая сертификат этого поставщика, подписанный его собственной подписью, в хранилище сертификатов доверяемых корневых ЦС на хост-компьютере. Для управления этими ЦС в Windows Server 2003 используется служба Certificate Services. Таким образом, ЦС несет ответственность за создание и удостоверение идентификационных данных обладателей сертификатов. Вы можете управлять службой Certificate Services с помощью консоли MMC Certification Authority (Центр сертификации).

Картинка с сайта: intuit.ru

Шаблоны сертификатов

Шаблон сертификата — это набор правил и настроек, которые применяются к запросам сертификатов. Для каждого типа сертификатов должен быть сконфигурирован шаблон сертификата. Шаблоны сертификатов можно настраивать в центрах сертификации (ЦС) предприятий Windows Server 2003, и они хранятся в Active Directory для использования всеми ЦС в домене. Это позволяет вам выбрать шаблон по умолчанию или модифицировать существующие шаблоны, чтобы создавать настраиваемые шаблоны. В Windows Server 2003 имеется несколько типов шаблонов сертификатов.

• Server Authentication Certificates (Сертификаты для аутентификации серверов).

Используются для аутентификации серверов перед клиентами.

• Client Authentication Certificates (Сертификаты для аутентификации клиентов).

Используются для аутентификации клиентов перед серверами.

• Code Signing Certificates (Сертификаты для подписания кода).Используются для подписания активного содержимого и приложений, чтобы гарантировать их поступление от доверяемого источника.
• Secure Email Certificates (Сертификаты для защищенной почты). Используются для подписания сообщений электронной почты.
• Encrypting File System Certificates (Сертификаты для шифрующей файловой системы).Применяются для шифрования и дешифрования симметричного ключа, используемого файловой системой Encrypting File System (EFS) Windows Server 2003.
• File Recovery Certificates (Сертификаты для восстановления файлов). Используются для шифрования и дешифрования симметричного ключа, используемого для восстановления данных, шифрованных с помощью файловой системы EFS Windows Server 2003.