Управление средствами аутентификации в windows

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

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

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

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

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

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

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

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

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

При регистрации пользователя одна из первых задач 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:

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

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

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе «Архитектура современных компьютерных сетей» вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

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

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

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

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

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

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

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

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

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

Затем служба 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? Рассмотрим следующую схему:

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

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

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

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

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

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

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

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

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

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

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

NTLMv2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе «Архитектура современных компьютерных сетей» вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Contents:

• Basic Access Check
• The Security Descriptor, DACL & SACL
• Integrity Level Check / Mandatory Integrity Control (MIC)
• Privileges
• UAC
• UAC for the RID-500er local Admin
• Disabling UAC For Non-RID-500er Admins
• UAC and Remote Access
• UAC And Pass-the-Hash
• Access Tokens
• Impersonation
• Privilege Escalation With Identification Tokens
• Privilege Escalation By Leaky Tokens

Compared to Linux, the Window’s authorization process is quite complex and quite a few actors and objects are involved in this process. As a result, there a lot of terms and acronyms that must be known in order to understand and follow up on the topic. To get an idea of what is covered in this guide take a look on this overview of terms and acronyms:

Картинка с сайта: csandker.io

Facing this wall of acronyms, i’d say the best to get into this complex environment is to dive right in and cross reference all new terms.
For all of the following (and in general) be aware that there is a Windows Security Glossary that you could use to look up any acronym or term used in the following.

Basic Access Check

Starting with the simplest scenario: You log onto your Windows system and want to open a file. Who decides if you get access and how is this decision made?
As a reference recap how this decision is made on Unix systems. On Unix systems your user has a user- & group-ID and the access target (the file in this scenario) has an associated list of access permissions that could look like this:

-rwxr-xr-- 1 root root 2048 Jun 13 10:00 file.txt

The Unix OS checks these file permissions, figures that everyone got read access rights and grants the logged in Unix user read access. Most of the Unix authorisation decisions can be broken down to this very simple access check.

Now let’s dive into the Windows World:
Let’s start simple: When a user logs into his Windows machine (regardless if that is a local or a domain joined user), an Access Token is created for that user. Precisely that means this access token is created for that user’s logon thread.
When that logged on user tries to open a file, an access request is generated that specifies what the user wants to do with that file (access right). In our case the user simply wants to read a file, which maps to the GENERIC_READ access right. There are a set of different access rights, which at the end of the day are all just bitmasks representing numbers that serve as a global reference to have a clear definition of what the user requests to do. The most important access rights are the Generic Access Rights and the so called Standard Access Rights.
The user’s access request is taken on by a Windows component called the Security Reference Monitor (SRM), which takes on the requested access right along with the user’s Access Token and compares these bits of information against the defined access permissions for the requested file, which are composed in a structure called Security Descriptor.
Important to note here: Each Securable Object, which include files, directories, registry keys and many other things, has a Security Descriptor.

Okay let’s break that down in key »Take aways«::

• Each user logon thread has an access token
  (Read this as: Each user got assigned an access token)
• A required action, e.g. to open a file, is expressed in an Access Right, e.g. GENERIC_READ
• Each Securable Object has a Security Descriptor, which defines who can do what with that object.
• The Security Reference Monitor (SRM) is the software component in charge to evaluate if a certain process should be granted access to the requested object for the requested access right.

The key function for granting or denying access within the SRM is called SEAcessCheck.

And since I really like visual representation of things, take the following picture to get an overview of what has just been introduced:
(I based that representation on a figure James Forshaw used in his 2015 BlackHat Talk)

Картинка с сайта: csandker.io

Now that the basic concept of access checks in the Windows world has been introduced, let’s dig deeper into the individual components.

The Security Descriptor, DACL & SACL

This section will bring light on the Owner- and the DACL-Check shown in the figure above.

As mentioned previously each Securable Object has a Security Descriptor.
The Security Descriptor defines an object structure to keep record of to whom the referenced object belongs (Owner and Group) and to whom access is granted (or denied) for which actions.

To get an idea of what this looks like the following screenshot shows the Security Descriptor (as kernel object) of the running explorer.exe process:

Картинка с сайта: csandker.io

The most basic part here is the Owner and Group field, which are expressed by a Secure Identifier (SID). In the Windows world a SID is just a unique string to identify a security principal, e.g. a user, a group, etc. The SID consists of three blocks:

• The first part — always beginning with an ‘S’ — describes the group, e.g. Domain Everyone (S-1-1-0), Anonymous (S-1-5-7), Authenticated Users (S-1-5-11), which can be looked up in the register for Well-known SIDs.
• The second part is a unique domain ID (also present in each default WORKGROUP) (S-1-5-21), e.g. S-1-5-21-2884053423-3431565070-78458365-….
• The last part is called the relative ID (RID), which describes a user group inside a security group, e.g. the group of builtin Administrator group (S-1-5-32—544) or the builtin Guests group (S-1-5-32—546) or the famous default Admin account — by me often referred to as RID-500 Admin — (S-1-5-21-2884053423-3431565070-78458365—500). Note how the first two groups are in the same security group (S-1-5-32-…), while the RID-500 admin is in the domain security group.

Okay now back to our example from above: The Owner is set to the SID of S-1-5-21-…..-1001, which is the unique value for my current user and the group is set to the SID of S-1-5-21-…-513, which is the domain users group.
You can look up these SIDs in the register for Well-known SIDs

Apart from the owner and group of the explorer.exe process, the above shown Security Descriptor also contains two lists, the Discretionary Access Control List (DACL) and the System Access Control List (SACL):
The DACL is a list controlled by the owner of the Security Descriptor, that specifies the access particular users or groups can have on the object.
The SACL is a list controlled by system administrators, which holds two types of control entries:

• The SACL holds the MANDATORY_INTEGRITY_LABEL (more on this later); and
• The SACL holds control entries used for the generation of audit messages (which we ignore for now)

For the SACL just keep in mind that the MANDATORY_INTEGRITY_LABEL is stored in here (we ignore the rest for now…).
The DACL is the important control list used for the authorization process. Review the screenshot above and see that the presented DACL actually contains three Access Control Entries (ACEs). For each of the three ACEs the following important fields are set:

• SID: The SID defines the Security Principal (a user or group) to which the ACE applies.
  S-1-5-21-…..-1001 references to one specific domain user.
  S-1-5-18 references the local System account.
• Mask: The access mask is a numeric value, which resembles a combination (addition) of multiple Access Rights, e.g. GENERIC_READ. The access mask is a data structure described in the Microsoft Docs here.
• AceType: The AceType defines whether access should be allowed or denied for the given security principal (SID) and based on the given access mask.
  In the example above three ACEs with AceType ACCESS_ALLOWED_ACE_TYPE are given, which means that if the Security Reference Monitor (SCM) finds a matching access mask for the requesting user in any of these ACEs access will be granted.

For this part the important »Take away«: is:
The SCM will review the Security Descriptor of the requested object and iterate over each ACE in the Security Descriptor’s DACL and check whether the requesting user — identified by it’s SID and requested access right (e.g. GENERIC_READ) match with an Access Mask inside of an ACE. If a match is found the AceType of that ACE will determine if access is granted or denied.

A side note on empty DACLs:
If a DACL of a Security Descriptor is set to NULL, aka the Security Descriptor has no DACL, than full access is granted to everyone.
If the DACL of a Security Descriptor is empty, aka a DACL exists, but does not contain any ACEs than no access is granted to that object.

The last bit of information that is missing is the identity of the requesting user. The SRM gets the identity of the requesting user from the given user access token. Insights of how this token looks like will be given later, for now it’s just important to know that this token contains the SID of the requesting user, as well as the SID of the user’s groups.

Okay and now let’s put in the full picture for the SeAccessCheck:
After the Integrity Level-Check (IL-Check), which will be described in the following section, the Security Reference Monitor (SRM) queries the Security Descriptor of the requested object for the following information:

• Who is the owner of the requested object?
  → If the requesting user is the owner of the requested object: Grant Access
• If the requesting user is not the owner, iterate over all ACEs in the DACL of the Security Descriptor and determine:
  – Does the ACE apply for the requesting user by comparing the ACE SID to the user SID and his/her group SIDs ?
  – Does the access mask contain the requested access right, e.g. does the access mask contain the GENERIC_READ access right ?
  – Does the access type is set to allow access or is it set to deny access?
