Как происходит аутентификация в домене windows - Доктор Windows

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

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

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

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

Аутентификация — происходит от английского слова 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.

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

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

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

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

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

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

Источник

Протоколы, составляющие основу процедуры

Аутентификация — это незаменимая процедура для каждого пользователя, компьютера и служебной учетной записи Windows, но ее механизм не изучается системными администраторами досконально. Каждый знает, что для регистрации в компьютере необходимо указать верный пароль, но многим ли известно, что происходит потом? Аутентификация Windows и связанные с ней протоколы активизируются каждый раз, когда пользователь, компьютер или служба регистрируются локально или на контроллере домена (DC). В данной статье речь пойдет сначала об основных принципах аутентификации Windows, а затем о связанных с ней протоколах. В заключение приводятся краткие рекомендации по повышению надежности процедуры аутентификации в сети Windows.

Аутентификация: общие принципы

Аутентификация представляет собой один из компонентов любой компьютерной системы управления доступом. Как показано на экране 1, системы управления доступом обеспечивают идентификацию, аутентификацию, авторизацию и отчетность.

Рисунок 1. Механизмы управления доступом и аутентификация Windows

Идентификация (identification). В процессе идентификации используется набор данных, который уникально идентифицирует объект безопасности (например, пользователя, группу, компьютер, учетную запись службы) в общей службе каталогов. Служба каталогов, такая как Active Directory (AD), позволяет уникально идентифицировать объекты, подобно тому как DNS удостоверяет, что два человека не могут иметь одинаковые адреса электронной почты. Во внутренних механизмах Windows используются SID, глобально уникальные идентификаторы (globally unique identifier, GUID) и другие уникальные тэги. В большинстве случаев для идентификации достаточно ввести уникальное имя учетной записи, такое как Rgrimes. В большом лесу AD приходится применять полные имена пользователей (user principal name, UPN), например rgrimes@banneretcs.com. При использовании смарт-карт субъект безопасности может представить свой цифровой сертификат или ключ.

Аутентификация или проверка подлинности (authentication). После того как субъект безопасности вводит с клавиатуры или иным способом предоставляет необходимую для идентификации информацию (например, имя пользователя, маркер безопасности), он должен ввести с клавиатуры или представить частную информацию для аутентификации (например, пароль и PIN-код). В Windows субъект безопасности вводит эту информацию на экране регистрации с помощью программ Microsoft Graphical Identification and Authentication DLL (msgina.dll) и Winlogon.exe. Протокол аутентификации и механизм системы кодируют представленную информацию на настольном компьютере и передают запрос аутентификации. Служба аутентификации Windows может быть базой данных SAM или AD. База данных SAM обслуживает локальные процедуры регистрации и регистрацию на контроллерах домена Windows NT 4.0. AD аутентифицирует запросы в Windows 2000 или доменах более поздних версий этой операционной системы. Протокол аутентификации (например, LAN Manager, NT LAN Manager, NTLM, NTLMv2, Kerberos) используется для транспортировки запросов аутентификации и последующих транзакций между экраном регистрации и службой аутентификации. Чуть ниже каждый протокол аутентификации будет рассмотрен отдельно.

Авторизация (authorization). Если служба аутентификации удостоверяет комбинацию идентификатора и «секретных» данных аутентификации, то подлинность субъекта безопасности считается успешно подтвержденной. Затем система собирает информацию о членстве субъекта безопасности (т. е. пользователя) в группах. Нередко пользователь принадлежит к нескольким точно определенным группам — локальным (local), доменным (domain local), глобальным (global) и универсальным (universal) — в результате обычных процедур назначения членства. Система сверяет локальные группы с локальной базой данных SAM и проверяет локальные и глобальные группы на контроллерах DC в домашнем домене пользователя, а также универсальные группы на DC, который содержит глобальный каталог Global Catalog. Прямо или косвенно система собирает все сведения о членстве в группах, чтобы получить информацию о разрешениях безопасности.

Сразу после аутентификации система собирает идентификаторы SID учетной записи и сведения о членстве в группах в объекте, называемом маркером доступа (access token). Возможно, пользователю придется выйти и вновь зарегистрироваться в системе, чтобы новые разрешения безопасности вступили в силу. Если пользователю нужно получить доступ к объекту (например, файлу, папке, принтеру, разделу реестра), защищенному разрешениями NTFS, то процесс (например, Windows Explorer), выступающий от имени пользователя, предоставляет свой маркер доступа. Каждый объект NTFS располагает списком элементов управления доступом (access control entry, ACE), которые, в сущности, представляют собой знакомые разрешения NTFS (например, Allow Read, Allow Write). Набор элементов ACE, назначенных пользователям и группам, составляет список управления доступом (ACL) данного объекта. Примечательно, что ACL объекта представлен разрешениями безопасности, которые можно просмотреть в Windows Explorer.

Маркер доступа, содержащий учетную запись и группы, с которыми связан пользователь, определяет эффективные разрешения пользователя. Процесс авторизации заключается в разрешении или отказе в доступе к определенному объекту на основе сравнения маркера доступа с ACL объекта. Авторизацию обеспечивает Security Reference Monitor системы Windows (экран 1). В примере, показанном на экране 1, пользователь имеет разрешения Read, Write и Modify. Однако группа Everyone, к которой принадлежит пользователь, не имеет разрешения Modify. Члены других групп располагают разрешениями Read и Modify, но разрешение Deny группы Everyone отменяет разрешение Modify. Объект также располагает списками ACL, которые отказывают в разрешении Full Control группе HR, но пользователь к этой группе не принадлежит. Таким образом, эффективные разрешения пользователя по отношению к объекту на экране 2 — Read и Write.

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

Задачи протокола

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

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

Компьютер получает данные для идентификации и аутентификации от пользователя и запрашивает аутентификацию на соответствующем сервере.
Сервер аутентификации генерирует случайное произвольное значение (называемое запросом — challenge) и посылает его запросчику.
Запросчик получает запрос и производит над ним и скрытой формой пароля математические операции, а затем передает результат (называемый ответом — response) серверу аутентификации.
Сервер аутентификации также выполняет математические манипуляции с запросом методом, идентичным используемому на рабочей станции, и сравнивает результат с полученным ответом. Если результаты совпадают, то запросчик считается успешно аутентифицированным.

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

