Процедура аутентификации Windows. Создание учетных данных в среде SQL Server Management Studio. Аутентификация: общие принципы

В случае, если сервер располагается на базе Cassini, Вам необходимо нажать клавишу с логотипом Windows (флажок Microsoft) + R и ввести следующую команду в диалоговое окно: "services.msc " (без кавычек), после чего появится окно служб Windows. В нем Вы сможете найти строчку Веб-сервер ELMA , кликнуть по ней правой кнопкой мыши и выбрать в контекстном меню пункт Свойства , в котором и располагается искомая вкладка Вход в систему . Укажите учетную запись LocalSystem

Если сервер располагается на базе IIS, необходимо зайти в Диспетчер служб IIS (стандартно на сервере в Пуск - Администрирование ). В нем на вкладке Пулы приложений нажать правой кнопкой мыши на пул ELMA3-Standart и выбрать в контекстном меню пункт Дополнительные параметры . На панели Модель процесса в поле Удостоверение указать учетную запись LocalSystem либо реальную учетную запись с правами администратора, после чего следует перезапустить веб-сервер.

Создание учетных данных в среде SQL Server Management Studio

В обозревателе объектов раскройте папку Безопасность .
Нажмите правой кнопкой мыши на папку Учетные данные и выберите команду Создать учетные данные .
В диалоговом окне Создание учетных данных в поле Учетное имя введите имя для учетных данных.
В поле Удостоверение введите имя учетной записи, используемой для исходящих соединений (при выходе из контекста SQL Server). Как правило, это будет учетная запись пользователя Windows, но удостоверение может быть и учетной записью другого типа. Либо нажмите кнопку с многоточием (...), чтобы открыть диалоговое окно Выбор пользователя или группы .
В полях Пароль и Подтверждение пароля введите пароль учетной записи, указанной в поле Удостоверение . Если в поле Удостоверение указана учетная запись пользователя Windows, то это будет пароль Windows. Поле Пароль может быть пустым, если пароль не требуется.
Установите флажок Использовать поставщика услуг шифрования , чтобы учетные данные проверялись поставщиком расширенного управления ключами.
Нажмите кнопку ОК .

Аутентификация в SQL Server

Как известно, в SQL Server можно выбрать один из двух типов аутинтификации: Windows Authentication (Аутентификация Windows) или SQL Server Authentication (Аутентификация SQL Server). Сменить режим аутентификации на сервере с помощью SSMS (SQL Server Management Studio) либо с помощью EM (Entreprise Manager) достаточно легко. Для этого необходимо в свойствах сервера перейти на закладку Security и установить флажок в нужное поле.

После этого обязательно необходимо перезапустить службу MSSQLSERVER.

Если установлена бесплатная редакция MSDE (2000) или Express (2005/2008) без установленных клиентских утилит, то необходимо знать, что настройки аутентификации хранятся в реестре.

С помощью недокументированной процедуры T-SQL xp_instance_regwrite , через утилиты OSQL/SQLCMD , меняем значение (Windows Authentication mode; SQL Server and Windows Authentication mode ) EXEC xp_instance_regwrite N’HKEY_LOCAL_MACHINE’, N’Software\Microsoft\MSSQLServer\MSSQLServer’, N’LoginMode’, REG_DWORD, 1 . Далее после смены типа аутентификации, необходимо перезапустить службу. Остановить её можно также с помощью T-SQL (процедура xp_servicecontrol также недокументированная): EXEC master..xp_servicecontrol ’stop’, ’MSSQLSERVER’ . А вот запустить службу через T-SQL не выйдет, так как она остановлена, но если у вас установлен второй инстанс, тогда через него достаточно выполнить: EXEC master..xp_servicecontrol ’start’, ’MSSQLSERVER’ . Службу лучше перезапускать с помощью команд net stop MSSQLSERVER/net start MSSQLSERVER .

Конечный вариант для смены аутентификации на сервере будет выглядеть так (достаточно вставить этот код в bat-файл и использовать, когда вам это потребуется):

SQLCMD -E -q "EXEC xp_instance_regwrite N’HKEY_LOCAL_MACHINE’, N’Software\Microsoft\MSSQLServer\MSSQLServer’, N’LoginMode’, REG_DWORD, 1" net stop MSSQLSERVER net start MSSQLSERVER

Создание учетных данных FireBird

Только пользователь SYSDBA может отображать, удалять, изменять и создавать любое количество учетных записей для различных категорий пользователей.

Структура учетных записей пользователей:

UserName - имя пользователя. Максимальная длина 31 символ. Имя не чувствительно к регистру;
Password - пароль пользователя чувствителен к регистру. Максимальное количество символов 32, однако, только первые восемь имеют значение;
UID - целое число, задающее идентификатор пользователя;
GID - целое число, задающее идентификатор группы;
FirstName - имя. Может занимать до 17 символов;
MiddleName - второе имя. Можем использовать в качестве отчества. До 17 символов;
LastName - фамилия. До 17 символов.

Обязательными являются только имя пользователя и пароль.

Внимание! Ни в каком поле учетной записи не используйте буквы кириллицы. Такая запись не будет создана или изменена.

Запустите программу IBExpert. Нажмите левой кнопкой мыши по кнопке Tools в верхнем меню и в выпадающем меню выберите пункт User Manager . Откроется диалоговое окно User Manager. В выпадающем списке Server выберите local .

Нажмите на кнопку Connect справа от выпадающего списка Server . Откроется диалоговое окно Server Login .

В поле Login уже будет задано имя пользователя SYSDBA . Вам нужно в поле Password ввести пароль masterkey (или другой, если вы изменили значение пароля) и нажать на кнопку ОК . Появится список учетных записей, который будет содержать только одного пользователя SYSDBA.

Нажмите на кнопку Add , в открывшемся окне New User введите имя пользователя (имя пользователя вы можете вводить в любом регистре, символы все равно будут появляться в верхнем регистре) и дважды введите пароль в поля Password и Confirm Password . Нажмите на кнопку ОК . В список будет добавлена новая учетная запись пользователя.

