АУТЕНТИФИКАЦИЯ в разных версиях Windows

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

Сергей Гордейчик

	— Никакая я не змея! — сказала Алиса. — Я просто... просто... — Ну, скажи, скажи, кто ты такая? — подхватила Горлица. — Сразу видно, хочешь что-то выдумать.
	Льюис Кэрролл. Приключения Алисы в Стране чудес (пер. Нины Демуровой)

Одной из главных задач, которые приходится решать при построении защищенной информационной системы, является создание надежной схемы аутентификации. В сетях на основе 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 достаточно будет запустить сценарий с сервера, после чего начинать работу в домене.

31.10.2003г