• If any ACCESS_DENIED_ACE_TYPE matches the user and requested access right: Deny Access
• If no ACCESS_DENIED_ACE_TYPE but a ACCESS_ALLOWED_ACE_TYPE matches the user and requested access right: Grant Access

Next to the Owner and DACL checks there is only one element missing to understand the SeAccessCheck, which is the Integrity Level Check (IL-Check). So let’s dive into that.

Integrity Level Check / Mandatory Integrity Control (MIC)

This section will bring light on the Integrity Level Check shown in the figure above.

The Integrity Level check is meant to enforce another Windows control layer, called Mandatory Integrity Control (MIC).

Mandatory Integrity Control (MIC) provides a mechanism for controlling access to securable objects. This mechanism is in addition to discretionary access control and evaluates access before access checks against an object’s discretionary access control list (DACL) are evaluated.
Source: Mandatory Integrity Control

The first question that should arise in your head now is:
Why the f** do we need MIC? We got DACL checks, which are basically the same checks that are done in Unix systems – shouldn’t that be enough?*

The answer to this question is: Yes the DACL checks are the core of the authorization checks and the vast majority of all access request will be granted or denied based on the DACL checks. MIC is just another layer added by Microsoft in Windows Vista alongside with User Access Control (UAC) to get more fine grained control and to prevent compromised processes from accessing sensitive resources.
This is a very abstract answer to a simple question, but the following introduction to MIC and UAC will hopefully shed some more light on this.

Each Securable Object got a MANDATORY_INTEGRITY_LABEL set in it’s SACL. This label assigns one of four possible Integrity Levels (IL) to the object (as defined in Windows Integrity Mechanism Design):

• Low (SECURITY_MANDATORY_LOW_RID 0x00001000)
• Medium (SECURITY_MANDATORY_MEDIUM_RID 0x00002000)
• High (SECURITY_MANDATORY_HIGH_RID 0X00003000)
• System (SECURITY_MANDATORY_SYSTEM_RID 0x00004000)

These Integrity Levels label the degree of ‘security protection’ that has been assigned to a Securable Object.
»By default all objects are assigned with a Medium Integrity Label.

As an example refer back to the previous screenshot of the Security Descriptor, notice that the Security Descriptor of this object (the explorer.exe process) got the following MANDATORY_INTEGRITY_LABEL: SID: S-1-16-8192
A quick look up to the Well-known SIDs Register reveals that this SID describes the ‘Medium Mandatory Level’ (default for all objects).

»Take away«:
The whole story of integrity labels is to prevent lower level integrity processes from accessing higher level integrity objects.

Another example: When starting the Internet Explorer, a low Integrity Level IE process will be spawned (see screenshot below). This low level IE process is the process that is used by the user for surfing the internet.
If this process is compromised, e.g. by exploiting an IE/Flash/etc. vulnerability, the process would not be able to access a user’s documents, because these were created with the default medium Integrity Level label (and the IE process is running with low integrity).

Картинка с сайта: csandker.io

This is the point where the Integrity Levels checks should begin to make sense. Imagine the compromised IE scenario without MIC. The IE process has been launched by the logged in user and therefore is owned by the logged in user. The DACL-check would therefore grant the compromised IE process access to the user’s resources.
By enforcing an IL-Check, access to user resources is denied to the compromised IE process.

So am I saying that access is generally denied when a process with a lower Integrity Level tries to access a resource with a higher Integrity Level? Of course not – why should it be that simple…

During the Integrity Level check, the SRM compares the Integrity Level of the requesting process with the Integrity Level of the requested object and decides to go to the DACL check or denies access based on the Integrity Level Policy defined for that object.
The Integrity Level Policy of an object is based on the following three defined states (as defined in the SYSTEM_MANDATORY_LABEL_ACE Structure):

• SYSTEM_MANDATORY_LABEL_NO_WRITE_UP ( 0x1 )
• SYSTEM_MANDATORY_LABEL_NO_READ_UP ( 0x2 )
• SYSTEM_MANDATORY_LABEL_NO_EXECUTE_UP ( 0x4 )

Once again refer back to the Security Descriptor of the running explorer.exe given in the previous section. Notice that the Access Mask of the SACL ACE SYSTEM_MANDATORY_LABEL_ACE_TYPE is set to 0x00000003, meaning that this integrity policy denies READ and WRITE access attempts from processes with a lower Integrity Level than Medium, which is the integrity level of that object.

That’s the story of integrity level checks.

Refer back to the initial figure and double check that all makes sense now.

Privileges

The best way to introduce Privileges is with the official MSDN explanation:

A privilege is the right of an account, such as a user or group account, to perform various system-related operations on the local computer, such as shutting down the system, loading device drivers, or changing the system time. Privileges differ from access rights in two ways:

• Privileges control access to system resources and system-related tasks, whereas access rights control access to securable objects.
• A system administrator assigns privileges to user and group accounts, whereas the system grants or denies access to a securable object based on the access rights granted in the ACEs in the object’s DACL.

Each system has an account database that stores the privileges held by user and group accounts. When a user logs on, the system produces an access token that contains a list of the user’s privileges, including those granted to the user or to groups to which the user belongs. Note that the privileges apply only to the local computer; A domain account can have different privileges on different computers.
Source: https://msdn.microsoft.com/en-us/library/windows/desktop/aa379306(v=vs.85).aspx

To enumerate what privileges your user has, simply run the following command and find the list of privileges at the end of the outputted result

C:> whoami /all

Картинка с сайта: csandker.io

Notice how the privileges expand once you run that command in a cmd started with “Run as administrator”:

Картинка с сайта: csandker.io

To cross check or look up the privileges you got you can use the following MSDN resource:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb530716(v=vs.85).aspx

UAC

The sole purpose of User Access Control (UAC) is to have more fine-grained control over administrative execution and to prevent administrative users to use their admin execution rights when it’s not needed.

Recall from the introduction that by logging into your Windows computer your logon thread is assigned a user access token and all child processes launched by that user will inherit this token. For non-admin users this is a Medium Integrity token with your default privileges.
Prior to Windows Vista admin users got a high integrity token with all administrative privileges and each child processes launched would inherit this token. This meant that all processes spawned by an admin user would run with high privileges even if the process would not need those high privileges (e.g. the explorer.exe started by an admin would run with a high integrity token and full admin privileges without needing those privileges). UAC was introduced to fix this.

»Note: All of the following explanations assume that UAC is enabled and the administrative user we’re talking about is not the local RID-500er administrator (we get to that special case afterwards)

Since UAC was introduced in Windows Vista, when an admin logs in two access tokens are created:

• A Full Admin Token, also often referred to as ‘Non-filtered Token’ or ‘Full Token’, with high Integrity Level (IL) and all administrative privileges
• A filtered admin token, also often referred to as ‘Standard Token’ or ‘Restriced Token’, with medium integrity level (IL) and reduced privileges

These two tokens are linked together in the kernel, so that an executing thread could access both tokens if needed.
Now if an admin user logs into his account and launches cmd.exe this process will be spawned using the filtered, medium integrity token (remember: UAC is enabled and the user is not the RID-500 administrator). Thereby high access privileges are not given to processes that do not need those.
But in case the administrator user needs to run a process with full admin privileges he can ask the operating system to elevate this processes privileges with his full admin token, this is the ‘Run as administrator’-button. This will cause the prominent ‘consent’ prompt to pop up (C:\Windows\System32\consent.exe) as shown in the screenshot below:

Картинка с сайта: csandker.io

By accepting this consent prompt, the system will create the elevated process (in this case cmd.exe) with full admin privileges, as it can be seen in the screenshot below:

Картинка с сайта: csandker.io

The cmd.exe process (note that conhost.exe is the child processes created by cmd.exe) launched by the administrator without elevating is shown on the left and the elevated cmd.exe by hitting ‘Run as administrator’ is shown on the right.
Also compare the Integrity Levels and Privileges of these processes to determine which is which.

UAC for the RID-500er local Admin

All of the explanations above are only true for local or domain administrators that are not the RID-500er local admin. Each installation of Windows comes with a local Administrator account (which is disabled by default), that can be identified by the Relative Identifier (RID) of 500 (SID: S-1-5-21-DomainID—500).