Для изменения существующей записи (изменять можно любое поле, кроме имени пользователя) необходимо нажать на кнопку Edit или дважды нажать левой кнопкой мыши по нужной строке и в появившемся окне изменить желаемые поля.

Для удаления существующей записи щелкните по кнопке Delete и в диалоговом окне подтвердите удаление.

Чтобы изменить имя пользователя, вам нужно удалить старую запись и ввести новую, с другим именем и теми же или другими характеристиками.

Если вы одновременно работаете в IBExpert и используете утилиту gsec или другую программу для добавления или изменения учетных записей, то для того, чтобы увидеть в списке IBExpert новое состояние списка, нужно нажать на кнопку Refresh .

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

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

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

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

Изменения системных ресурсов первоначально разрешены системным администратором.
При попытке пользователя получить доступ или обновить системный ресурс разрешение на действие оценивается системой или приложением.

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

Процесс авторизации и аутентификации.

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

Протокол Kerberos версии 5: Основной метод аутентификации клиентов и серверов под управлением операционных систем Microsoft Windows. Он используется для проверки подлинности учетных записей пользователей и учетных записей компьютеров.
Windows NT LAN Manager (NTLM): используется для обратной совместимости с операционными системами более старыми, чем Windows 2000 и некоторых приложений. Он менее гибок, эффективен и безопасен, чем протокол Kerberos версии 5.
Сопоставление сертификатов: обычно используется для проверки подлинности при входе в сочетании со смарт-картой. Сертификат, записанный на смарт-карте, связан с учетной записью пользователя. Для чтения смарт-карт и аутентификации пользователя используется считыватель смарт-карт.

Новые функции аутентификации в Windows 7.

Целый ряд улучшений, связанных с процессами входа и проверки подлинности пользователя был добавлен еще в Windows Vista ®. Эти усовершенствования увеличили базовый набор функции проверки подлинности, чтобы помогло обеспечить лучшую безопасность и управляемость. В Windows 7 Microsoft продолжает начатые в Windows Vista усовершенствования, предоставляя следующие новые функции аутентификации:

Смарт-карты
Биометрия
Интеграция личности в Интернете.

Смарт-карты.

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

Смарт-карты Plug and Play
Личные удостоверения проверки (PIV), стандарт национального института стандартов и технологий США (NIST)
Поддержка для входа смарт-карты Kerberos.
Шифрование дисков BitLocker
Документы и электронная почта
Использование с бизнес-приложениями.

Биометрия.

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

До сих пор в Windows не было стандартной поддержки биометрических устройств. Чтобы решить эту проблему, Windows 7 вводит Windows Biometric Framework (WBF). WBF предоставляет новый набор компонентов, поддерживающий снятие отпечатка пальца с помощью биометрические устройства. Эти компоненты увеличивают безопасность пользователей.

Windows Biometric Framework упрощает пользователям и администраторам настройку и управление биометрическими устройствами на локальном компьютере или в домене.

Интеграция личности в Интернете.

Управление аккаунтом - стратегия обеспечения безопасности. Для разрешения или запрета проверки подлинности определенных компьютеров или всех компьютеров, которыми вы управляете онлайн, используется Групповая политика.

Интеграцией онлайн идентификации можно управлять политикой группы. Политика, настроенная как: “Сетевая безопасность: Позволить этому компьютеру при запросе идентификации PKU2U использовать ID онлайн”, управляет возможностью ID онлайн подтвердить подлинность этого компьютера при помощи протокола PKU2U. Этот параметр политики не влияет на способность учетных записей доменов или локальных учетных записей пользователей входить на этот компьютер.

Что делать, если вы изобрели оригинальное устройство или технологию (например, популярные ныне биометрические технологии) для идентификации пользователей? Или хотите в момент авторизации проверять дополнительные параметры? Или просто изменить графический интерфейс, предоставляемый при регистрации в системе? Или пользоваться ресурсами нестандартных информационных провайдеров, например разработанного своими силами файл-сервера, требующих авторизации?

Архитектура Windows предоставляет разработчикам прекрасные возможности для решения подобных задач. И все, что нужно сделать, - это переписать парочку небольших модулей да реализовать несколько экспортируемых функций. Один из модулей называется Graphical Identification and Authentication dynamic-link library (GINA DLL). Вы взаимодействуете с этим модулем, когда вводите имя и пароль, нажимая на Ctrl-Alt-Del, блокируете рабочую станцию или меняете пароль и т. д. Достаточно переписать модуль, и перед вами раскроются новые горизонты.

В этой статье я остановлюсь на реализации основных функций, которые должна экспортировать GINA.DLL, и на использовании ряда функций подсистемы Local Security Authority (LSA), которая, собственно, и осуществляет аутентификацию пользователя в системе. Подробнее об LSA, которая предоставляет очень интересный API, я расскажу в одной из следующих статей. Здесь же я остановлюсь лишь на взаимодействии данной подсистемы и модуля GINA.

Загрузка Windows

Посмотрим, какие стадии проходит Windows 2000 в процессе загрузки (подробнее об этом рассказано в ). После включения компьютера выполняется загрузка BIOS, которая проводит процедуру первоначального тестирования оборудования (POST), считывает запись Master Boot Record (MBR) и передает управление коду, содержащемуся в этой записи. Он выполняет проверку, ищет в корневом каталоге модуль ntldr и передает ему управление (MBR не может читать дерево подкаталогов, поэтому Ntldr всегда находится в корневом каталоге). В свою очередь, Ntldr обрабатывает файл boot.ini, выводит на экран меню вариантов загрузки или, если вариант один, не дожидаясь выбора, переходит к следующему этапу. На нем запускается 16-разрядное приложение ntdetect.com, которое получает информацию об оборудовании от BIOS и сохраняет ее во внутренних структурах. Затем ntldr выводит картинку - индикатор загрузки Windows 2000 - и предлагает нажать на F8. Действия операционной системы при выборе специальных вариантов загрузки по нажатию клавиши F8 мы здесь рассматривать не будем.