Локальная и доменная регистрация

При регистрации пользователя одна из первых задач Windows — определить, относится ли процедура только к локальной машине или к учетной записи домена. Пользователи, регистрирующиеся от имени локальной учетной записи, имеют доступ только к ресурсам своего компьютера и только если информация об учетной записи пользователя содержится в локальной базе данных SAM. Если пользователям нужно обратиться к ресурсам на удаленном компьютере без аутентификации в домене, то их учетные записи должны быть продублированы в локальной базе данных SAM каждого доступного компьютера. Учетные записи в каждом компьютере-участнике должны быть синхронизированы (одинаковые имена регистрации, пароли и сроки действия учетных данных на всех машинах). В противном случае положение значительно усложняется. Трудно обслуживать одноранговые (P2P) сети средних размеров, в которых применяются только локальные процедуры регистрации.

На DC не распространяется требование синхронизации нескольких учетных записей пользователей на разных компьютерах. При доменной аутентификации компьютеры, зарегистрированные в домене, отыскивают контроллеры DC, чтобы предъявить учетные данные доменной учетной записи пользователя при запросах аутентификации. Таким образом, если удаленный пользователь пытается получить доступ к локальному ресурсу какой-нибудь машины, то этот компьютер просит DC проверить идентичность запрашивающего пользователя. Учетные записи пользователя домена располагаются только на DC и создаются лишь один раз. Любой компьютер-участник, которому нужно удостоверить учетную запись в домене, может обратиться к контроллерам DC в любое время. Проблемы синхронизации имен регистрации, паролей и сроков их действия не возникает, так как учетные данные и управление учетной записью осуществляются только в одном месте — на DC. Независимо от типа регистрации (локальной или доменной), Windows должна аутентифицировать запрос пользователя.

Протоколы аутентификации Windows

Как отмечалось выше, в Windows применяется четыре основных протокола аутентификации: LAN Manager, NTLM, NTLMv2 и Kerberos. LAN Manager появился во времена DOS и продолжал использоваться с первыми версиями Windows. NTLM был выпущен вместе с NT. Новшеством пакета обновлений NT Server 4.0 Service Pack 4 (SP4) стал NTLMv2, а Windows 2000 привнесла Kerberos. По умолчанию все компьютеры с Windows 2000 и более новыми операционными системами совместимы со всеми четырьмя протоколами аутентификации. Передавая в эти системы соответствующие команды, другие рабочие станции и серверы могут выбирать протокол для обработки запроса аутентификации. Системы Windows 9x и более поздние с полным набором программных исправлений совместимы с LM, NTLM и NTLMv2. На платформе Microsoft Kerberos может использоваться только клиентами Windows 2000 (или более новыми) при обращениях в домены Windows 2000 (и выше). Компьютер с Windows 2000 или более новой версией операционной системы должен иметь Kerberos и по крайней мере еще один из протоколов аутентификации.

Исследования в области безопасности показали, что более старые протоколы (LM и NTLM) уязвимы в случае прослушивания и атак с разгадыванием пароля.

Поэтому, если возможно, рекомендуется использовать только Kerberos и NTLMv2. Чтобы убедиться в правильности этого совета, следует оценить возможности каждого протокола.

LAN Manager

Компания IBM разработала протокол LAN Manager, применив его в ранних версиях Windows и сетях Windows. Как все протоколы аутентификации Microsoft, LAN Manager генерирует хеш паролей (LM hash), который хранится и используется отправителем и получателем в процессе аутентификации. LAN Manager формирует LM-хеши, изменяя все буквы пароля на верхний регистр, разбивая пароль на две 7-символьные половины, а затем шифруя. В дальнейшем LM-хеш используется в нескольких последовательных операциях, аналогичных процессу запрос—ответ, описанному выше.

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

пароли могут состоять из ограниченной последовательности 128 символов ASCII;
длина пароля не превышает 14 символов;
если пароль содержит менее 14 символов, то отсутствующие символы заменяются легко угадываемой хешированной формой, что позволяет точно определить длину пароля;
перед кэшированием LAN Manager преобразует все буквенные символы пароля в верхний регистр.

Почему LAN Manager до сих пор не вышел из употребления? В целях обратной совместимости он активен по умолчанию во всех компьютерах Windows, в том числе Windows Server 2003. В новейших базах данных аутентификации Windows слабый LM-хеш хранится наряду с более надежными просто на случай, если придется выполнить транзакцию LAN Manager. Если на предприятии не используются другие приложения, требующие аутентификации LAN Manager, то можно (и нужно) LAN Manager отключить.

NTLM

С появлением NT компания Microsoft спроектировала и развернула более надежный протокол аутентификации NTLM. В NTLM используется более эффективный алгоритм аутентификации, который создает более надежный хеш паролей (NTLM hash). Пароль NTLM может содержать до 128 символов. В отличие от хеширования LAN Manager, ограниченного использованием только символов ASCII, NTLM совместим с полным набором символов Unicode, что повышает сложность паролей. NTLM-хеш отсекается на 128-м символе, преобразуется в 16-разрядное значение Unicode, обрабатывается распределительной функцией MD4 и сохраняется в 32-символьной шестнадцатеричной строке. За счет использования NTLM-хеша в операциях запрос—ответ последовательность аутентификации NTLM гораздо сложнее процедуры LAN Manager.

NTLMv2

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

В целом NTLMv2 более устойчив к атакам с применением «грубой силы», нежели NTLM, так как в протоколе применяется 128-разрядный ключ шифрования. Известно только о двух программах взлома паролей (одна из них — LC5 компании Symantec), с помощью которых удавалось открыть хеши паролей NTLMv2.

Kerberos

Компания Microsoft приняла Kerberos в качестве выбираемого по умолчанию протокола доменной аутентификации для доменов Windows 2000, а затем и AD. Kerberos — открытый стандарт, пригодный для взаимодействия с инородными доменами (называемыми областями — realm — в UNIX и Linux). Каждый DC в доменах AD играет роль сервера распределения (Kerberos Distribution Server, KDC) и может участвовать в процедуре аутентификации. Безопасность повышается благодаря следующим характеристикам Kerberos:

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

Краткое описание работы Kerberos:

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