The Story for the RID-500 local admin is that this account is not enrolled in UAC by default.
That means that if you log in to your Windows computer with the RID-500er local admin account you will be assigned a high privileged full access token right away (and don’t get a ‘filtered’ medium integrity token). If you run cmd.exe (or anything else) with the RID-500 local admin, even without specifying ‘Run as administrator’, then the cmd.exe will spawn with full administrative privileges and a high Integrity Level (because your only got a full token that the cmd.exe process can inherit). If you hit ‘Run as administrator’ with your RID-500er local admin there will be no consent prompt.

The RID-500er admin is by default not enrolled in UAC, but can be enrolled by setting the following registry key to ‘1’:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\FilterAdministratorToken

As shown in the following screenshot the FilterAdminstratorToken has been set to ‘1’ in this instance, which enrolls the RID-500er Admin in UAC (and thereby all of the rules mentioned previously would also apply for this user).

Картинка с сайта: csandker.io

Disabling UAC For Non-RID-500er Admins

So by default the RID-500er Admin is not enrolled in UAC, but all other admins (meaning local or domain users that are in the administrative group) are enrolled in UAC.
Now as the RID-500er admin user can be enrolled in UAC, also the Non-RID-500er admins can be dis-enrolled from UAC, by setting the LocalAccountTokenFilterPolicy to ‘1’.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy

This registry key is not set by default, so if this key is missing all non RID-500er accounts are enrolled in UAC:

Картинка с сайта: csandker.io

UAC and Remote Access

All of the above is true for local access, meaning your user locally logs into the computer and executes processes. Now for remote access there is another addition to the story.

The short version: For remote access (e.g. via wmic) domain administrators are given a full high integrity access token, but local Non-RID-500er admins will only be given a medium integrity restricted token.

Terming it the Microsoft way:

1) Remote Access for Local Admins (Non-RID-500er):
Source: https://support.microsoft.com/en-us/help/951016/description-of-user-account-control-and-remote-restrictions-in-windows

When a user who is a member of the local administrators group on the target remote computer establishes a remote administrative connection … they will not connect as a full administrator. The user has no elevation potential on the remote computer, and the user cannot perform administrative tasks. If the user wants to administer the workstation with a Security Account Manager (SAM) account, the user must interactively log on to the computer that is to be administered with Remote Assistance or Remote Desktop.

2) Remote Access for Domain Admins:
Source: https://support.microsoft.com/en-us/help/951016/description-of-user-account-control-and-remote-restrictions-in-windows

When a user with a domain user account logs on to a Windows Vista computer remotely, and the user is a member of the Administrators group, the domain user will run with a full administrator access token on the remote computer and UAC is disabled for the user on the remote computer for that session.

» This addition to UAC applies for remote administrative access, this does not affect Remote Desktop connections (which are considered as local logon).

UAC And Pass-the-Hash

Now comes the kicker.. Let’s face the following question:

Q: The following accounts try to establish a remote connection to a computer with default settings via a pth-attack (pass-the-hash) (using psexec or wmic).
Who will be able to establish a successful remote connection and why?

• a) The Local ‘Administrator’ — SID: S-1-5-21DomainID-500
• b) The Local user ‘LocalAdm’ who is member of the local Administrators Group (SID: S-1-5-32-544)
• c) The domain user ‘Lab\Frank’ who is a standard domain user without administrative privileges
• d) The domain user ‘Lab\Bob’ who is a member of the domain Administrators group

Be aware that remote access requires to launch high privileges processes and consider that there is no way to remotely elevate privileges.

——– SPOILER / ANSWER ——–

Answer: a) & d) are correct

And here’s why:
a) –> The local 500er Admin is not enrolled in UAC per default. The 500er admin receives a full access token per default and can establish a remote connection.
b) –> The non-500er local Admin is enrolled in UAC, but does not receive a full access token.

The full story here is: The non-500er admins tries to log in and gets a standard/medium access token. The remote connection access requires to start full token administrative access processes, which the user does not have (he/she got the medium token). Thereby his connection is refused.
c) –> Same story as for the non-500er local Admin. He/she gets a standard (medium) token and is rejected.
d) –> The domain admin is enrolled in UAC but gets automatically elevated. This is the exception that applies to remote access compared to local access.

The full story is: The domain admin, tries to log in, automatically receives a full/admin access token (instead of a standard/medium access token) and is able to get a remote shell.

If you’re still interested i also recommend a read over harmj0y’s blog post on Pass-the-Hash Is Dead: Long Live LocalAccountTokenFilterPolicy https://www.harmj0y.net/blog/redteaming/pass-the-hash-is-dead-long-live-localaccounttokenfilterpolicy/

Bonus Kicker: As mentioned before, the UAC remote rules do not apply for remote desktop connections. Therefore, if your user is part of the remote desktop user group you could also go for pass-the-hash via remote desktop, as described here: https://www.kali.org/penetration-testing/passing-hash-remote-desktop/

Access Tokens

So far when talking about basic access checks or UAC, user ‘access tokens’ were introduced. This access tokens hold information about the current user and the user’s groups and are for example used by the Security Reference Monitor (SRM) to determine who is requesting access.

These tokens are of major relevance for the access check and also play a role for certain privilege escalation attacks. Therefore it’s worth getting a closer look at access tokens.

So to start with there are only two kinds of token:

• Primary Tokens, which are assigned to processes; and
• Impersonation Tokens that are assigned to threads

Two kinds of tokens, that’s it. ‘Filtered tokens’, ‘Restricted Tokens’, ‘Full Tokens’, ‘Admin Tokens’, or in general ‘Access Tokens’, are just names given to describe the token, but all of these are Impersonation Tokens.
Both, primary and impersonation tokens, consist of the following major fields:

• User SID: the SID of the user (impersonation token) or the SID of the user that created the process (Primary token)
• Group SIDs: Group SIDs of the corresponding user (User SID)
• Logon SID: Identifies the current logon session
• Privileges: List of Privileges the User (impersonation token or process has)
• Primary Group SID: identifies the primary group of the impersonated user (impersonation token), e.g. ‘Domain Users’
• Default DACL: The default DACL that the system uses when a user creates a securable object without specifying a security descriptor (comparable to Linux umask)
• Type: Information if token is primary or impersonation
• Impersonation Level: The degree (level) of allowed impersonation.
• Integrity Level: SID of integrity level
• …

It is the token that is passed to the SRM to determine if a process has access to an object, therefore if you are able to obtain a high privileged token, you can escalate your privileges.

To get a hands on experience with tokens, James Forshaw develop the great tool Token Viewer (contained in the Sandbox-AttackSurface-Analysis-Tools), which is shown below:

Картинка с сайта: csandker.io

In the right window a list of processes is shown. The token of one of the high integrity cmd.exe processes was opened and is shown in the left window. Notice that the token type is primary (because it’s a process) and the Integrity Level (IL) is set to High (because the cmd.exe process was started as elevated process by an admin).
Keep in mind that each process has a token assigned to it and this token is always a primary token.

Now let’s move to threads. Remember from the introduction that a user is assigned with a token once the user logs in and more precisely that means that the user’s logon thread is assigned with an impersonation token. A process can only have a primary token, but a thread can have an impersonation token as well as a primary token, in which case the impersonation token will always take primary over the primary token.
(… yep I know. Microsoft just sucks when it comes to naming things)

An example of an impersonation token is given below:

Картинка с сайта: csandker.io

Notice that the token type now says ‘Impersonation’ and that now also the field ‘Impersonation Level’ is set to ‘Impersonation’. The impersonation level is an important field that influences if a token can be impersonated (more on this in the next section).

So far so good. The key take away here is that there are only two types of tokens for processes and threads.

Impersonation

The process of impersonation is quite important and frequently used in the Windows authorization process. To understand why impersonation is used we first must take a step back:

Imagine a user wants to delete a file on a remote file share. Now the server hosting the file needs to determine if the user is allowed to do that. The server can’t access the user’s access token because that token is not accessible in the remote server’s memory (the token is stored on the computer of the user requesting to delete the file). What the server could do is query the user’s account and group information from the Active Directory (AD) and check manually if the user is allowed to delete files, but this task is tedious and prone to errors. Therefore another approach was implemented and termed ‘Impersonation’.

The basic idea is that the server simply pretends to be the requesting user and carries out the requested action as if the server was the user. So what the server does is it duplicates the user’s Impersonation token and requests the action (e.g. delete a file) with that duplicated token (as if the server was the user).

Impersonation is a powerful feature, it enables a process to pretend to be someone else.