Ntldr загружает ядро операционной системы и Hardware Abstraction Layer (HAL), которым, по умолчанию, соответствуют файлы Ntoskrnl.exe и HAL.dll. Далее загружаются необходимые (помеченные флажком SERVICE_BOOT_START) драйверы устройств, описанные в файле SYSTEM, содержащем соответствующий раздел реестра. После этого загрузчик производит действия, необходимые для запуска ntoskrnl.exe, и передает управление его главной функции. Здесь происходит много всяких, во-первых, сложных и, во-вторых, не представляющих сейчас для нас интереса событий. Но в числе прочего создается процесс Smss, который формирует среду пользовательского режима. Smss запускает подсистему Win32, программы, перечисленные в HKLMSYSTEMCurrentControlSet ControlSession ManagerBootExecute, инициализирует реестр, переменные окружения и другие «мелочи» и, наконец, запускает процесс Winlogon.

Далее ответственность за дальнейшую инициализацию системы ложится на Winlogon. Он формирует объект WindowStation и три рабочих стола - пользовательский, хранителя экрана и Winlogon; загружает GINA DLL (!), создает процесс диспетчера управления службами (SCM), загружает все службы и драйверы устройств, помеченные для автоматического запуска, и запускает процесс Lsass. После того как пользователь успешно зарегистрировался, а SCM запустил службы и драйверы, загрузка считается успешно завершенной, и LastKnownGood обновляется в соответствии с текущими установками.

Вот таким образом происходит загрузка Windows 2000. Понимая процесс загрузки, мы можем смело переходить к подробному обсуждению работы интересующего нас модуля - GINA. Свое исследование я хочу начать с того момента, когда пользователь еще не зарегистрировался в системе, а GINA DLL только загружена в память. Заметим, что процесс инициализации GINA и загрузка служб и драйверов происходят параллельно. Этим объясняется, почему для некоторых реализаций GINA в тот момент, когда пользователь хочет предпринять какие-то действия, необходимых служб еще нет.

Подсистема регистрации пользователя в Windows NT/2000/XP состоит из трех компонентов: Winlogon.exe, GINA DLL и, возможно, нескольких сетевых библиотек (Network Providers), осуществляющих вторичную авторизацию, например на файл-сервере собственной разработки. Регистрация выполняется через LSA API. GINA DLL, как показано на Рисунке 1, непосредственно взаимодействует с этой подсистемой и возвращает результаты регистрации Winlogon. В Windows 2000 и более поздних версиях поддерживается механизм notification packages - пакетов уведомлений. Это модули, представляющие собой DLL, которые вызываются Winlogon в моменты, соответствующие тем или иным событиям.

Рисунок 1. Схема подсистемы регистрации.

Среда разработки, выполнения и отладки демонстрационной программы

Код, представленный в листингах, и полный текст демонстрационного модуля GINA DLL, который можно получить на нашем сайте, разработан в Visual C++ 6.0 без пакетов обновления с использованием Platform SDK. Проект представляет собой Win32 Dynamic-Link Library. Необходимо добавить директиву _WIN32_WINNT =0x0500 для препроцессора и дополнительные библиотеки netapi32.lib и Secur32.lib - для компоновщика. Для того чтобы наша реализация GINA DLL загрузилась в память, ее нужно скомпилировать. Программа выполняется на Windows 2000 без пакетов обновления и в более поздних версиях Windows.

С отладкой приложения дело обстоит сложнее. Основная проблема заключается в том, что отладчик запускается на рабочем столе по умолчанию, которым является пользовательский рабочий стол. А GINA выполняется на рабочем столе Winlogon. Можно поступить следующим образом: используя отладочную версию Winlogon, которую можно найти, например, в DDK, получать log-файлы, которые вполне пригодны для анализа. Для этого необходимо в файле Win.ini создать секцию

LogFile=C:Winlogon.log DebugFlags=Flag1[, Flag2...]

Имя файла должно содержать полный путь. Флаги, определяющие, какую информацию нужно записывать в журнал, указаны в Таблице 1 . Для запуска отладочной версии Winlogon необходимо в раздел реестра HKLMSoftwareMicrosoftWindows NTCurrentVersionImage File Execution OptionsWinlogon.exe добавить значение Debugger типа REG_SZ со значением ntsd -d (подробнее об отладке компонентов Windows можно прочитать в и ). Если такого раздела не существует, а в обычных конфигурациях Windows это именно так, его требуется создать. В статье Q260901 базы знаний MSDN технология, позволяющая отлаживать GINA DLL на одном компьютере, описана более подробно.

Путь к модулю, который загружает Winlogon, находится в значении параметра GinaDLL. По умолчанию это msGINA.dll. Если в реестре этого параметра нет, то Winlogon также использует msGINA.dll. При загрузке в безопасном режиме (Safe Mode) всегда загружается модуль msGINA.dll. Если в папке System32 его нет, то он подгружается из dllcache, в противном случае загрузка прерывается. Поэтому при отладке своей версии модуля не следует уничтожать модуль по умолчанию.

Взаимодействие Winlogon и GINA

Как отмечалось выше, GINA представляет собой DLL, которая экспортирует ряд как обязательных, так и дополнительных функций. Первые необходимо реализовать в своей версии модуля, а для вторых в модуле Winlogon.exe имеется код по умолчанию, который будет выполнен, если библиотека не предоставит их реализацию.

Winlogon взаимодействует с GINA следующим образом:

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

В основе всех этих механизмов лежит понятие secure attention sequence (SAS).

Все эти функции поддерживают только модальные диалоги. Затем созданные с их помощью диалоговые окна получают специфическое для Winlogon сообщение WLX_WM_SAS. wParam для этого сообщения может принимать значения, описанные в Таблице 4 .