Следует обратить внимание, что, хотя принцип работы Kerberos напоминает инфраструктуру с частным открытым ключом (public key infrastructure, PKI), вся информация защищается с использованием симметричных ключей (в отличие от асимметричных ключей, применяемых в большинстве служб аутентификации).

Смарт-карты

Надежность паролей и других методов аутентификации на основе одного параметра быстро снижается. Электронная коммерция проникает в повседневную жизнь и возрастает как число способов кражи личных данных (спам, мошенничество с URL), так и вероятность злоупотреблений паролями. Многие специалисты считают, что аутентификация с двумя параметрами — в форме смарт-карт, USB-устройств или других криптографических устройств — в будущем станет обычным явлением для транзакций в Internet. Разработчики Microsoft встраивают в свои решения функции для работы с цифровыми сертификатами и смарт-картами. Для использования смарт-карт необходимо установить службу Certificate Services и распространить сертификаты смарт-карт. Конечно, нужны также физические смарт-карты, устройства считывания и программное обеспечение поставщика. Затем при необходимости пользователи могут вставлять свои смарт-карты в локальные устройства чтения для доступа к компьютеру Windows. При грамотном использовании смарт-карты могут существенно повысить надежность аутентификации.

Защита протокола аутентификации

В некоторых статьях ошибочно утверждается, что взломать механизм аутентификации Microsoft по-прежнему просто. В действительности из 20 существующих инструментов взлома пароля только два работают с NTLMv2 и лишь один — с Kerberos. Но, предприняв несколько простых шагов, можно отвести и эту угрозу. Для предотвращения попыток разгадывания и сброса пароля нужно принять следующие меры (большинство параметров можно настроить локально или с помощью Group Policy).