OK Million dollar idea: I just impersonate the token of a high privileged user and gain instant privilege escalation! … Nice thought, but obviously it cannot be that easy. There are two obstacles in the way:

• a) Not every impersonation token can be used to carry out actions
• b) You need special privileges to be able to ‘impersonate’ a token (which technically means duplicate a token)

The first obstacle is that not every token is actually ‘valuable’. What that means is that each impersonation token got an attribute called Impersonation Level, that can have one of the following values:

• Anonymous Level — the server can impersonate the client, but the token does not contain any information about the client. Anonymous level is only supported for inter process communication (e.g. for named pipes). All other transports silently promote this to ‘Identification Level’
• Identification Level — This is the default. The server can obtain the identity of the client in order to do ACL checks. You can use that token to read information about the impersonated user or check the resources ACL, but you can’t actually access that resource (read/write/execute)
• Impersonate Level — The server can impersonate the security context of the client in order to access local resources. If the server is local, it can access local and network resources. If the server is remote it can only access resources on the same machine as the server.
• Delegate Level — The most powerful impersonation level. The server can impersonate the security context of the client to access local or remote resources.

So what you want is an Impersonation or Delegation Level impersonation token to be able to actually do anything (a little more on this in the next section).

The second obstacle in your way is that you need special privileges in order to be able to duplicate (impersonate) another token. That special privilege is TOKEN_DUPLICATE (as specified in Access Rights for Access-Token Objects).
The plot twist here is that if you do not hold this privilege, your request to duplicate a token is not denied, you still get a duplicated token, but one with a lower Impersonation Level.
The flow of duplicating/impersonating another token is shown below:

Картинка с сайта: csandker.io

So at the end of the day you either hold the TOKEN_DUPLICATE privilege (or compromised a process that holds this) or you end up with an Identification Level token, which is supposedly of no use to an attacker because you can’t carry out any action with that.

At this point we’re almost done with tokens. The following sections are meant to get you into the mind-set of privilege escalation attacks based on tokens…

Privilege Escalation With Identification Tokens

The previous section describes that it is pretty easy to obtain an identification token.
To once more underline the fact that this is true, I activated the local administrator account on my windows machine and used Forshaw’s Token Viewer tool, to impersonate the Administrators Impersonation token (for more details check out His 2015 BlackHat Talk):

Картинка с сайта: csandker.io

I ran this tool with a standard non admin user, and still got access to the Administrators token. It feels odd, but based on the access check for duplicate tokens that was presented in the previous section, this is all as it should be.
Notice that I only gained an Identification Impersonation Token.
There should be not much that I can do with that token, especially not carry out administrative tasks or access protected resources…

… unless of course some programmers forget to check the Impersonation Level of the token that is presented for authorization checks. James Forshaw found that this happened for some windows components, which resulted in CVE-2015-0002 as shown for example in this PoC.

I highly recommend to review James 2015 BlackHat Talk to understand the full impact and application of this vulnerability, but the basic story for this was that a certain Windows component made an access check to verify if the presented impersonation token belongs to an Administrator, but the component only checked the Impersonation type and the associated groups and totally ignored the impersonation level, which resulted in access for any user that could present a high integrity identification token with administrative groups… Amazing finding!

Privilege Escalation By Leaky Tokens

Another privilege escalation vulnerability that Forshaw found is what he termed ‘Leaky Tokens’. The basic idea of this kind of vulnerability is as follows:

Kernel code can access any kind of token to read and manipulate it. So what if you found a Windows kernel component that just gives out tokens, that it had accessed, back to the user ?!
It sounds a bit too obvious that this is flawed, but Forshaw found that an undocumented win32k system call existed that passed a previously used token right back to the user.

This flaw exited in the kernel code for the Windows clipboard (used for copy+paste). So once an administrator copied something (e.g. say text from an editor), any user could call the undocumented function NtUserGetClipboardToken and get back the previously used admin access token.

This was raised by Forshaw in CVE-2015-0087.

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

Как работает аутентификация Windows

Аутентификации Windows (NTLM) и LDAP могут работать независимо друг от друга. Аутентификация Windows требует ввода учетных данных пользователя в окне авторизации браузера. А аутентификация LDAP использует проверку пароля пользователя на сервере Active Directory. Аутентификации Windows (NTLM) и LDAP работают вместе, когда пользователь нажимает ссылку “Войти под доменным пользователем”, и его аккаунт синхронизирован с LDAP.

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

Выполняется проверка авторизации пользователя в домене.

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

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

Если пользователь не синхронизирован с LDAP:

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

Если пользователь синхронизирован с LDAP:

Браузер посылает запрос в службу Active Directory для проверки подлинности пользователя.

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

На заметку. Проверка подлинности выполняется как среди пользователей основного приложения, так и среди пользователей портала самообслуживания. Порядок проверки настраивается в файле Web.config приложения-загрузчика. Подробнее >>>

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

Настройка выполняется на сервере, где развернуто приложение, и включает в себя:

Настройку сервера IIS, которая активирует аутентификацию по протоколу NTLM. Подробнее >>>

Настройку файла Web.config приложения-загрузчика, которая определяет провайдеров аутентификации и порядок проверки наличия пользователей среди зарегистрированных в Creatio. Подробнее >>>

Настроить аутентификацию Windows в IIS

Для приложения-загрузчика и веб-приложения включите анонимную аутентификацию и аутентификацию форм ( Рис. 1 ).

На заметку. Обратите внимание, что необходимо выключить настройку “Windows Authentication”, которая в IIS включена по умолчанию.

Для директории Login внутри приложения-загрузчика отключите аутентификацию форм и включите анонимную аутентификацию и аутентификацию Windows ( Рис. 2 ).

Обратите внимание, что анонимная аутентификация приложения-загрузчика и рабочих приложений должна выполняться под пользователем Application Pool Identity. Для этого перейдите в окно редактирования данных входа настроек Authentication по кнопке Edit в боковом меню Actions менеджера IIS, и выберите пользователя “Application Pool Identity” ( Рис. 3 ).

Настроить файл Web.config приложения-загрузчика

InternalUserPassword — провайдер, указанный в файле Web.config по умолчанию. Если вы хотите предоставить возможность аутентификации по NTLM-протоколу только пользователям, которые не синхронизированы с LDAP, не указывайте для параметра providerNames дополнительные значения.

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

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

NtlmUser — добавьте к значениям параметра autoLoginProviderNames данный провайдер, чтобы предоставить возможность аутентификации по NTLM-протоколу пользователям приложения, независимо от того, синхронизированы ли они с LDAP и какой тип аутентификации установлен для данных пользователей в Creatio.

SSPNtlmUser — добавьте к значениям параметра autoLoginProviderNames данный провайдер, чтобы предоставить возможность аутентификации по NTLM-протоколу пользователям портала самообслуживания, независимо от того, синхронизированы ли они с LDAP и какой тип аутентификации установлен для данных пользователей в Creatio.

Если после выполнения описанных действий при первой попытке входа в систему отображается окно доменной авторизации, то необходимо дополнительно настроить свойства обозревателя Windows.

Чтобы в дальнейшем окно доменной авторизации не отображалось:
В меню “Start” —> “Settings” —> “Control Panel” —> “Network and Internet” выберите пункт “Internet options” ( Рис. 1 ).

Откройте для редактирования файл Web.config приложения-загрузчика.

Укажите в файле провайдеры аутентификации Windows:

Если вы хотите активировать сквозную аутентификацию, чтобы пользователь имел возможность авторизоваться в Creatio, минуя страницу входа, укажите значение “true” для параметра UsePathThroughAuthentication элемента :

В открывшемся окне перейдите на вкладку “Security” и по кнопке “Custom level” перейдите к настройкам безопасности ( Рис. 2 ).

В группе настроек “User Authentication” выберите способ авторизации “Automatic logon with current user name and password” ( Рис. 3 ).

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

Источник

Аутентификация и авторизация

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

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

Что такое аутентификация и авторизация?

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

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

Есть два варианта авторизации:

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

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

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

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

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

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

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

Биометрия.

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

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

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

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

Для того, чтобы разрешить эту идентификацию пользователи должны связать свою учетную запись пользователя Windows ID онлайн. Включение в Windows протокола Public Key Cryptography Based User-to-User (PKU2U) разрешает проходить идентификацию при помощи свидетельств.

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

Источник

Двухфакторная аутентификация в Windows и шифрование данных без центра сертификации и домена