Как реагировать на сообщения WLX_SAS_TYPE_CTRL_ALT_DEL, WLX_SAS_TYPE_SC_INSERT, WLX_SAS_TYPE_SC_REMOVE - решать разработчику. В принципе, не требует обязательной обработки и сообщение WLX_SAS_TYPE_USER_LOGOFF. Но с тайм-аутами несколько сложнее. Все диалоговые окна, кроме выводимого функцией WlxDisplaySASNotice, которая представляет приветствие Windows и предлагает начать регистрацию с нажатия кнопок Ctrl-Alt-Del, должны завершаться с помощью стандартной функции EndDialog. Возвращаемое же значение должно быть WLX_DLG_INPUT_TIMEOUT для WLX_SAS_TYPE_TIMEOUT и WLX_DLG_SCREEN_SAVER_TIMEOUT - для WLX_SAS_TYPE_SCRNSVR_TIMEOUT (см. Листинг 5). А вот функция диалога из WlxDisplaySASNotice может отработать эти сообщения проще, как показано в .

В остальном же это самые обычные диалоговые окна, к которым применимы обычные функции. Для работы с диалогами GINA я написал класс CGinaDlg, код которого приведен в Листинге 7 . Все диалоги в демонстрационной программе наследуют от данного класса и выглядят как белые эллипсы. Я не думаю, что этот код требует дополнительных комментариев.

Регистрация пользователя

Смысл регистрации заключается в получении информации, идентифицирующей пользователя. Заметим, что информацией, идентифицирующей пользователя, может быть не только привычный набор, состоящий из имени пользователя, пароля и имени домена, в котором пользователь будет регистрироваться. Им может быть и цифровой сертификат, и битовые образы отпечатка пальца или рисунка сетчатки глаза. Для того чтобы предоставить GINA DLL возможность ввода и получения маркера доступа - ключевого объекта при регистрации пользователя, о котором мы поговорим ниже, - Winlogon вызывает функцию GINA WlxLoggedOutSAS. Результатом выполнения этой функции должны быть полученные маркер доступа, SID и профиль пользователя. Посмотрим, как все это происходит.

В первую очередь создается диалоговое окно, в котором пользователю предлагается «рассказать о себе».

В результате мы получаем имя пользователя, пароль и домен, в котором хранится учетная запись пользователя. Что дальше? Можно выбрать простой способ и вызвать функцию LogonUser. Но, хотя мы и получим необходимый нам маркер, возможности этой функции крайне невелики. Windows предоставляет специальную службу - Local Security Authority, - предназначенную для аутентификации и авторизации пользователей.

Процесс регистрации пользователя заключается в открытии сессии LSA, что происходит в функции WlxLoggedOutSAS, и дальнейшей активизации оболочки, которая осуществляется в функции WlxActivateUserShell.

Посмотрим, как формируется сессия пользователя, (см. Листинг 8). Функция WlxLoggedOutSAS, прежде всего, должна создать окно, в котором пользователь введет свое имя, пароль и домен, где хранится информация об учетной записи.

Значение ShutdownWithoutLogon может быть равно 1 или 0. В первом случае пользователь может завершить работу компьютера без регистрации. Для этого в окне ввода регистрационной информации добавляется кнопка Shutdown, как сделано в демонстрационном модуле. После нажатия пользователем этой кнопки функция WlxLoggedOutSAS может вернуть в Winlogon значение WLX_SAS_ACTION_SHUTDOWN_POWER_OFF, если PowerdownAfterShutdown равно 1, и WLX_SAS_ACTION_SHUTDOWN, если это значение равно 0, после чего компьютер выключится. Если сделать ShutdownWithoutLogon равным 0, кнопка Shutdown становится недоступной.

Кроме того, в параметрах реестра DefaultUserName и DefaultDomainName находятся строковые данные, которые можно показать в соответствующих полях ввода. Это несколько ускорит процесс регистрации, но и уменьшит степень защищенности рабочей станции.

Хранители экрана

Я немного рассказал о работе с хранителями экрана, когда рассматривал диалоги в GINA DLL. Но на этом разговор не закончен. Когда мы в течение определенного времени отвлекаемся от любимого занятия, а именно - терзания клавиатуры и беспорядочных перемещений манипулятора «мышь», загружается процесс хранителя экрана. Это происходит при заданных настройках Windows. И в случае, если установлен флаг защиты хранителя экрана паролем, GINA получает сообщение о начале его работы. Winlogon вызывает необязательную для реализации функцию

BOOL WlxScreenSaverNotify(PVOID pWlxContext,BOOL *pSecure).

Я уже упоминал о том, что для необязательных функций выполняется код по умолчанию. Для этой функции код по умолчанию, взятый из MSDN, приведен в . Вообще говоря, проверка параметра *pSecure необязательна, так как эта функция вызывается только в том случае, если хранитель экрана защищен паролем. Но инженеры Microsoft считают, что делать надо так. Этот параметр возвращает TRUE, если после переключения на программу хранителя экрана требуется запрашивать пароль, и FALSE - в противном случае. Функция WlxScreenSaverNotify возвращает TRUE, если хранитель экрана надо загружать, и FALSE - если нет. Если хранитель экрана задействован, то процесс хранителя экрана запускается на отдельном рабочем столе и продолжается до тех пор, пока пользователь не начинает использовать устройства ввода. После чего станция переключается на рабочий стол Winlogon и вызывается функция WlxDisplay LockedNotice. Сценарий ее работы я рассматриваю ниже.

Замечу, что в демонстрационном примере я не стал реализовывать функцию WlxScreenSaverNotify.

Обработчик SAS для незаблокированной рабочей станции