Отключить хранение LM-хешей, как описано в статье Microsoft «How to prevent Windows from storing a LAN manager hash of your password in Active Directory and local SAM databases» (http://support.microsoft.com/ default.aspx?scid=kb;en-us;299656). Это делается для того, чтобы помешать взломщикам открыть исходный пароль.
Отключить все протоколы аутентификации, кроме NTLMv2 и Kerberos (после исчерпывающего тестирования). Процедура описана в статье Microsoft TechNet «Network security: LAN Manager authentication level» (http://www.microsoft.com/resources/ documentation/windowsserv/2003/ standard/proddocs/en-us/576.asp).
Запретить начальную загрузку со сменных носителей, чтобы предотвратить запуск инструментов взлома пароля в обход операционной системы. Запрет начальной загрузки со всех дисков, кроме выбираемого по умолчанию, предотвращает доступ автономных программ взлома пароля к базе данных аутентификации, где хранятся хеши паролей.
Пользователи должны назначать сложные пароли длиной не менее 8 символов.
Пользователи должны менять свои пароли по крайней мере раз в квартал.
Активизировать блокировку учетной записи хотя бы на одну минуту с автоматическим сбросом. Это предотвращает разгадывание паролей в сети.

Обязанности пользователей

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

Роджер Граймз — Редактор Windows IT Pro и консультант по проблемам безопасности. Имеет сертификаты CPA, CISSP, CEH, CHFI, TICSA, MCT, MCSE: Security и Security+. roger@banneretcs.com

Источник

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

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

Аутентификация в системах Windows. Часть 1 — NTLM-02

LAN Manager (LM)

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

NT LAN Manager (NTLM)

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

Аутентификация в системах Windows. Часть 1 — NTLM-03

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

Аутентификация в системах Windows. Часть 1 — NTLM-04

NTLMv2

Аутентификация в системах Windows. Часть 1 — NTLM-05

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

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

Аутентификация в системах Windows. Часть 1 — NTLM-06

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

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

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

Материал сайта pyatilistnik.org

Источник

Кто-то из вас наверняка слышал про инцидент , который был обнародован совсем недавно. Американский производитель полупроводников Allegro MicroSystem LLC подал в суд на своего бывшего IT-специалиста за саботаж. Нимеш Пател, проработавший в компании 14 лет, уничтожил важные финансовые данные в первую неделю нового фискального года.

Как это произошло?

Через две недели после своего увольнения Пател зашел на территорию штаб-квартиры компании в Вустере (штат Массачусетс, США) с целью поймать корпоративную сеть Wi-Fi. Используя учетные данные бывшего коллеги и рабочий ноутбук, Пател авторизовался в корпоративной сети. Затем он внедрил в модуль Oracle код и запрограммировал его выполнение на 1 апреля 2016 года — первую неделю нового финансового года. Код предназначался для копирования определенных заголовков или указателей в отдельную таблицу базы данных и следующего удаления их из модуля. Ровно 1 апреля данные были удалены из системы. И поскольку злоумышленник авторизовался в сети Allegro легально, его действия были замечены не сразу.

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

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

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

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

В следующих статьях мы расскажем вам, как настроить Bitlocker, защитить электронную почту и простейший документооборот. Также мы вместе с вами настроим безопасный доступ к корпоративным ресурсам и безопасный удаленный доступ по VPN.

Двухфакторная аутентификация

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

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

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

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

Токен и смарт-карта

Наверно, самым надежным и простым в реализации способом двухфакторной аутентификации является использование криптографического токена или смарт-карты. Токен — это USB-устройство, которое является и считывателем, и смарт-картой одновременно. Первым фактором в таком случае является факт владения устройством, а вторым — знание его PIN-кода.

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

На фотографии изображена типичная смарт-карта и считыватель.

Однако вернемся к корпоративной безопасности.

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

Как известно, политики Windows-домена, настройки пользователей, настройки групп в Active Directory предоставляют и разграничивают доступ к огромному количеству приложений и сетевых сервисов.

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

Почему двухфакторная аутентификация в домене по токену с PIN-кодом безопаснее обычной парольной схемы?

PIN-код привязан к определенному устройству, в нашем случае к токену. Знание PIN-кода само по себе ничего не дает.

Например, PIN-код от токена можно диктовать по телефону другим лицам и это ничего не даст злоумышленнику, если вы достаточно бережно относитесь к токену и не оставляете его без присмотра.

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

Токен является уникальным некопируемым физическим объектом. Им обладает легитимный пользователь. Двухфакторную аутентификацию по токену можно обойти только тогда, когда администратор намеренно или по недосмотру оставил для этого «лазейки» в системе.

Преимущества входа в домен по токену

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

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

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

Токены позволяют решить проблему «брошенного рабочего места» — когда пользователь уходит со своего рабочего места и забывает выйти из своей учетной записи.

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

Недостатки, куда же без них

Токены или смарт-карты не бесплатные (решается бюджетом).

Их нужно учитывать, администрировать и обслуживать (решается системами управления токенами и смарт-картами).

Некоторые информационные системы могут «из коробки» не поддерживать аутентификацию по токенам (решается системами типа Single Sign-On — предназначенными для организации возможности использования единой учетной записи для доступа к любым ресурсам области).

Настройка двухфакторной аутентификации в домене Windows

Теоретическая часть:

Служба каталога Active Directory поддерживает возможность аутентификации с помощью смарт-карты и токена, начиная с Windows 2000. Она заложена в расширении PKINIT (public key initialization — инициализация открытого ключа) для протокола Kerberos RFC 4556 .

Протокол Kerberos был специально разработан для того, чтобы обеспечить надежную аутентификацию пользователей. Он может использовать централизованное хранение аутентификационных данных и является основой для построения механизмов Single Sing-On. Протокол основан на ключевой сущности Ticket (билет).

Ticket (билет) является зашифрованным пакетом данных, который выдается доверенным центром аутентификации, в терминах протокола Kerberos — Key Distribution Center (KDC, центр распределения ключей).

Когда пользователь выполняет первичную аутентификацию после успешного подтверждения его подлинности, KDC выдает первичное удостоверение пользователя для доступа к сетевым ресурсам — Ticket Granting Ticket (TGT).

В дальнейшем при обращении к отдельным ресурсам сети, пользователь, предъявляет TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу — Ticket Granting Service (TGS).

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

Расширение PKINIT позволяет использовать двухфакторную аутентификацию по токенам или смарт-картам на этапе предаутентификации Kerberos.

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

Все контроллеры доменов должны иметь установленный сертификат Domain Controller Authentication, или Kerberos Authentication, т. к. реализуется процесс взаимной аутентификации клиента и сервера.

Практика:

Приступим к настройке.

Сделаем так, чтобы в домен под вашей учетной записью можно было зайти только по предъявлению токена и зная PIN-код.

Для демонстрации мы будем использовать Рутокен ЭЦП PKI производства компании «Актив».

1 Этап — Настройка домена Первым делом установим службы сертификации.

Дисклеймер.

Эта статья не является туториалом по внедрению корпоративного PKI. Вопросы проектирования, разворачивания и грамотного применения PKI тут не рассматриваются ввиду необъятности этой темы.

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

Задача центра сертификации — подтверждать подлинность ключей шифрования с помощью сертификатов электронной подписи.

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

Удостоверяющий центр, выдающий сертификаты для использования смарт-карт или токенов, должен быть помещен в хранилище NT Authority.

Зайдите в Диспетчер сервера и выберите «Добавить роли и компоненты».

При добавлении ролей сервера выберите «Службы сертификации Active Directory» (Microsoft категорически рекомендует не делать это на контроллере домена, дабы не огрести проблем с производительностью). В открывшемся окне выберите «Добавить компоненты» и выберите пункт «Центр сертификации».

На странице для подтверждения установки компонентов нажмите «Установить».

2 Этап — Настройка входа в домен с помощью токена

Для входа в систему нам понадобится сертификат, который содержит идентификаторы Smart Card Logon и Client Authentication.

Сертификат для смарт-карт или токенов также должен содержать UPN пользователя (суффикс имени участника-пользователя). По умолчанию суффиксом имени участника-пользователя для учетной записи является DNS-имя домена, которое содержит учетную запись пользователя.

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

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

Настроим установленные службы сертификации. В правом верхнем углу нажмите на желтый треугольник с восклицательным знаком и щелкните «Настроить службы сертификации…».

В окне «Учетные данные» выберите необходимые учетные данные пользователя для настройки роли. Выберите «Центр сертификации».

Выберите «ЦС предприятия».

ЦС предприятия интегрированы с AD. Они публикуют сертификаты и списки отзыва сертификатов в AD.

Укажите тип «Корневой ЦС».

На следующем этапе выберите «Создать новый закрытый ключ».

Выберите период действия сертификата.

3 этап — Добавление шаблонов сертификатов

Для добавления шаблонов сертификатов откройте Панель управления, выберите пункт «Администрирование» и откройте Центр сертификации.

Щелкните по названию папки «Шаблоны сертификатов», выберите пункт «Управление».

Щелкните по названию шаблона «Пользователь со смарт-картой» и выберите пункт «Скопировать шаблон». На следующих скриншотах показано, какие параметры в окне «Свойства нового шаблона» необходимо изменить.

Если в списке поставщиков нет «Aktiv ruToken CSP v1.0», то необходимо установить комплект «Драйверы Рутокен для Windows».

Начиная с Windows Server 2008 R2 вместо специального провайдера от производителя можно использовать «Microsoft Base Smart Card Crypto Provider».

Для устройств Рутокен библиотека «минидрайвера», поддерживающая «Microsoft Base Smart Card Crypto Provider», распространяется через Windows Update.

Проверить установился ли «минидрайвер» на вашем сервере можно подключив Рутокен к нему и посмотрев в диспетчер устройств.

Если «минидрайвера» по каким-то причинам нет, его можно установить принудительно, инсталлировав комплект «Драйверы Рутокен для Windows», а после этого воспользоваться «Microsoft Base Smart Card Crypto Provider».

Комплект «Драйверы Рутокен для Windows» распространяется бесплатно с сайта Рутокен .

Добавьте два новых шаблона «Агент сертификации» и «Пользователь с Рутокен».

Для этого выйдите из окна «Управления шаблонами». Нажмите правой кнопкой мыши на «Шаблоны сертификатов» и выберите пункт меню «Создать» и подпункт «Выдаваемый шаблон сертификата».

Далее выберите «Агент регистрации» и «Пользователь с Rutoken» и нажмите «ОК».

В результате названия этих шаблонов отобразятся в центре сертификации.

Далее нам необходимо выписать сертификат администратору домена. Откройте службу «Выполнить» и укажите команду mmc. Добавьте оснастку «Сертификаты».

В окне «Оснастки диспетчера сертификатов» выберите «моей учетной записи пользователя». В окне «Добавление и удаление оснастки» подтвердите добавление сертификатов.

Выберите папку «Сертификаты».

Запросите новый сертификат. Откроется страница для регистрации сертификата. На этапе запроса сертификата выберите политику регистрации «Администратор» и нажмите «Заявка».

Таким же образом запросите сертификат для Агента регистрации.

Чтобы запросить сертификат для определенного пользователя щелкните «Сертификаты», выберите пункт «Зарегистрироваться от имени…».

В окне для запроса сертификата установите флажок «Пользователь с Рутокен».

Теперь необходимо выбрать пользователя.

В поле «Введите имена выбранных объектов» укажите имя пользователя в домене и нажмите «Проверить имя».

В окне для выбора пользователя нажмите «Заявка».

В раскрывающемся списке выберите имя токена и укажите PIN-код.

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

4 этап — Настройка учетных записей пользователей

Для настройки учетных записей откройте список пользователей и компьютеров AD.

Выберите папку Users и пункт «Свойства».

Перейдите на вкладку «Учетные записи», установите флажок «Для интерактивного входа в сеть нужна смарт-карта».

Настройте политики безопасности. Для этого откройте Панель управления и выберите пункт «Администрирование». Откройте меню для управления групповой политикой.

В левой части окна «Управление групповой политикой» щелкните «Default Domain Policy» и выберите пункт «Изменить».

В левой части окна «Редактор управления групповыми политиками» выберите пункт «Параметры безопасности».

Откройте политику «Интерактивный вход в систему: требовать смарт-карту».

На вкладке «Параметры политики безопасности» установите флажки «Определить следующий параметр политики» и «Включен».

Откройте политику «Интерактивный вход в систему: поведение при извлечении смарт-карты».

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

Перезагрузите компьютер. И при следующей попытке аутентификации в домене уже можно будет использовать токен и его PIN-код.

BINGO!

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

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

Источник

Аннотация: В этой лекции описываются некоторые средства и процессы, используемые для защиты сервера. Уделено внимание аутентификации Windows Server 2003 и основным протоколам: Kerberos V5 и NTLM

Существует довольно распространенный миф, что платформа 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 входят следующие шаги.

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

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

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

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

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

Откройте оснастку Active Directory Users and Computers.
В дереве консоли щелкните правой кнопкой на данном домене.
Выберите пункт Properties (Свойства) и затем щелкните на вкладке Group Policy (Групповая политика).
Щелкните на кнопке Edit.
В дереве консоли щелкните на Kerberos Policy (в последовательности Computer Configuration/ Windows Settings/Security Settings/Account Policies/Kerberos Policy).
Дважды щелкните на политике Kerberos, которую хотите модифицировать.
Внесите изменения в эту политику и затем щелкните на кнопке 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 (Центр сертификации).

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

Шаблон сертификата — это набор правил и настроек, которые применяются к запросам сертификатов. Для каждого типа сертификатов должен быть сконфигурирован шаблон сертификата. Шаблоны сертификатов можно настраивать в центрах сертификации (ЦС) предприятий 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.

Источник

Лекция №4

Вопросы:

1. Этапы
идентификации и аутентификации
пользователя, реализуемые ОС Windows.

2. Протоколы
аутентификации Windows.

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

Аутентификация
представляет собой один из компонентов
любой компьютерной системы
управления доступом.
Как показано на рисунке 1, системы
управления доступом обеспечивают
идентификацию, аутентификацию, авторизацию
и отчетность.

Рисунок 1. Механизмы
управления доступом и аутентификация
в Windows

1. Идентификация

Это первый этап
входа в КС. Как известно, на этом этапе
вводится имя пользователя КС (логин).

При этом ОС (а
именно, процесс Winlogon, отвечающий за вход
в КС и выход из неё) создает уникальный
идентификатор пользователя (SID),
представляющий собой набор данных,
который уникально идентифицирует объект
безопасности (пользователя, группу,
компьютер, учетную запись службы).

Пример.

S-1-5-21-1463437245-1224812800-863842198-1128

1 — №версии;

5 – код агента ОС
(назначающей SID);

Четыре кода
субагентов-попечителей;

1128 – RID или средство
создания уникальных SID.

SID назначается
компьютеру при установке ОС. Далее
Winlogon назначает SID локальным учетным
записям на данном компьюторе.

SID(ЛУЗ) = SID (К) + RID
пользователя.

RID = 500 – администратор;

RID = 501 – гость;

RID = 1000, 1001….. –
пользователи.

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

Маркер доступа
(МД) –
идентификатор контекста защиты процесса
или потока. Он наследуется всеми
процессами, запущенными от имени
пользователя.

Для защиты от НСД
используются два элемента МД:

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

2. Аутентификация

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

В Windows субъект
безопасности вводит эту информацию на
экране регистрации с помощью программ
Microsoft Graphical Identification and Authentication DLL
(msgina.dll) и Winlogon.exe. Протокол аутентификации
и механизм системы шифруют представленную
информацию на персональном компьютере
и передают запрос аутентификации.

Службой аутентификации
Windows может быть база данных SAM или Active
Directory.

База данных SAM
обслуживает локальные
процедуры регистрации и регистрацию
на контроллерах домена Windows NT 4.0. Эта
база обязательно имеется на каждом
компьютере с операционной системой
Windows. В ней хранится вся информация,
используемая для аутентификации
пользователей Windows при интерактивном
входе в систему и при удаленном доступе
к ней по компьютерной сети.

База
данных SAM представляет собой один из
кустов (hive) системного реестра (registry)
Windows. Этот куст принадлежит ветви
(subtree) HKEY_LOCAL_MACHINE и называется SAM. Физически
база данных SAM располагается в каталоге
wmnt_rootSystem32ConfIg (winnt_root — условное
обозначение каталога с системными
файлами Windows) в отдельном файле, который
тоже называется SAM.

Информация в базе
данных SAM хранится в основном в двоичном
виде. Доступ к ней обычно осуществляется
через диспетчер учетных записей. Изменять
записи, находящиеся в базе данных SAM,
при помощи программ, позволяющих напрямую
редактировать реестр Windows (REGEDT или
REGEDT32), не рекомендуется. По умолчанию
этого и нельзя делать, т. к. доступ к базе
данных SAM запрещен для всех без исключения
категорий пользователей операционной
системы Windows.

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

Active
Directory
аутентифицирует запросы в Windows
2000/XP/Vista
или доменах более поздних версий этой
операционной системы. Протокол
аутентификации используется для
транспортировки запросов аутентификации
и последующих транзакций между экраном
регистрации и службой аутентификации.
Чуть ниже каждый протокол аутентификации
будет рассмотрен отдельно.

Рис.2.
Компоненты, участвующие в процессе
аутентификации.

При
интерактивном входе в систему (в отличие
от входа через сеть) происходит
взаимодействие с процессами Winlogon,
Lsass,
одним или несколькими пакетами
аутентификации, а также SAM
или Active
Directory.
Пакеты
аутентификации
(authentication
packages)
— это DLL-модули,
выполняющие
проверки, связанные с аутентификацией.

Windows использует
два стандартных пакета аутентификации
при интерактивном входе: Kerberos и MSV1_0.

Пакетом
аутентификации Windows
для интерактивного входа в домен
является
Kerberos.

Пакет
MSV1_0
используется для
интерактивного входа на локальные
компьютеры.

Таким
образом, пакетом аутентификации по
умолчанию в автономной
системе
Windows является пакет — MSV1_0
(WindowsSystem32Msvl_0.dll).

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

Далее
MSV1_0 сравнивает хешированный пароль и
имя пользователя с теми, которые хранятся
в SAM.

Winlogon — процесс,
отвечающий за взаимодействие с
пользователем.

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

Winlogon получает имя
и пароль пользователя через Graphical
Identification and Authentication (GINA) DLL Стандартная
GINA — WindowsSystem32 Msgina.dll. Msgina выводит
диалоговое окно для входа в систему.

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

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

Соседние файлы в папке лк

#
02.02.2021530.94 Кб28Л9.ppt
#
#
#
#
#
#
#
#
#
#

Источник

Настройка авторизации пользователей

Для пользователей, импортированных из Active Directory, доступны все типы авторизации пользователей. Наиболее часто используемые варианты авторизации пользователей — Single Sign-On аутентификация через Active Directory с использованием Kerberos/NTLM для авторизации через веб-браузер и авторизация через журнал безопасности Active Directory (рекомендуется одновременное использование обоих типов авторизации).

Для включения Single Sign-On аутентификации и Авторизация через журнал безопасности Active Directory перейдите на вкладку Пользователи -> Авторизация -> Основное и включите эти типы авторизации. Далее нажмите кнопку Сохранить.

После заполнения поля Имя домена и сохранения настроек, будет выдан Let’s Encrypt сертификат и пользователь будет перенаправляться на окно авторизации, минуя страницу исключения безопасности:

Если сертификат для такого домена уже загружен в разделе

Сертификаты

, то будет использоваться он, новый сертификат выдаваться не будет.

Настройка компьютеров пользователей и политик домена

Авторизация через журнал безопасности Active Directory

Поддерживается начиная с версии контроллера домена 2008 standard edition.

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

В настройках брандмауэра Windows на всех контроллерах домена (или доменов) разрешить удаленный доступ к логам безопасности.

В англоязычной версии, правило именуется: Remote Event Log Management (RPC)

Добавить Ideco UTM в группу безопасности Читатели журнала событий (Event Log Readers).

После настройки доступа к журналу, необходим перезапуск службы Авторизация через журнал безопасности Active Directory на Ideco UTM, для этого отключите эту настройку и заново включите;

Если вы изменяли политики безопасности контроллеров домена по сравнению со стандартными, то нужно включить логирование в политиках безопасности, активировав следующий параметр: Default Domain Controllers Policy -> Computer Configuration->Policies->Windows Settings->Security Settings-> Advanced Audit Policy Configuration -> Audit Policies -> Logon/Logoff -> Audit Logon -> Success.

Путь для русскоязычной версии: Политика Default Domain Controllers Policy -> Конфигурация Windows -> Параметры безопасности -> Конфигурация расширенной политики аудита -> Политики аудита -> Вход/выход -> Аудит входа в систему -> Успех.

Также необходимо включить следующие параметры: Default Domain Controllers Policy -> Computer Configuration->Policies->Windows Settings->Security Settings-> Advanced Audit Policy Configuration -> Audit Policies -> Account logon -> «Audit Kerberos Authentication Service» и «Audit Kerberos Service Ticket Operations» -> Success.

Путь для русскоязычной версии: Политика Default Domain Controllers Policy -> Конфигурация Windows -> Параметры безопасности -> Конфигурация расширенной политики аудита -> Политики аудита -> Вход учетной записи -> «Аудит службы проверки подлинности Kerberos» и «Аудит операций билета службы керберос» -> Успех.

Для обновления политик контроллеров доменов выполните команду gpupdate /force;

Если авторизация пользователей при логине не происходит, нужно проверить в журнале безопасности наличие событий 4768, 4769, 4624.

Веб-аутентификация (SSO или NTLM)

Для работы аутентификации через веб-браузер (с использованием Kerberos либо NTLM) необходима настройка Internet Explorer (остальные браузеры подхватывают его настройки). В системе Windows 10 параметры прокси нужно настроить без Internet Explorer, в разделе Параметры -> Сеть и интернет -> Прокси-сервер.
Обязательно используйте эти настройки, даже если обычно пользователи авторизуются через журнал безопасности, в некоторых случаях будет необходима их аутентификация через браузер.

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

Зайдите в свойствах браузера на вкладку Безопасность.

Выберите Местная интрасеть -> Сайты -> Дополнительно.

Добавьте в открывшемся окне ссылку на Ideco UTM под тем именем, под которым вы ввели его в домен. Нужно указывать два URL: c http:// и с https://.

На скриншоте ниже Ideco UTM введен в домен example.ru под именем idecoics.

Также данную настройку можно сделать с помощью групповых политик Active Directory сразу для всех пользователей. Для этого необходимо выполнить следующие действия:

В групповых политиках для пользователей перейдите по пути: Default Policy Group > Computer Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Site to Zone Assignment List

Путь для русскоязычной версии: Конфигурация компьютера -> Политики -> Административные шаблоны -> Компоненты Windows -> Internet Explorer -> Панель управления браузером -> Вкладка безопасность -> Список назначений зоны для веб-сайтов.

Введите назначение зоны для DNS-имени Ideco UTM (в примере idecoics.example.ru) со значением равным 1 (интрасеть). Необходимо указать два назначения, для схем работы по http и https.

При входе на HTTPS-сайт, для аутентификации необходимо разрешить браузеру доверять сертификату Ideco UTM (чтобы не делать это каждый раз, можно добавить корневой сертификат Ideco UTM в доверенные корневые сертификаты устройства. Например, с помощью политик домена). Можно также использовать

скрипты для автоматической авторизации

пользователей при логине.

На странице настроек браузера Mozilla Firefox (about:config в адресной строке) настройте следующие параметры:

network.automatic-ntlm-auth.trusted-uris и network.negotiate-auth.trusted-uris добавьте адрес локального интерфейса Ideco UTM (например idecoUTM.example.ru);

security.enterprise_roots.enabled в значении true позволит Firefox доверять системным сертификатом и авторизовать пользователей при переходе на HTTPS-сайты.

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

Через Ideco Agent — подходит для аутентификации пользователей терминальных серверов (с использованием Remote Desktop IP Virtualization на терминальном сервере);

Авторизация по IP-адресу — подходит в случае, если пользователи всегда работают с фиксированных IP-адресов. IP-адреса на UTM необходимо прописывать вручную каждому пользователю;

Авторизация по PPTP — если в сети предъявляются повышенные требования к конфиденциальности информации, передаваемой между шлюзом и устройствами пользователей, или используется слабо защищенный от перехвата трафика Wi-Fi.

Настройка аутентификации пользователей при прямых подключениях к прокси-серверу

Настройка прозрачной аутентификации пользователей при прямых подключениях к прокси-серверу аналогична настройке прозрачной Single Sign-On аутентификации, описанной выше в инструкции. Единственная особенность — указание в качестве адреса прокси-сервера не IP-адреса Ideco UTM, а его DNS-имени.

Настройка браузера Mozilla Firefox для аутентификации по NTLM при прямом подключении к прокси-северу

Для компьютеров, которые не находятся в домене Active Directory, в случае необходимости их аутентификации под доменным пользовательским аккаунтом, на странице настроек браузера Mozilla Firefox (about:config в адресной строке) настройте следующие параметры:

network.automatic-ntlm-auth.allow-proxies = false;

network.negotiate-auth.allow-proxies = false.

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

Возможные причины ошибок при аутентификации

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

Доменному пользователю должно быть разрешено аутентифицироваться на Ideco UTM. На контроллере домена зайдите в свойства выбранных пользователей во вкладку Учетная запись -> Вход на…, выберите пункт только на указанные компьютеры и пропишите имя рабочей станции для входа в систему.

Пример данной настройки представлен на скриншоте ниже:

При аутентификации через журнал безопасности контроллера домена Active Directory пользователи будут аутентифицированы при попытке выхода в Интернет (любым трафиком). Автоматической аутентификации без прохождения трафика через UTM не происходит, т.к. используется конкурентная политика аутентификации.

Источник

В этой статье мы покажем, как внедрить двухфакторную аутентификацию пользователей в домене Windows с помощью open source продукта multiOTP. MultiOTP эта набор php скриптов и утилит, который реализует протокол OATH для HOTP/TOTP (Time-based One Time Password). Возможно использовать как в Windows, так и через RADIUS для реализации 2FA практически в чем угодно.

После внедрения multiOTP для входа пользователя Windows будет запрашивать дополнительный одноразовый пароль (OTP – one time password), который пользователь должен получить со своего мобильного устройства (приложение Microsoft или Google Authenticator, или другого генератора OTP). Вы можете настроить двухфакторную аутенфтикацию для входа на рабочие станции Windows, или для удаленного RDP доступа к хостам RDS на Windows Server.

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

Содержание:

Установка и настройка MultiOTP в домене Active Directory
Настройка двухфакторной аутентификации MultiOTP для пользователя домена
Установка multiOTP CredentialProvider в Windows

Установка и настройка MultiOTP в домене Active Directory

В этом разделе мы покажем, как установить MultiOTP в Windows Server 2019 и настроить синхронизацию пользователей из Active Directory.

Также вы можете развернуть MultiOTP с помощью готового образа OVA для VMware, виртуальной машины Hyper-V или Docker контейнера.

Начнем с настройки сервера MultiOTP, который будет получать пользователей из Active Directory, генерировать уникальные QR коды для пользователей и проверять правильность второго фактора.

Создадим в Active Directory отдельную группу и добавим в нее пользователей, для которых мы будет требовать проверку второго фактора при входе в Windows. Создадим группу с помощью PowerShell:

New-ADGroup 2FAVPNUsers -path 'OU=Groups,OU=Moscow,dc=winitpro,DC=ru' -GroupScope Global -PassThru –Verbose

Добавьте пользователей в группу:

Add-AdGroupMember -Identity 2FAVPNUsers -Members kbuldogov, user1, user2

Создайте в AD нового пользователя multiotp_srv, который будет использоваться multiotp для доступа к AD (с минимальными привилегиями).

$passwd = ConvertTo-SecureString -String "[email protected]!" -AsPlainText -Force New-ADUser -Name "multiotp_srv" -SamAccountName "multiotp_srv" -UserPrincipalName "[email protected]" -Path "OU=ServiceAccounts,OU=Moscow,DC=winitpro,DC=ru" –AccountPassword $passwd -Enabled $true

Скачайте архив с файлами MultiOTP с сайта разработчиков https://download.multiotp.net/.

Откройте архив multiotp_5.8.2.9.zip и извлеките из него каталог windows в папку на локальном диске (C:MultiOTP).

Откройте командную строку и перейдите в каталог с утилитой multiotp.exe:

CD C:MultiOTPwindows

Следующими командами мы настроим MultiOTP для получения пользователей из LDAP каталога Active Directory.

multiotp -config default-request-prefix-pin=0 multiotp -config default-request-ldap-pwd=0 multiotp -config ldap-server-type=1 multiotp -config ldap-cn-identifier="sAMAccountName" multiotp -config ldap-group-cn-identifier="sAMAccountName" multiotp -config ldap-group-attribute="memberOf" multiotp -config ldap-ssl=0 multiotp -config ldap-port=389

REM Адрес контроллера домена

multiotp -config ldap-domain-controllers=msk-dc03.winitpro.ru,ldap://192.168.13.10:389 multiotp -config ldap-base-dn="DC=winitpro,DC=ru"

REM Учетная запись для аутентификации multiotp в AD:

multiotp -config ldap-bind-dn="CN=multiotp_srv,OU=ServiceAccounts,OU=Moscow,DC=winitpro,DC=ru" multiotp -config ldap-server-password="[email protected]!"

REM группа пользователей, для которых нужно включить OTP

multiotp -config ldap-in-group="2FAVPNUsers" multiotp -config ldap-network-timeout=10 multiotp -config ldap-time-limit=30 multiotp -config ldap-activated=1

REM ключ для доступа к MultiOTP серверу

multiotp -config server-secret=secretOTP

Ранее мы создали группу 2FAVPNUsers и добавили в нее 3 пользователей. Выполните синхронизацию пользователей AD в MultiOTP.

multiotp -debug -display-log -ldap-users-sync

OG 2022-01-17 14:36:44 info LDAP Info: 3 users created, based on 3 LDAP entries (processed in 00:00:00)
LOG 2022-01-17 14:36:44 debug System Info: *File created: c:MultiOTPwindows.usersa.ivanov.db

В данном случае MultiOTP обнаружила трех пользователей и синхронизировала их.

Для регулярной синхронизации новых учетных записей в Active Directory, нужно создать задание планировщика с командой:

multiotp -debug -display-log -ldap-users-sync

Запустите с правами администратора файл webservice_install.cmd. Это установит веб интерфейс управления MultiOTP.

Зайдите на веб-интерфейс
http://127.0.0.1:8112/
под учётной запись admin с паролем 1234 (желательно сменить при входе).

Настройка двухфакторной аутентификации MultiOTP для пользователя домена

В разделе List of users будет доступен список пользователей домена, которые были синхронизированы ранее (источник AD/LDAP).

Выберите пользователя и нажмите Print. Перед вами появится QR код пользователя, который нужно добавить в приложение-аутентфикатор.

Установите на смартфон пользователя приложение Microsoft Authenticator (или Google Authenticator) из Google Play или App Store. Запустите его и отсканируйте QR код пользователя.

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

Из командной строки можно проверить, что MultiOTP позволяет аутентифицировать данного пользователя с помощью OTP:

multiotp.exe -display-log kbuldogov 719854

где
719854
– одноразовый пароль, полученный из приложения.

LOG 2022-01-17 15:13:11 notice (user kbuldogov) User OK: User kbuldogov successfully logged in with TOTP token
Filter-Id += "2FAVPNUsers"

Также можно проверить корректность работы OTP из веб-интерфейса. Перейдите в раздел Check a user, введите имя пользователя и одноразовый пароль.

Установка multiOTP CredentialProvider в Windows

Следующий этап – установка multiOTP-CredentialProvider на компьютеры Windows, на которых вы хотите внедрить двухфакторную аутентификацию пользователей с помощью MultiOTP. CredentialProvider можно установить на все версии Windows 7/8/8.1/10/11 и Windows Server 2012(R2)/2016/2019/2022.

В это примере мы настроим двухфакторную аутентификацию для RDP входа пользователей на RDSH сервер на Windows Server 2019.

Скачайте и установите multiOTP CredentialProvider с GitHub https://github.com/multiOTP/multiOTPCredentialProvider/releases. На момент написания статьи эта версия
5.8.4.0
.

Запустите установку:

Укажите IP сервера, на котором был установлен multiOTP
В нижнее поле укажите секретное слово из конфигурации multiOTP (
в нашем конфиге);
Выберите тип входа в Windows, для которых нужно применять аутентфикацию через OTP. В нашем примере мы ограничимся 2FA только для RDP входов (OTP authentication mandatory for remote desktop only).

Можно включить использование OTP аутенфтикации как для RDP так и для локальных входов.

MultiOTP CredentialProvider хранит настройки в реестре HKEY_CLASSES_ROOTCLSID{FCEFDFAB-B0A1-4C4D-8B2B-4FF4E0A3D978}. Если нужно, вы здесь можете изменить настройки CredentialProvider без переустановки.

Перезагрузите Windows Server RDS и попробуйте через RDP подключиться к нему. Теперь после отправки имени и пароля пользователя появляется дополнительное окно one-time password. Здесь пользователь должен ввести одноразовый пароль из приложения Authenticator на своем смартфоне.

Если на RDS хосте отключен NLA для RDP, пользователь просто увидит три поля для ввода (имя учетной записи, пароль и OTP).

На севере MultiOTP можно включить ведение логов, это полезно при отладке:
multiotp -config debug=1 multiotp -config display-log=1

Your script is running from C:MultiOTPwindows
2022-01-17 15:21:07 debug CredentialProviderRequest Info: *Value for IsCredentialProviderRequest: 1 0 SPB-SRV01
2022-01-17 15:21:07 debug Server-Client Info: *CheckUserToken server request. 0 SPB-SRV01
2022-01-17 15:21:07 notice kbuldogov User OK: User kbuldogov successfully logged in (using Credential Provider) with TOTP token 0 SPB-SRV01
2022-01-17 15:21:07 debug Server-Client Info: *Cache level is set to 1 0 SPB-SRV01
2022-01-17 15:21:07 debug Server-Client Info: *Server secret used for command CheckUserToken with error code result 0: secretOTP 0 SPB-SRV01

Не забудьте убедиться, что ваш домен синхронизирует время с тайм-серверами в интернете и время на клиентах не разбегается. Эти критично для работы OTP.

В любом случае перед массовым внедрением 2FA на базе MultiOTP в вашей сети рекомендуем в течении пары недель протестировать все режимы работы и нештатные ситуации (недоступность сервера MultiOTP, DC, ошибки в CredentialProvider и т.д.). Если возникли существенные проблемы со входом через MultiOTP, вы можете удалить CredentialProvider в безопасном режиме.

На этом настройка двухфакторной аутентификации в Windows Server с помощью MultiOTP закончена. Доступны сценарии использования MultiOTP с RADIUS сервером, для аутентификации практически любых типов клиентов через OTP. Также вы можете использовать OTP для дополнительной зашиты RDP серверов в интернете от брутфорса в дополнении к https://winitpro.ru/index.php/2019/10/02/blokirovka-rdp-atak-firewall-powershell/.

Источник