Сегодня расскажем, как можно быстро и просто настроить двухфакторную аутентификацию и зашифровать важные данные, причем даже с возможностью использования биометрии. Решение будет актуально для небольших компании или просто для персонального компьютера или ноутбука. Важно, что для этого нам не потребуется инфраструктура открытых ключей (PKI), сервер с ролью центра сертификации (Certificate Services) и даже не потребуется домен (Active Directory). Все системные требования будут сводиться к операционной системе Windows и наличию у пользователя электронного ключа, а в случае биометрической аутентификацией еще и считывателю отпечатка пальцев, который, например, может быть уже встроен в ваш ноутбук.

Для аутентификации будем использовать ПО нашей разработки – JaCarta SecurLogon и электронный ключ JaCarta PKI в качестве аутентификатора. Инструментом шифрования будет штатный Windows EFS, доступ к зашифрованным файлам будет осуществляться также через ключ JaCarta PKI (тот же, который используется для аутентификации).

Напомним, JaCarta SecurLogon — сертифицированное ФСТЭК России программно-аппаратное решение компании Аладдин Р.Д., позволяющее осуществить простой и быстрый переход от однофакторной аутентификации на основе пары логин-пароль к двухфакторной аутентификации в ОС по USB-токенам или смарт-картам. Суть работы решения довольно проста — JSL генерирует сложный пароль (

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

EFS также как и JSL умеет работать в режиме standalone, не требуя кроме самой ОС ничего. Во всех операционных системах Microsoft семейства NT, начиная с Windows 2000 и новее (кроме home версий), существует встроенная технология шифрования данных EFS (Encrypting File System). EFS-шифрование основано на возможностях файловой системы NTFS и архитектуре CryptoAPI и предназначено для быстрого шифрования файлов на жестком диске компьютера. Для шифрования в EFS используется закрытый и открытый ключи пользователя, которые генерируются при первом использовании пользователем функции шифрования. Данные ключи остаются неизменными все время, пока существует его учетная запись. При шифровании файла EFS случайным образом генерирует уникальный номер, так называемый File Encryption Key (FEK) длиной 128 бит, с помощью которого и шифруются файлы. Ключи FEK зашифрованы мастер-ключом, который зашифрован ключом пользователей системы, имеющего доступ к файлу. Закрытый ключ пользователя защищается хэшем пароля этого самого пользователя. Данные, зашифрованные с помощью EFS, могут быть расшифрованы только с помощью той же самой учетной записи Windows с тем же паролем, из-под которой было выполнено шифрование. А если хранить сертификат шифрования и закрытый ключ на USB-токене или смарт-карте, то для доступа к зашифрованным файлам потребуется еще и этот USB-токен или смарт-карта, что решает проблему компрометации пароля, так как будет необходимо наличие и дополнительного устройства в виде электронного ключа.

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

Как уже отметили, для настройки не нужен AD или центр сертификации, нужен любой современный Windows, дистрибутив JSL и лицензия. Настройка проста до безобразия.

Нужно установить файл лицензии.

Картинка с сайта: hand.post-ap.ru

Добавить профиль пользователя.

Картинка с сайта: hand.post-ap.ru

Картинка с сайта: hand.post-ap.ru

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

Картинка с сайта: hand.post-ap.ru

Картинка с сайта: hand.post-ap.ru

Биометрическая аутентификация

Есть возможность использовать биометрическую аутентификацию по отпечатку пальца. Решение работает по технологии Match On Card. Хэш отпечатка записывается на карту при первичной инициализации и в дальнейшем сверяется с оригиналом. Из карты никуда не уходит, в каких-то базах не хранится. Для разблокировки такого ключа используется отпечаток или комбинация ПИН + отпечаток, ПИН или отпечаток.

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

Картинка с сайта: hand.post-ap.ru

Картинка с сайта: hand.post-ap.ru

В дальнейшем такое же окно будет всплывать перед входом в ОС.

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

Картинка с сайта: hand.post-ap.ru

После предъявления отпечатка или ПИН-кода, пользователь попадет в ОС.

Шифрование данных

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

Для выпуска сертификата шифрования и закрытого ключа откройте учетную запись пользователя, выберите — Управление сертификатами шифрования файлов. В открывшемся мастере, создайте самозаверенный сертификат на смарт-карте. Так как мы продолжаем использовать смарт-карту с BIO-апплетом, для записи сертификата шифрования нужно предъявить отпечаток или ПИН.

Картинка с сайта: hand.post-ap.ru

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

Картинка с сайта: hand.post-ap.ru

Далее система еще раз попросит ввести ПИН или предьявить отпечаток, произойдет непосредственный выпуск сертификата на смарт-карту.

Картинка с сайта: hand.post-ap.ru

Далее нужно настроить конкретные директории. В нашем примере — это папка Документы в хомяке пользователя. Откройте свойства папки и укажите — Шифровать содержимое для защиты данных.

Картинка с сайта: hand.post-ap.ru

Далее укажите применять настройки только к текущей папке или включить все вложенные поддиректории.

Картинка с сайта: hand.post-ap.ru

Сама шифрованная директория и файлы в ней будут подсвечены другим цветом.

Картинка с сайта: hand.post-ap.ru

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

Картинка с сайта: hand.post-ap.ru

На этом вся настройка окончена.

Можно использовать оба сценария (аутентификация и шифрование), можно остановиться на чем-то одном.

Источник

Встроенная аутентификация Windows с расширенной защитой Integrated Windows Authentication with Extended Protection

Были добавлены улучшения, которые влияют на обработку встроенной проверки подлинности Windows в HttpWebRequest, HttpListener, SmtpClient, SslStream, NegotiateStream и связанных классах в System.Net и соответствующих пространствах имен. Enhancements were made that affect how integrated Windows authentication is handled by the HttpWebRequest, HttpListener, SmtpClient, SslStream, NegotiateStream, and related classes in the System.Net and related namespaces. Была добавлена поддержка расширенной защиты для повышения безопасности. Support was added for extended protection to enhance security.

Эти изменения могут влиять на приложения, которые используют эти классы для создания веб-запросов и получения ответов, в которых используется встроенная проверка подлинности Windows. These changes can affect applications that use these classes to make web requests and receive responses where integrated Windows authentication is used. Это изменение также может повлиять на веб-серверы и клиентские приложения, в которых используется встроенная проверка подлинности Windows. This change can also impact web servers and client applications that are configured to use integrated Windows authentication.

Эти изменения могут также влиять на приложения, которые используют эти классы для создания других типов запросов и получения ответов, в которых используется встроенная проверка подлинности Windows. These changes can also affect applications that use these classes to make other types of requests and receive responses where integrated Windows authentication is used.

Изменения для поддержки расширенной защиты будут доступны только для приложений в Windows 7 и Windows Server 2008 R2. The changes to support extended protection are available only for applications on Windows 7 and Windows Server 2008 R2. Функции расширенной защиты недоступны в более ранних версиях Windows. The extended protection features are not available on earlier versions of Windows.

Обзор Overview

Структура встроенной проверки подлинности Windows позволяет формировать универсальные ответы на некоторые запросы учетных данных. Это означает, что эти ответы можно повторно использовать или перенаправлять. The design of integrated Windows authentication allows for some credential challenge responses to be universal, meaning they can be re-used or forwarded. Ответы на запросы должны обязательно содержать сведения о целевом объекте, а также могут содержать некоторые сведения о канале. The challenge responses should be constructed at a minimum with target specific information and preferably also with some channel specific information. Кроме того, службы могут предоставлять расширенную защиту, чтобы в ответах на запросы учетных данных также содержались сведения о службе, например имя субъекта-службы. Services can then provide extended protection to ensure that credential challenge responses contain service specific information such as a Service Principal Name (SPN). С включением этих сведений в ответы на запросы учетных данных службы могут обеспечить лучшую защиту при изменении ответов на запросы учетных данных злоумышленниками. With this information in the credential exchanges, services are able to better protect against malicious use of credential challenge responses that might have been improperly used.

Механизм расширенной защиты представляет собой улучшение протоколов проверки подлинности, предназначенное для исключения атак на ретрансляторы проверки подлинности. The extended protection design is an enhancement to authentication protocols designed to mitigate authentication relay attacks. Это улучшение связано с концепцией каналов и сведениями о привязке службы. It revolves around the concept of channel and service binding information.

Общие цели улучшения таковы. The overall objectives are the following:

При обновлении клиента для поддержки расширенной защиты приложения должны предоставить сведения о привязке канала и привязке службы для всех поддерживаемых протоколов проверки подлинности. If the client is updated to support the extended protection, applications should supply a channel binding and service binding information to all supported authentication protocols. Сведения о привязке канала могут быть предоставлены только при наличии канала (TLS), к которому выполняется привязка. Channel binding information can only be supplied when there is a channel (TLS) to bind to. Сведения о привязке службы должны предоставляться всегда. Service binding information should always be supplied.

Обновленные серверы, которые правильно настроены, могут проверять сведения о привязке для канала и службы, если эти сведения содержатся в маркере проверки подлинности клиента, и отклонять попытки проверки подлинности, если привязки каналов не совпадают. Updated servers which are properly configured may verify the channel and service binding information when it is present in the client authentication token and reject the authentication attempt if the channel bindings do not match. В зависимости от сценария развертывания серверы могут проверять привязку канала, привязку службы или обе привязки. Depending on the deployment scenario, servers may verify channel binding, service binding or both.

Обновленные серверы могут принимать или отклонять запросы клиентов нижнего уровня, которые не содержат сведений о привязке канала, на основе политики. Updated servers have the ability to accept or reject down-level client requests that do not contain the channel binding information based on policy.

Сведения, используемые для расширенной защиты, включают в себя один или оба следующих компонента: Information used by extended protection consists of one or both of the following two parts:

Маркер привязки канала. A Channel Binding Token or CBT.

Сведения о привязке службы в виде имени субъекта-службы. Service Binding information in the form of a Service Principal Name or SPN.

Сведения о привязке службы свидетельствуют о намерении клиента проверить подлинность для конкретной конечной точки службы. Service Binding information is an indication of a client’s intent to authenticate to a particular service endpoint. Эти сведения передаются от клиента на сервер с помощью следующих свойств: It is communicated from client to server with the following properties:

Значение имени субъекта-службы должно быть доступно на сервере, выполняющем проверку подлинности клиента, в виде открытого текста. The SPN value must be available to the server performing client authentication in clear text form.

Значение имени субъекта-службы является открытым. The value of the SPN is public.

Имя субъекта-службы должно быть криптографически защищено во время передачи, чтобы его было невозможно вставить, удалить или изменить с помощью атаки «человек посередине». The SPN must be cryptographically protected in transit such that a man-in-the-middle attack cannot insert, remove or modify its value.

Маркер привязки канала — это свойство внешнего безопасного канала (например, TLS), которое используется для привязки этого канала к обмену данными во внутреннем канале, проверку подлинности которого выполнил клиент. A CBT is a property of the outer secure channel (such as TLS) used to tie (bind) it to a conversation over an inner, client-authenticated channel. Маркер привязки канала должен иметь следующие свойства (эти свойства также определяются в стандарте RFC 5056, принятом IETF): The CBT must have the following properties (also defined by IETF RFC 5056):

При наличии внешнего канала значение маркера привязки канала должно определять внешний канал или конечную точку сервера. Маркер привязки канала должен быть получен обеими сторонами обмена (клиентской и серверной) независимо друг от друга. When an outer channel exists, the value of the CBT must be a property identifying either the outer channel or the server endpoint, independently arrived at by both client and server sides of a conversation.

Злоумышленник не должен иметь возможность повлиять на значение маркера привязки канала. Value of the CBT sent by the client must not be something an attacker can influence.

Конфиденциальность маркера привязки канала не гарантируется. No guarantees are made about secrecy of the CBT value. Однако это не означает, что значение привязки службы и сведения о привязке канала могут быть доступны кому-то, кроме сервера, выполняющего проверку подлинности, так как протокол, посредством которого передается маркер привязки канала, может шифровать этот маркер. This does not however mean that the value of the service binding as well as channel binding information can always be examined by any other but the server performing authentication, as the protocol carrying the CBT may be encrypting it.

Целостность маркера привязки канала должна быть криптографически защищена во время передачи, чтобы его значение было невозможно вставить, удалить или изменить с помощью атаки «человек посередине». The CBT must be cryptographically integrity protected in transit such that an attacker cannot insert, remove or modify its value.

Привязка канала выполняется клиентом, который передает имя субъекта-службы и маркер привязки канала на сервер в защищенном режиме. Channel binding is accomplished by the client transferring the SPN and the CBT to the server in a tamperproof fashion. Сервер проверяет сведения о привязке канала в соответствии со своей политикой и отклоняет попытки проверки подлинности, целевым объектом которых он не является. The server validates the channel binding information in accordance with its policy and rejects authentication attempts for which it does not believe itself to have been the intended target. Таким образом, два каналы становятся криптографически связанными друг с другом. This way, the two channels become cryptographically bound together.

Для сохранения совместимости с существующими клиентами и приложениями сервер можно настроить таким образом, чтобы разрешить попытки проверки подлинности для клиентов, которые еще не поддерживают расширенную защиту. To preserve compatibility with existing clients and applications, a server may be configured to allow authentication attempts by clients that do not yet support extended protection. Это называется «частично усиленной» конфигурацией в отличие от «полностью усиленной» конфигурации. This is referred to as a «partially hardened» configuration, in contrast to a «fully hardened» configuration.

Несколько компонентов в пространствах имен System.Net и System.Net.Security выполняют встроенную проверку подлинности Windows от имени вызывающего приложения. Multiple components in the System.Net and System.Net.Security namespaces perform integrated Windows authentication on behalf of a calling application. В этом разделе описаны изменения в компонентах System.Net для добавления расширенной защиты при использовании встроенной проверки подлинности Windows в этих компонентах. This section describes changes to System.Net components to add extended protection in their use of integrated Windows authentication.

Расширенная защита поддерживается в Windows 7. Extended protection is currently supported on Windows 7. Предоставляется механизм, с помощью которого приложение может определить, поддерживает ли операционная система расширенную защиту. A mechanism is provided so an application can determine if the operating system supports extended protection.

Изменения для поддержки расширенной защиты Changes to Support Extended Protection

Процесс проверки подлинности, используемый со встроенной проверкой подлинности Windows, в зависимости от протокола проверки подлинности часто включает в себя запрос, который выдается компьютером назначения и отправляется обратно на клиентский компьютер. The authentication process used with integrated Windows authentication, depending on the authentication protocol used, often includes a challenge issued by the destination computer and sent back to the client computer. Расширенная защита добавляет новые функции при проверке подлинности Extended protection adds new features to this authentication process

Пространство имен System.Security.Authentication.ExtendedProtection обеспечивает поддержку проверки подлинности для приложений с использованием расширенной защиты. The System.Security.Authentication.ExtendedProtection namespace provides support for authentication using extended protection for applications. Класс ChannelBinding в этом пространстве имен представляет привязку каналов. The ChannelBinding class in this namespace represents a channel binding. Класс ExtendedProtectionPolicy в этом пространстве имен представляет политику расширенной защиты, используемую сервером для проверки входящих клиентских подключений. The ExtendedProtectionPolicy class in this namespace represents the extended protection policy used by the server to validate incoming client connections. Другие члены класса используются с расширенной защитой. Other class members are used with extended protection.

Для серверных приложений к таким классам относятся следующие: For server applications, these classes include the following:

Класс ExtendedProtectionPolicy, содержащий следующие элементы: A ExtendedProtectionPolicy that has the following elements:

Свойство OSSupportsExtendedProtection, которое указывает, поддерживает ли операционная система встроенную проверку подлинности Windows с расширенной защитой. An OSSupportsExtendedProtection property that indicates whether the operating system supports integrated windows authentication with extended protection.

Значение PolicyEnforcement, указывающее, когда следует применять расширенную политику защиты. A PolicyEnforcement value that indicates when the extended protection policy should be enforced.

Значение ProtectionScenario, которое указывает сценарий развертывания. A ProtectionScenario value that indicates the deployment scenario. Это влияет на проверку расширенной защиты. This influences how extended protection is checked.

Необязательный объект ServiceNameCollection, содержащий пользовательский список имен субъектов-служб, который используется для проверки имени субъекта-службы, предоставленного клиентом в виде целевого объекта проверки подлинности. An optional ServiceNameCollection that contains the custom SPN list that is used to match against the SPN provided by the client as the intended target of the authentication.

Необязательный объект ChannelBinding, содержащий пользовательскую привязку канала, используемую при проверке. An optional ChannelBinding that contains a custom channel binding to use for validation. Этот сценарий не является наиболее распространенным. This scenario is not a common case

Пространство имен System.Security.Authentication.ExtendedProtection.Configuration обеспечивает поддержку настройки проверки подлинности для приложений с использованием расширенной защиты. The System.Security.Authentication.ExtendedProtection.Configuration namespace provides support for configuration of authentication using extended protection for applications.

В существующем пространстве имен System.Net были изменены некоторые функции для поддержки расширенной защиты. A number of feature changes were made to support extended protection in the existing System.Net namespace. К этим изменениям относятся следующие: These changes include the following:

В пространство имен System.Net добавлен новый класс TransportContext, который представляет контекст транспорта. A new TransportContext class added to the System.Net namespace that represents a transport context.

В класс HttpWebRequest добавлены новые перегрузки методов EndGetRequestStream и GetRequestStream, которые позволяют получить TransportContext для поддержки расширенной защиты клиентских приложений. New EndGetRequestStream and GetRequestStream overload methods in the HttpWebRequest class that allow retrieving the TransportContext to support extended protection for client applications.

Дополнения к классам HttpListener и HttpListenerRequest для поддержки серверных приложений. Additions to the HttpListener and HttpListenerRequest classes to support server applications.

Была изменена функция для поддержки расширенной защиты для клиентских приложений SMTP в существующем пространстве имен System.Net.Mail: A feature change was made to support extended protection for SMTP client applications in the existing System.Net.Mail namespace:

В существующем пространстве имен System.Net.Security были изменены некоторые функции для поддержки расширенной защиты. A number of feature changes were made to support extended protection in the existing System.Net.Security namespace. К этим изменениям относятся следующие: These changes include the following:

В класс NegotiateStream добавлены новые перегрузки методов BeginAuthenticateAsClient и AuthenticateAsClient, которые позволяют передавать маркер привязки канала для поддержки расширенной защиты клиентских приложений. New BeginAuthenticateAsClient and AuthenticateAsClient overload methods in the NegotiateStream class that allow passing a CBT to support extended protection for client applications.

В класс NegotiateStream добавлены новые перегрузки методов BeginAuthenticateAsServer и AuthenticateAsServer, которые позволяют передавать ExtendedProtectionPolicy для поддержки расширенной защиты серверных приложений. New BeginAuthenticateAsServer and AuthenticateAsServer overload methods in the NegotiateStream class that allow passing an ExtendedProtectionPolicy to support extended protection for server applications.

Новое свойство TransportContext в классе SslStream для поддержки расширенной защиты клиентских и серверных приложений. A new TransportContext property in the SslStream class to support extended protection for client and server applications.

В пространство имен System.Net.Security добавлено свойство SmtpNetworkElement для поддержки настройки расширенной защиты для клиентов SMTP. A SmtpNetworkElement property was added to support configuration of extended protection for SMTP clients in the System.Net.Security namespace.

Расширенная защита для клиентских приложений Extended Protection for Client Applications

Для большинства приложений расширенная защита поддерживается автоматически. Extended protection support for most client applications happens automatically. Классы HttpWebRequest и SmtpClient поддерживают расширенную защиту, если базовая версия Windows поддерживает расширенную защиту. The HttpWebRequest and SmtpClient classes support extended protection whenever the underlying version of Windows supports extended protection. Экземпляр HttpWebRequest отправляет имя участника-службы, сформированное из Uri. An HttpWebRequest instance sends an SPN constructed from the Uri. По умолчанию экземпляр SmtpClient отправляет имя участника-службы, сформированное из имени узла на почтовом сервере SMTP. By default, an SmtpClient instance sends an SPN constructed from the host name of the SMTP mail server.

Для пользовательской проверки подлинности клиентские приложения могут использовать методы HttpWebRequest.EndGetRequestStream(IAsyncResult, TransportContext) или HttpWebRequest.GetRequestStream(TransportContext) в классе HttpWebRequest, которые позволяют получить TransportContext и маркер привязки канала с помощью метода GetChannelBinding. For custom authentication, client applications can use the HttpWebRequest.EndGetRequestStream(IAsyncResult, TransportContext) or HttpWebRequest.GetRequestStream(TransportContext) methods in the HttpWebRequest class that allow retrieving the TransportContext and the CBT using the GetChannelBinding method.

Имя субъекта-службы для встроенной проверки подлинности Windows, которое отправляется экземпляром HttpWebRequest в заданную службу, можно переопределить, задав свойство CustomTargetNameDictionary. The SPN to use for integrated Windows authentication sent by an HttpWebRequest instance to a given service can be overridden by setting the CustomTargetNameDictionary property.

Свойство TargetName можно использовать для установки пользовательского имени субъекта-службы, которое будет использоваться во встроенной проверке подлинности Windows для соединения SMTP. The TargetName property can be used to set a custom SPN to use for integrated Windows authentication for the SMTP connection.

Расширенная защита для серверных приложений Extended Protection for Server Applications

HttpListener автоматически предоставляет механизмы для проверки привязок службы при проверке подлинности HTTP. HttpListener automatically provides mechanisms for validating service bindings when performing HTTP authentication.

В этой конфигурации при выполнении запроса к серверу с помощью внешнего безопасного канала у внешнего канала запрашивается привязка канала. In this configuration when a request is made to the server through an outer secure channel, the outer channel is queried for a channel binding. Эта привязка канала передается вызовам проверки подлинности SSPI, которые проверяют соответствие переданной привязки и привязки канала в BLOB-объекте проверки подлинности. This channel binding is passed to the authentication SSPI calls, which validate that the channel binding in the authentication blob matches. Существует три возможных результата: There are three possible outcomes:

Базовая операционная система сервера не поддерживает расширенную защиту. The server’s underlying operating system does not support extended protection. Запрос не будет передан в приложение, и клиенту будет возвращен ответ 401 (Не авторизовано). The request will not be exposed to the application, and an unauthorized (401) response will be returned to the client. В источник трассировки HttpListener будет записано сообщение с указанием причины сбоя. A message will be logged to the HttpListener trace source specifying the reason for the failure.

Если вызов SSPI завершается неудачно, это означает, что либо клиент предоставил привязку канала, которая не соответствует ожидаемому значению привязки, полученному из внешнего канала, либо клиенту не удалось предоставить привязку канала при настройке политики расширенной защиты на сервере для Always. The SSPI call fails indicating that either the client specified a channel binding that did not match the expected value retrieved from the outer channel or the client failed to supply a channel binding when the extended protection policy on the server was configured for Always. В обоих случаях запрос не будет передан в приложение, и клиенту будет возвращен ответ 401 (Не авторизовано). In both cases, the request will not be exposed to the application, and an unauthorized (401) response will be returned to the client. В источник трассировки HttpListener будет записано сообщение с указанием причины сбоя. A message will be logged to the HttpListener trace source specifying the reason for the failure.

Клиент указывает правильную привязку канала или получает возможность подключиться без указания привязки канала, так как политика расширенной защиты на сервере настроена со свойством WhenSupported. Запрос возвращается приложению для обработки. The client specifies the correct channel binding or is allowed to connect without specifying a channel binding since the extended protection policy on the server is configured with WhenSupported The request is returned to the application for processing. Имена служб не проверяются автоматически. No service name check is performed automatically. Приложение может выполнить собственную проверку имени службы с помощью свойства ServiceName, но в таких обстоятельствах это действие является избыточным. An application may choose to perform its own service name validation using the ServiceName property, but under these circumstances it is redundant.

По умолчанию список допустимых имен служб создается на основе префиксов, которые были зарегистрированы с HttpListener. A default list of allowed service names is created based on the prefixes which have been registered with the HttpListener. Для просмотра списка по умолчанию можно использовать свойство DefaultServiceNames. This default list can be examined through the DefaultServiceNames property. Если этот список не является исчерпывающим, приложение может указать пользовательскую коллекцию имен служб в конструкторе класса ExtendedProtectionPolicy, и эта коллекция будет использоваться вместо списка имен служб по умолчанию. If this list is not comprehensive, an application can specify a custom service name collection in the constructor for the ExtendedProtectionPolicy class which will be used instead of the default service name list.

В этой конфигурации при отправке запроса на сервер без использования внешнего безопасного канала проверка подлинности выполняется нормально без проверки привязки канала. In this configuration, when a request is made to the server without an outer secure channel authentication proceeds normally without a channel binding check. Если проверка подлинности завершается успешно, то в контексте запрашивается имя службы, предоставленное клиентом, и это имя службы проверяется на соответствие списку допустимых имен служб. If the authentication succeeds, the context is queried for the service name that the client provided and validated against the list of acceptable service names. Существует четыре возможных результата: There are four possible outcomes:

Базовая операционная система сервера не поддерживает расширенную защиту. The server’s underlying operating system does not support extended protection. Запрос не будет передан в приложение, и клиенту будет возвращен ответ 401 (Не авторизовано). The request will not be exposed to the application, and an unauthorized (401) response will be returned to the client. В источник трассировки HttpListener будет записано сообщение с указанием причины сбоя. A message will be logged to the HttpListener trace source specifying the reason for the failure.

Базовая операционная система клиента не поддерживает расширенную защиту. The client’s underlying operating system does not support extended protection. В конфигурации WhenSupported попытка проверки подлинности завершится успешно, и запрос будет возвращен в приложение. In the WhenSupported configuration, the authentication attempt will succeed and the request will be returned to the application. В конфигурации Always попытка проверки подлинности завершится неудачно. In the Always configuration, the authentication attempt will fail. Запрос не будет передан в приложение, и клиенту будет возвращен ответ 401 (Не авторизовано). The request will not be exposed to the application, and an unauthorized (401) response will be returned to the client. В источник трассировки HttpListener будет записано сообщение с указанием причины сбоя. A message will be logged to the HttpListener trace source specifying the reason for the failure.

Базовая операционная система клиента поддерживает расширенную защиту, но в приложении не указана привязка службы. The client’s underlying operating system supports extended protection, but the application did not specify a service binding. Запрос не будет передан в приложение, и клиенту будет возвращен ответ 401 (Не авторизовано). The request will not be exposed to the application, and an unauthorized (401) response will be returned to the client. В источник трассировки HttpListener будет записано сообщение с указанием причины сбоя. A message will be logged to the HttpListener trace source specifying the reason for the failure.

В клиенте указана привязка службы. The client specified a service binding. Привязка службы сравнивается со списком допустимых привязок службы. The service binding is compared to the list of allowed service bindings. Если привязка соответствует списку, запрос возвращается приложению. If it matches, the request is returned to the application. В противном случае запрос не будет передан в приложение, и клиенту будет автоматически возвращен ответ 401 (Не авторизовано). Otherwise, the request will not be exposed to the application, and an unauthorized (401) response will be automatically returned to the client. В источник трассировки HttpListener будет записано сообщение с указанием причины сбоя. A message will be logged to the HttpListener trace source specifying the reason for the failure.

Эти функции расширенной защиты также могут использоваться серверными приложениями для проверки подлинности с другими типами запросов, а также при использовании доверенного прокси. These extended protection features can also be used by server applications for authentication with other types of requests and when trusted proxies are used.

Источник

Время на прочтение4 мин

Количество просмотров16K

Сегодня расскажем, как можно быстро и просто настроить двухфакторную аутентификацию и зашифровать важные данные, причем даже с возможностью использования биометрии. Решение будет актуально для небольших компании или просто для персонального компьютера или ноутбука. Важно, что для этого нам не потребуется инфраструктура открытых ключей (PKI), сервер с ролью центра сертификации (Certificate Services) и даже не потребуется домен (Active Directory). Все системные требования будут сводиться к операционной системе Windows и наличию у пользователя электронного ключа, а в случае биометрической аутентификацией еще и считывателю отпечатка пальцев, который, например, может быть уже встроен в ваш ноутбук.

Для аутентификации будем использовать ПО нашей разработки – JaCarta SecurLogon и электронный ключ JaCarta PKI в качестве аутентификатора. Инструментом шифрования будет штатный Windows EFS, доступ к зашифрованным файлам будет осуществляться также через ключ JaCarta PKI (тот же, который используется для аутентификации).

Напомним, JaCarta SecurLogon — сертифицированное ФСТЭК России программно-аппаратное решение компании Аладдин Р.Д., позволяющее осуществить простой и быстрый переход от однофакторной аутентификации на основе пары логин-пароль к двухфакторной аутентификации в ОС по USB-токенам или смарт-картам. Суть работы решения довольно проста — JSL генерирует сложный пароль (~63 символа) и записывает его в защищенную память электронного ключа. При этом пароль может быть неизвестен самому пользователю, пользователь знает только ПИН-код. Вводя ПИН-код при аутентификации, происходит разблокировка устройства, и пароль передается системе для аутентификации. Опционально можно заменить ввод ПИН-кода сканированием отпечатка пальца пользователя, а также можно применить комбинацию ПИН + отпечаток пальца.

EFS также как и JSL умеет работать в режиме standalone, не требуя кроме самой ОС ничего. Во всех операционных системах Microsoft семейства NT, начиная с Windows 2000 и новее (кроме home версий), существует встроенная технология шифрования данных EFS (Encrypting File System). EFS-шифрование основано на возможностях файловой системы NTFS и архитектуре CryptoAPI и предназначено для быстрого шифрования файлов на жестком диске компьютера. Для шифрования в EFS используется закрытый и открытый ключи пользователя, которые генерируются при первом использовании пользователем функции шифрования. Данные ключи остаются неизменными все время, пока существует его учетная запись. При шифровании файла EFS случайным образом генерирует уникальный номер, так называемый File Encryption Key (FEK) длиной 128 бит, с помощью которого и шифруются файлы. Ключи FEK зашифрованы мастер-ключом, который зашифрован ключом пользователей системы, имеющего доступ к файлу. Закрытый ключ пользователя защищается хэшем пароля этого самого пользователя. Данные, зашифрованные с помощью EFS, могут быть расшифрованы только с помощью той же самой учетной записи Windows с тем же паролем, из-под которой было выполнено шифрование. А если хранить сертификат шифрования и закрытый ключ на USB-токене или смарт-карте, то для доступа к зашифрованным файлам потребуется еще и этот USB-токен или смарт-карта, что решает проблему компрометации пароля, так как будет необходимо наличие и дополнительного устройства в виде электронного ключа.

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

Как уже отметили, для настройки не нужен AD или центр сертификации, нужен любой современный Windows, дистрибутив JSL и лицензия. Настройка проста до безобразия.

Нужно установить файл лицензии.

Картинка с сайта: habr.com

Добавить профиль пользователя.

Картинка с сайта: habr.com

Картинка с сайта: habr.com

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

Картинка с сайта: habr.com

Картинка с сайта: habr.com

Биометрическая аутентификация

Есть возможность использовать биометрическую аутентификацию по отпечатку пальца. Решение работает по технологии Match On Card. Хэш отпечатка записывается на карту при первичной инициализации и в дальнейшем сверяется с оригиналом. Из карты никуда не уходит, в каких-то базах не хранится. Для разблокировки такого ключа используется отпечаток или комбинация ПИН + отпечаток, ПИН или отпечаток.

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

Картинка с сайта: habr.com

Картинка с сайта: habr.com

В дальнейшем такое же окно будет всплывать перед входом в ОС.

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

Картинка с сайта: habr.com

После предъявления отпечатка или ПИН-кода, пользователь попадет в ОС.

Шифрование данных

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

Для выпуска сертификата шифрования и закрытого ключа откройте учетную запись пользователя, выберите — Управление сертификатами шифрования файлов. В открывшемся мастере, создайте самозаверенный сертификат на смарт-карте. Так как мы продолжаем использовать смарт-карту с BIO-апплетом, для записи сертификата шифрования нужно предъявить отпечаток или ПИН.

Картинка с сайта: habr.com

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

Картинка с сайта: habr.com

Далее система еще раз попросит ввести ПИН или предьявить отпечаток, произойдет непосредственный выпуск сертификата на смарт-карту.

Картинка с сайта: habr.com

Далее нужно настроить конкретные директории. В нашем примере — это папка Документы в хомяке пользователя. Откройте свойства папки и укажите — Шифровать содержимое для защиты данных.

Картинка с сайта: habr.com

Далее укажите применять настройки только к текущей папке или включить все вложенные поддиректории.

Картинка с сайта: habr.com

Сама шифрованная директория и файлы в ней будут подсвечены другим цветом.

Картинка с сайта: habr.com

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

Картинка с сайта: habr.com

На этом вся настройка окончена.

Можно использовать оба сценария (аутентификация и шифрование), можно остановиться на чем-то одном.