Если в ходе работы пользователь нажимает Ctrl-Alt-Del, Winlogon переключает рабочий стол на стол Winlogon и вызывает функцию WlxLoggedOnSAS, обязательную для реализации в GINA DLL. Внутри этой функции создается диалог, в котором пользователь может выбрать какое-нибудь действие. Для вызова стандартного менеджера задач, завершения сеанса, блокировки или выключения компьютера функция должна вернуть соответствующие значения: WLX_SAS_ACTION_TASKLIST, WLX_SAS_ACTION_LOGOFF, WLX_SAS_ACTION_LOCK_WKSTA и WLX_SAS_ACTION_SHUT DOWN_POWER_OFF. Но некоторые функции можно реализовать внутри GINA DLL, например смену пароля.

Смена пароля

Смена пароля в GINA происходит внутри функции WlxLoggedOnSAS. Для изменения пароля используется функция NetUserChangePassword(). Первые два параметра этой функции - имя пользователя и домен. Для их получения я использую маркер, сохраненный при регистрации пользователя. Как это делается, показано в Листинге 10 . Для получения SID пользователя по маркеру я написал дополнительную функцию GetTokenUserInfo, показанную в Листинге 11 .

Ещк два параметра - старый и новый пароль - вводятся пользователем в соответствующее диалоговое окно. После успешной смены пароля функция WlxLoggedOnSAS должна вернуть Winlogon значение WLX_SAS_ACTION_PWD_CHANGED, извещающее сетевых провайдеров о смене пароля.

Разблокировка рабочей станции

Для разблокировки рабочей станции Winlogon вызывает необходимую в реализации GINA DLL функцию WlxWkstaLockedSAS. Поставляемая с операционной системой библиотека GINA предоставляет стандартный сценарий разблокирования рабочей станции. Это может сделать либо пользователь, который ее заблокировал, либо член локальной группы администраторов. Во втором случае происходит завершение текущего сеанса. Конечно, в собственной реализации модуля можно избрать какой-нибудь другой сценарий. Например, разрешать разблокировку только зарегистрированному пользователю. Но здесь мы рассмотрим вариант, предлагаемый компанией Microsoft.

Итак, в первую очередь мы должны предоставить пользователю возможность ввести свои идентификационные данные. Это делается тем же способом, который использовался при регистрации пользователя. Только одно отличие: в функции LsaLogonUser для параметра SECURITY_LOGON_TYPE используется значение Unlock. После этого вызова мы получаем маркер.

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

Теперь нам нужно только получить для этого маркера и для маркера, сохраненного после регистрации, SID пользователя и сравнить их. Если значения SID совпадут, значит, пользователь тот же, и рабочую станцию можно разблокировать. Для этого достаточно вернуть значение WLX_SAS_ACTION_UNLOCK_WKSTA из функции WlxWkstaLockedSAS (см. Листинг 12).

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

Александр Эпштейн - независимый разработчик и консультант по проблемам низкоуровневого программирования; руководил департаментами разработки программного обеспечения в нескольких крупных российских компаниях. С ним можно связаться по адресу: [email protected] .

Литература

David A. Solomon, Mark E. Russinovich Insude for Microsoft Windows 2000, Third Edition Microsoft Press (Дэвид Соломон, Марк Русинович «Внутреннее устройство Microsoft Windows 2000». - Русская редакция, 2001)

Sven B. Schreiber Undocumented Windows 2000 secrets. A programming cookbook. Addison-Wesley 2001

Keith Brown Handle Logons in Windows NT and Windows 2000 with Your Own Logon Session Broker

Листинг 1. Проверка версии WinLogon.

BOOL WINAPI WlxNegotiate(DWORD dwWinLogonVersion,PDWORD pdwDllVersion) { if(dwWinLogonVersion

Листинг 3. Используемая в данной реализации GINA структура контекста.

typedef struct _tagGINA_CONTEXT { HANDLE hWlx; LPWSTR wszStation; PWLX_DISPATCH_VERSION_1_3 pWlxFuncs; HANDLE hDllInstance; HANDLE hUserToken; SID sid; HWND hWndOwner; } GINA_CONTEXT, *LPGINA_CONTEXT, *PGINA_CONTEXT;

Листинг 6. Обработка сообщений о тайм-аутах.

case WLX_SAS_TYPE_TIMEOUT: EndDialog(hWnd,WLX_DLG_INPUT_TIMEOUT); nRet = TRUE; break; case WLX_SAS_TYPE_SCRNSVR_TIMEOUT: EndDialog(hWnd,WLX_DLG_SCREEN_SAVER_ TIMEOUT); nRet = TRUE; break; Листинг 5. Возвращаемые значения. case WLX_SAS_TYPE_TIMEOUT: case WLX_SAS_TYPE_SCRNSVR_TIMEOUT: nRet = wParam; break;

Листинг 9. Код по умолчанию, который обрабатывается обработчиком сообщения от хранителя экрана.

BOOL DefaultScreenSaverNotify(PVOID pWlxContext, BOOL *pSecure) { if (*pSecure) { *pSecure = WlxIsLockOk (pWlxContext); } return(TRUE); }

Большинство web-сайтов работают в режиме анонимного доступа. Они содержат информацию, которую могут просматривать все желающие, и поэтому не проводят аутентификацию пользователей. Web-приложения ASP.NET предоставляют анонимный доступ к серверным ресурсам посредством назначения учетной записи анонимному пользователю. По умолчанию учетная запись для анонимного доступа имеет имя в виде IUSER _ имя компьютера.

ASP.NET исполняет web-приложения под учетной записью ASPNET. Это означает, что при выполнении задачи, не предусмотренной привилегиями пользователя (например, запись файла на диск), приложение получает отказ в доступе.
Идентификация пользователей применяется в тех случаях, когда нужно предоставить доступ к разделам web -приложения только для определенных пользователей. Это может быть Internet -магазины, форумы, закрытые разделы в корпоративных Intranet -сайтах и так далее.
Безопасность в приложениях ASP.NET основана на трех операциях:

Аутентификация – процесс идентификации пользователя для предоставления доступа к какому-то ресурсу приложения (разделу сайта, странице, базе данных, …). Аутентификация основана на проверке сведений о пользователе (например, имени и пароля);
Авторизация – процесс предоставления доступа пользователю на основе данных аутентификации;
Олицитворение (impersonalisation) – предоставление серверному процессу ASP.NET прав доступа клиента.

Существует три способа аутентификации пользователей в приложениях ASP.NET:

аутентификация Windows - применяется для идентификации и авторизации пользователей в зависимости от привилегий учетной записи пользователя. Работает аналогично обычным механизмам сетевой безопасности Windows и выполняется контроллером домена;
аутентификация Forms - пользователь вводит логин и пароль в Web -форме, после чего авторизация происходит по списку пользователей, хранящемуся, например, в базе данных. Применяется на большинстве Internet-сайтов при регистрации в Inernet -магазинах, форумах, пр;
аутентификация Passport - все пользователи имеют единое имя и пароль, используемые для сайтов, использующих данный тип авторизации. Пользователи регистрируются в службе Microsoft Passport.

Важно отметить, что аутентификация ASP.NET применяются только для web -форм (.aspx -файлы), контролов (.ascx -файды) и прочих ресурсов ASP.NET. HTML-файлы не входят в этот список. Для авторизации доступа к HTML -файлам нужно их зарегистрировать вручную!
Тип аутентификации указывается в конфигурационном файле Web.config:

По умолчанию применяется тип аутентификации Windows. Значение None имеет смысл устанавливать если используется собственная схема аутентификации или анонимный доступ (для повышения производительности).
Аутентификация Windows. Существует 4 типа аутентификации Windows: обычная (basic), краткая (digest), встроенная (integated) и на основе клиентских сертификатов SSL. Обычную и краткую аутентификацию применяют для идентификации имени пользователя и пароля, указываемом в диалоговом окне. Они хорошо работают в Internet , так как данные передаются по HTTP. Базовая аутентификация передает пароль и имя пользователя в кодировке Base 64, которую легко раскодировать. Для повышения безопасности можно использовать базовую аутентификацию совместно с SSL. Базовую аутентификация поддерживают большинство браузеров.
Краткая аутентификация является более безопасной, так как пароль шифруется по алгоритму MD 5. Она поддерживается браузерами Internet Explorer 5.0 и выше, либо на клиентской машине должен быть установлен. NET Framework. Кроме этого, учетные записи пользователей должны храниться в Active Directory.
Встроенная аутентификация применяется для идентификации учетных записей Windows и не может применяться в Internet , так как клиент и сервер должны пройти проверку контроллером домена. При этом пароли по сети не передаются, что увеличивает безопасность приложения. Этот тип аутентификации блокируется файрволами и работает только с Internet Explorer. Встроенная аутентификации немного медленнее, чем базовая или краткая.
Применение сертификатов SSL так же обычно применяется в Intranet , т.к. требует раздачи цифровых сертификатов. При этом типе аутентификации пользователям не нужно регистрироваться. Сертификаты можно сопоставить учетным записям пользователей в домене или Active Directory.

Для указания способа аутентификации нужно выполнить следующие действия:
1. Запустить диспетчер IIS
2. Щелкнуть правой кнопкой мыши по приложению и выбрать в контекстном меню Свойства.
3. В появившимся диалоге перейти на вкладку Безопасность каталога и нажать кнопку Изменить в разделе Анонимный доступ и проверка подлинности .

4. В диалоге Методы проверки подлинности указать тип аутентификации.

5. Указать права доступа к папке или отдельным файлам в папке Web -приложения. Обязательно нужно разрешить доступ для пользователя ASPNET.

В данном случае разрешен доступ для пользователя DENIS и запрещен доступ для всех остальных. Вместо имени пользователя может быть и название роли, к которой принадлежат пользователи – администраторы, менеджеры, …:

Если мы хотим защитить он неаутентифицированных пользователей папку полностью (например, папку, содержащую формы для администрирования сайта), то нужно разместить в ней файл Web.config с таким содержанием (cимвол «?» означает анонимных неавторизированных пользователей):

Если же мы хотим защитить только один файл (например, для подтверждения заказа в Internet -магазине), то в Web.config из корневой папки нужно добавить такие строки:

Приложение извлекает данные пользователей с помощью свойства Identity класса User. Это свойство возвращает объект, содержащий имя пользователя и роль.

bool authenticated = User.Identity.IsAuthenticated ;
string name = User.Identity.Name;
bool admin = User.IsInRole("Admins");

Forms-аутентификация

При использовании Forms-аутентификации запрос параметров регистрации (например, логина и пароля) происходит в web-форме. Регистрационная страница указывается в файле Web.config. При первом обращении к защищаемым страницам ASP.NET перенаправляет пользователя на страницу для ввода пароля. При успешной регистрации аутентификационные данные сохраняются в виде cookie и при повторном обращении к защищенным страницам регистрация не требуется.
Для того, чтобы использовать Forms-аутентификацию в файле Web.config в корневой папке приложения нужно указать страницу для ввода пароля:

При попытке просмотра защищенной страницы ASP.NET проверяет, есть ли аутентификационных cookie в запросе. Если cookie нет, то запрос перенаправляется на страницу для регистрации, если есть - ASP.NET дешифрует cookie и извлекает из него регистрационную информацию.

На форме находятся поля для ввода логина и пароля и флажок для сохраняемой регистрации. При нажатии кнопки «Войти» происходит поиск пользователя с таким логином и паролем. Если такой пользователь найден, вызывается функция FormsAuthentication.RedirectFromLoginPage (), в которой указывается идентификатор пользователя и флаг для сохраняемой регистрации. Если же нет – выводится сообщение об ошибке.

protected void btnLogin_Click(object sender, System.EventArgs e)
{
if (!IsValid) // проверяем правильность введенных данных
return;

OleDbConnection connection = GetDbConnection();

Try
{
connection.Open();

OleDbCommand command = new OleDbCommand(string.Format("SELECT id FROM Customers WHERE login="{0}" AND password="{1}"", login, password), connection);

OleDbDataReader reader = command.ExecuteReader();
if (!reader.Read()) // пароль или логин неверны
{
lblError.Text = "Неверный пароль – попробуйте еще раз";
return ;
}

String id = return reader.GetInt32(0).ToString();

FormsAuthentication.RedirectFromLoginPage(id, chkbRememberLogin.Checked);
}
catch (OleDbException ex)
{
lblError.Text = "Ошибка базы данных";
}
finally
{
connection.Close();
}
}

Аутентификации на основе ролей

Для аутентификации на основе ролей применяется атрибут roles тега allow. Например, если мы хотим запретить доступ всем, кроме пользователей из группы Admin , мы должны вставить такие строки в файл Web.config.

Затем при каждом запросе нужно связывать учетные записи пользователей и роли. Обычно это делается в обработчике события AuthenticateRequest в файле Global.asax.

protected void Application_AuthenticateRequest(Object sender, EventArgs e)
{
HttpApplication appl = (HttpApplication)sender;

If (appl.Request.IsAuthenticated && appl.User.Identity is FormsIdentity)
{
FormsIdentity identity = (FormsIdentity)appl.User.Identity;

DataTable tblUsers = (DataTable)Application["UsersTable"];
appl.Context.User = new GenericPrincipal(identity,
new string {(string)(tblUsers.Rows.Find(identity.Name)["Role"]) });
}
}

В коде проверяется тип аутентификации пользователя и то, что он уже зарегистрирован. Имя пользователя извлекается из cookie свойством Name. Таблица с именами пользователей и их ролями для повышения быстродействия была сохранена в объекте Application. Из этой таблицы и находим роль пользователя, которую сохраняем в объекте GenericPrincipal.

Параметры аутентификации

Если второй параметр функции RedirectFromLoginPage () равен false , то время жизни сеансового cookie , генерируемого ASP.NET , равно по умолчанию 30 минутам. Для изменения этого интервала служит параметр timeout тега forms в файле Web.config. Установим время действия аутентификации в 3 часа.

Когда сеансовый cookie возвращается в следующих после регистрации запросах, он автоматически обновляется, если время жизни истекло больше чем на половину. Время же жизни сохраняемых cookie равно 50 годам.
Можно указать имя аутентификационных cookie , поместив его в атрибут name (имя по умолчанию - ASPXAUTH):

По умолчанию аутентификацонные cookie шифруются и проверяются. Уровень защиты можно указать через атрибут protection , значение по умолчанию которого All. Значение Validation предписывает только проверку cookie , а значение Encript – только шифрование. Полностью отключить защиту можно указав значение None. Отключать защиту имеет смысл если данные передаются по протоколу HTTPS.

Сброс forms-аутентификации

Сброс регистрации можно увидеть на многих сайтах. Для сброса аутентификации применяется метод FormsAuthentication.SignOut (). Он устанавливает дату окончания действия cookie на прошедшее время и cookie автоматически уничтожается.

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

При аутентификации Passport пользователи могут входить на разные web -сайты пользуясь единым удостоверением службы Microsoft Passport. Это освобождает пользователя от регистрации на каждом сайте, а сами сайты получают сведения о пользователе из профиля, хранимого Microsoft.

Для использования Passport аутентификации в web -приложении нужно установить Passport SDK. Passport SDK предоставляется бесплатно для тестирования, но для коммерческого использования на сайте необходимо приобретать лицензию.
При обращении к приложению с Passport аутентификацией проверяется наличие cookie с данные Passport. Если такого файла нет, пользователь перенаправляется на страницу для регистрации Passport.
Для включения данного режима аутентификации в файле Web. config нужно указать следующее:

Для обязательной регистрации всех посетителей сайта в разделе autorization нужно запретить доступ неавторизированным пользователем:

Получить доступ к сведениям о пользователе можно с помощью события PassportAuthentication _ OnAuthenticate в файле Global.asax:

protected void PassportAuthentication_OnAuthenticate(Object sender, PassportAuthenticationEventArgs e)
{
System.Web.Security.PassportIdentity id = e.Identity;
if(id.IsAuthenticated)
{
Session["PassportID"] = e.Identity.Name;
Session["Name"] = e.Identity["FirstName"] + e.Identity["LastName":];
Session["Email"] = e.Identity["PrefferedEmail"];
}
}

Кондратьев Денис

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

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

Для начала внесем ясность в термины. Многие путают понятия аутентификации и авторизации, хотя это различные процедуры.

Аутентификация - происходит от английского слова authentication , которое можно перевести как идентификация или проверка подлинности . Это полностью отражает суть процесса - проверка подлинности пользователя, т.е. мы должны удостовериться, что пользователь, пытающийся получить доступ к системе именно тот, за кого себя выдает.
Авторизация - перевод слова authorization означает разрешение , т.е. проверка прав доступа к какому-либо объекту. Процесс авторизации может быть применен только к аутентифицированному пользователю, так как перед тем, как проверять права доступа, мы должны выяснить личность объекта, которому мы собираемся предоставить какие-либо права.

Чтобы проще представить себе этот процесс проведем простую аналогию. Вы находитесь за границей и вас останавливает полицейский, вы предъявляете свой паспорт. Полицейский проверяет данные в паспорте и сверяет фотографию - это процесс аутентификации. Убедившись, что вы это вы, полицейский просит показать визу - это процесс авторизации, т.е. вашего права здесь находиться.

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

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

Локальная аутентификация

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

Затем служба LSA обращается к диспетчеру учетных записей безопасности (SAM) и сообщает ему имя пользователя. Диспетчер обращается в базу SAM и извлекает оттуда хэш пароля указанного пользователя, сгенерированный при создании учетной записи (или в процессе смены пароля).

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

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

LAN Manager (LM)

Протокол LAN Manager возник на заре зарождения локальных сетей под управлением Windows и впервые был представлен в Windows 3.11 для рабочих групп , откуда перекочевал в семейство Windows 9.х . Мы не будем рассматривать этот протокол, так как в естественной среде он уже давно не встречается, однако его поддержка, в целях совместимости, присутствует до сих пор. И если современной системе поступит запрос на аутентификацию по протоколу LM, то, при наличии соответствующих разрешений, он будет обработан.

Что в этом плохого? Попробуем разобраться. Прежде всего разберемся, каким образом создается хэш пароля для работы с протоколом LM, не вдаваясь в подробности обратим ваше внимание на основные ограничения:

Пароль регистронезависимый и приводится к верхнему регистру.
Длина пароля - 14 символов, более короткие пароли дополняются при создании хэша нулями.
Пароль делится пополам и для каждой части создается свой хэш по алгоритму DES.

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

А теперь самое интересное, LM-хэш, в целях совместимости, создается при вводе пароля и хранится в системах по Windows XP включительно. Это делает возможной атаку, когда системе целенаправленно присылают LM-запрос и она его обрабатывает. Избежать создания LM-хэша можно изменив политику безопасности или используя пароли длиннее 14 символов. В системах, начиная с Windows Vista и Server 2008, LM-хэш по умолчанию не создается.

NT LAN Manager (NTLM)

Новый протокол аутентификации появился в Windows NT и благополучно, с некоторыми изменениями, дожил до наших дней. А до появления Kerberos в Windows 2000 был единственным протоколом аутентификации в домене NT.

Сегодня протокол NTLM, точнее его более современная версия NTLMv2, применяются для аутентификации компьютеров рабочих групп, в доменных сетях Active Directory по умолчанию применяется Kerberos, однако если одна из сторон не может применить этот протокол, то по согласованию могут быть использованы NTLMv2, NTLM и даже LM.

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

Как происходит работа по протоколу NTLM? Рассмотрим следующую схему:

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

Чтобы получить доступ к ресурсу клиент направляет серверу запрос с именем пользователя. В ответ сервер передает ему случайное число, называемое запросом сервера . Клиент в свою очередь шифрует данный запрос по алгоритму DES, используя в качестве ключа NT-хэш пароля, однако, несмотря на то, что NT-хэш 128-битный, в силу технических ограничений используется 40 или 56 битный ключ (хеш делится на три части и каждая часть шифрует запрос сервера отдельно).

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

В случае доменной аутентификации процесс протекает несколько иначе. В отличие от локальных пользователей, хэши паролей которых хранятся в локальных базах SAM, хэши паролей доменных пользователей хранятся на контроллерах доменов. При входе в систему LSA отправляет доступному контроллеру домена запрос с указанием имени пользователя и имени домена и дальнейший процесс происходит как показано выше.

В случае получения доступа к третьим ресурсам схема также немного изменяется:

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

Как видим, хэш пароля ни при каких обстоятельствах по сети не передается. Хэш введенного пароля хранит служба LSA, хэши паролей пользователей хранятся либо в локальных хранилищах SAM, либо в хранилищах контроллера домена.

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

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

NTLMv2

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

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

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

Запрос сервера объединяется с запросом клиента и от этой последовательности вычисляется HMAC-MD5 хэш. После чего от данного хэша берется еще один HMAC-MD5 хэш, ключом в котором выступает NT-хэш пароля пользователя. Получившийся результат называется NTLMv2-ответом и вместе с запросом клиента пересылается серверу.

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

Сервер, получив NTLMv2-ответ и запрос клиента, объединяет последний с запросом сервера и также вычисляет HMAC-MD5 хэш, затем передает его вместе с ответом контроллеру домена. Тот извлекает из хранилища сохраненный хэш пароля пользователя и производит вычисления над HMAC-MD5 хешем запросов сервера и клиента, сравнивая получившийся результат с переданным ему NTLMv2-ответом. В случае совпадения серверу возвращается ответ об успешной аутентификации.

При этом, как вы могли заметить, NTLMv2, также, как и его предшественник, не осуществляет взаимную проверку подлинности, хотя в некоторых материалах в сети это указывается.

Настройки безопасности

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

За выбор протокола аутентификации отвечает локальная или групповая политика. Откроем редактор политик и перейдем в Конфигурация компьютера - Конфигурация Windows - Политики безопасности - Локальные политики - Параметры безопасности , в этом разделе найдем политикуСетевая безопасность: уровень проверки подлинности LAN Manager .

В этом же разделе находится политика Сетевая безопасность: не хранить хэш-значения LAN Manager при следующей смене пароля , которая запрещает создание LM-хэша, по умолчанию активна начиная с Vista / Server 2008.

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

Эти же значения можно задать через реестр, что удобно в сетях уровня рабочей группы, для этого в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lsa нужно создать параметр DWORD с именем LmCompatibilityLevel , который может принимать значения от 0 до 5. Рассмотрим их подробнее:

Наименование настройки	Клиентский компьютер	Контроллер домена	Lm Compatibility Level
Отправлять LM- и NTLM-ответы	Клиентские компьютеры используют LM и NTLMаутентификацию, и никогда не используют сеансовую безопасность NTLMv2.		0
Отправлять LM- и NTLM- использовать сеансовую безопасность NTLMv2	Клиентские компьютеры используют LM и NTLM аутентификацию, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	1
Отправлять только NTLM-ответ	Клиентские компьютеры используют проверку подлинности NTLMv1, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	2
Отправлять только NTLMv2-ответ		Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2.	3
Отправлять только NTLMv2-ответ. Отказывать LM.	Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена отказываются принимать аутентификацию LM, и будут принимать только NTLM и NTLMv2.	4
Отправлять только NTLMv2-ответ. Отказывать LM и NTLM.	Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее.	Контроллеры домена отказываются приниматьаутентификацию LM иNTLM, и будут принимать только NTLMv2.	5

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