Лекция 5. Протоколы сетевой аутентификации. Модели разграничения доступа. Вредоносное программное обеспечение. | Методы и средства защиты компьютерной информации

Лекция 5. протоколы сетевой аутентификации. модели разграничения доступа. вредоносное программное обеспечение. | методы и средства защиты компьютерной информации

Местные окна одобрения

В операционных системах Windows локальная аутентификация выполняется следующим образом:

  1. Пользователь вводит логин и пароль
  2. Данные передаются подсистеме локальной безопасности (LSA), которая сразу преобразует пароль в хэш. В открытом виде пароли нигде не хранятся.
  3. Служба LSA обращается к диспетчеру учетных записей безопасности (SAM) и сообщает ему имя пользователя
  4. Диспетчер обращается в базу SAM и извлекает оттуда хэш пароля указанного пользователя, сгенерированный при создании учетной записи (или в процессе смены пароля)
  5. Затем LSA сравнивает хэши, в случае их совпадения аутентификация считается успешной, а хэш введенного пароля помещается в хранилище службы LSA и до окончания сеанса пользователя
    Схема работы локальной аутентификации Windows

Рис. 1. Схема работы локальной аутентификации Windows

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

В локальной сети существует несколько протоколов для аутентификации пользователей:

  • LAN Manager (LM),
  • NT LAN Manager (NTLM),
  • NT LAN Manager версии 2 (NTLM v2)

Рассмотрим актуальные на данный момент протоколы аутентификации – NTLM v2 и Kerberos.

Протокол NTLM v2.

Операционная система для протокола N TLMv2 с использованием контроллера домена

  1. Клиент при обращении к серверу сообщает ему имя пользователя и имя домена
  2. Сервер передает ему случайное число – запрос сервера
  3. Клиент генерирует также случайное число, куда, кроме прочего, добавляется метка времени, которое называется запрос клиента
  4. Запрос сервера объединяется с запросом клиента и от этой последовательности вычисляется HMAC-MD5 хэш
  5. От данного хэша берется еще один HMAC-MD5 хэш, ключом в котором выступает NT-хэш пароля пользователя. Получившийся результат называется NTLMv2-ответом и вместе с запросом клиента пересылается серверу
  6. Сервер, получив NTLMv2-ответ и запрос клиента, объединяет последний с запросом сервера и также вычисляет HMAC-MD5 хэш, затем передает его вместе с ответом контроллеру домена (КД)
  7. КД извлекает из хранилища сохраненный хэш пароля пользователя и производит вычисления над HMAC-MD5 хешем запросов сервера и клиента, сравнивая получившийся результат с переданным ему NTLMv2-ответом
  8. В случае совпадения серверу возвращается ответ об успешной аутентификации.
    Схема работы протокола NTLMv2 с контроллером домена
Похожее:  Ростелеком. Вход и регистрация в личном кабинете

Изображение 2. Работа протокола NTLMv2 в контроллере домена

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

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

В протоколе используется концепция Ticket (билет, сертификат).

Зашифрованный пакет данных, известный как “билет”, доставляется в надежный центр аутентификации.

Система KDC состоит из двух компонентов:

  • сервер аутентификации (англ. Authentication Server, сокр. AS);
  • сервер выдачи разрешений (англ. Ticket Granting Server, сокр. TGS).

Когда пользователь выполняет первичную аутентификацию, после успешного подтверждения его подлинности KDC выдаёт первичное удостоверение пользователя для доступа к сетевым ресурсам – TGT (Ticket Granting Ticket). В дальнейшем при обращении к отдельным сетевым ресурсам пользователь, предъявляя TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу – Service Ticket.
Схема работы протокола Kerberos

Рис. 3. Работа была завершена с использованием Kerberos.

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

В качестве примера реализации протоколов Kerberos следует упомянуть аутентификацию домена в операционных системах Microsoft, начиная с Windows 2000.

Протоколы аутентификации для удаленного доступа

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

Какие протоколы мы используем, и как они называются?

В качестве примера можно рассмотреть протоколы RADIUS.

Радио -аутентификация протокол

Протокол аутентификации Remote Authentication Dial-in User Service (RADIUS) 2 является методом аутентификации удаленных пользователей в средах с распределенной сетевой инфраструктурой.

В стандарте выделяются следующие роли:

Клиент ADIUS, R. Запросы на аутентификацию принимаются клиентом RADIUS. Каждый принятый запрос отправляется на сервер RADIUS для дальнейшей авторизации. Сервер удаленного доступа обычно выполняет роль клиента протокола RADIUS.

Сервер ADIUS R. Основной обязанностью сервера RADIUS является централизованная обработка данных, предоставляемых клиентами RIDIUS. Один сервер может обслуживать множество клиентов RADIUS. Учетные данные и подлинность пользователя подтверждаются сервером. Для аутентификации используются различные базы данных учетных данных.

Посредник R ADIUS RADIUS связь между клиентами и серверами использует специальные сообщения. В распределенных сетях между клиентом и сервером могут стоять различные сетевые устройства (например, маршрутизатор). Устройство, которое может перенаправлять сообщения RADIC, называется посредником RADIUS.

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

Internet Authentication Service (IAS) – это разновидность серверов и посредников RADIUS. Эта служба служит инструментом для централизованной проверки подлинности и авторизации пользователей по различным протоколам сетевых подключений. Службы маршрутизации и удаленного доступа, две другие сетевые службы, включенные в Windows Server 2003, интегрированы с IAS.

Как создать модель разграничения доступа

Для более тщательного анализа механизма авторизации рассмотрим следующие модели управления доступом:

  • Дискреционный контроль доступа, DAC
  • Обязательный контроль доступа, MAC
  • Ролевой контроль доступа, RBAC
  • Контроль доступа на основе атрибутов, ABAC
  • Гибридные моделии.

Контроль доступа по своему усмотрению (модель дискреционного контроля доступа)

  • Избирательный контроль доступа
  • Для каждой пары субъект-объект задается перечень разрешений (например, чтение, запись, выполнение)
  • Часто объект имеет связанного субъекта-владельца. Владелец может устанавливать разрешения для других субъектов.

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

Существует два метода построения дискреционной системы контроля доступа:

  • Каждый объект в системе имеет привязанный к нему субъект, называемый владельцем. Именно владелец устанавливает права доступа к объекту.
  • В системе есть выделенный субъект – суперпользователь, который имеет право устанавливать права собственности для всех остальных субъектов в системе.

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

Модель для обязательного контроля доступа

  • Обязательный контроль доступа
  • Все субъекты и объекты ИС должны быть однозначно идентифицированы
  • Линейно упорядоченное множество меток секретности
  • Объекты несут метку секретности, определяющую значение содержащейся информации – уровень секретности
  • Каждому субъекту присваивается метка секретности, определяющая максимальное значение метки секретности объектов, к которым субъект имеет доступ; Метка секретности субъекта называется уровнем доступа.

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

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

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

Фундаментальные спецификации для механизма контроля доступа к мандату

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

Рис. 4.Чтение информации в мандатной модели

Рис. 5: Информационная запись в модели учетных данных

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

Преимущество.

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

По умолчанию.

  • Резервирование прав доступа для отдельных устройств на соответствующих уровнях.

Уполномоченное лицо (субъект) имеет право читать только те документы, уровень безопасности которых не превышает его собственный уровень безопасности. Это является основой управления доступом в модели полномочий.

Управление доступом на основе ролей (модель для управления доступом на основе ролей)

  • Управление доступом на основе ролей
  • Субъекту назначается роль или роли
  • Разрешения предоставляются определенным ролям
  • Включает DAC и MAC
  • Может быть усложнено введением наследования ролей
  • Распространено в корпоративных приложениях
  • Пример: пользователь может подтвердить заказ, если его роль – менеджер.

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

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

Изображение 6. Распределение ролей в ролевой модели в соответствии с бизнес-правилами

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

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

Образ 7. расширение многогранного законодательства о бизнесе

Вы должны добавить новые роли после добавления нового значения атрибута. Если в этом сценарии появляется ветвь “G”, необходимо добавить новые роли. Например: “Администратор” или просто менеджер (для всех необходимых сотрудников) и т.д. Это приводит к большому количеству повторяющейся ручной работы.

Кроме того, есть и дополнительные недостатки:

  • Бизнес-правила “рассыпаются” по многим ролям и становятся неочевидными, что затрудняет их понимание и поддержку;
  • Количество ролей начинает стремительно расти, что значительно усложняет управление ими.

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

На рисунке 8 показаны бизнес-правила с атрибутами, значения которых неизвестны.

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

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

Управление доступом на основе атрибутов (модель для управления доступом на основе атрибутов)

  • Управление доступом на основе атрибутов
  • Сущности и объекты оснащены атрибутами
  • Политики вычисляют условия, заданные с помощью выражений атрибутов для сущностей и объектов
  • Пример: пользователь может подтвердить заказ, если подразделение пользователя равно подразделению, в котором создан заказ, и если позиция сущности – менеджер

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

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

Можно явно выделить несколько категорий атрибутов:
Несколько категорий атрибутов

Рис. 10:Несколько категорий атрибутов

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

Простые правила описываются простыми условиями.
Пример простых бизнес правил

Рис. 11, простая иллюстрация бизнес-правил

Многомерные правила в этой модели не становятся более сложными
Пример многомерных бизнес правил

Рис. 12, многомерные бизнес правила

В АС помогает предотвратить проблемы, возникающие при проведении РБА:

  • Бизнес-правила не “разбросаны” по системе, что облегчает их понимание и поддержку;
  • Нет взрывного роста числа условий, что облегчает их поддержку.
  • ABAC решает проблемы, которые невозможно решить с помощью RBAC, поскольку в этом подходе нет предела сложности бизнес-правил. Бизнес-правила любой сложности, в том числе использующие ранее неизвестные атрибуты, не создают новых проблем и легко поддерживаются.

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

На Рисунке 13 показана иллюстрация бизнес-правил с использованием фильтра.

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


Таблица 1. Сравнение ABAC и RBAC
Сравнение ABAC и RBAC

Простые бизнес-правила могут быть хорошо реализованы с помощью R BAC. RBAC неэффективен, поскольку сложность правил делает его более дорогим.

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

Вредоносное программно обеспечение

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

Вредоносное программное обеспечение – это широкая категория вредоносных программ.

Любая программа, которая устанавливается на ваш компьютер без вашего ведома, считается вредоносной. К вредоносному ПО относятся такие программы, как троянские кони, черви и вирусы.

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

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

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

Признаки заражения компьютера:

  • Компьютер работает медленнее, чем обычно
  • Компьютер перестает отвечать или часто “зависает”
  • Компьютер зависает и перезагружается каждые несколько минут
  • Компьютер запускается сам по себе, а затем отказывается работать должным образом
  • Компьютерные приложения не работают должным образом
  • Диски или приводы недоступны
  • Печать не работает должным образом
  • Сообщения об ошибках необычны
  • Меню или диалоговые окна запутаны.

Истории угроз

Рекламные программы

Adware – это термин, используемый для описания программного обеспечения, которое выполняет сразу несколько задач для пользователя. Рекламное ПО может быть проблематичным, и его очень сложно отключить или скрыть. Во время работы программа мешает работе компьютера и ставит под угрозу безопасность данных.

Рекламное ПО/шпионское программно

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

Приложение из неизвестного источника

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

Программы задней двери

Программа удаленного администрирования проникает в систему через бэкдор для выполнения кражи данных или других задач на компьютере. Клиентская часть программы (Client) может управляться сторонними лицами через Интернет или локальную сеть.

Файлы с скрытыми расширениями

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

Фишинг

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

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

Рассылка незапрошенных электронных писем, которые выглядят как настоящие сообщения от известных веб-сайтов или компаний, является распространенным методом фишинга.

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

Имя пользователя и личный номер.

# Адрес и номер телефона.

# Паспортные данные или PIN-код.

Номер банковского счета.

Номер дебетовой или кредитной карты.

# Код проверки карточки (CVC) или контрольное число карточки (CVV).

Номер социального страхования.

Изменить программы

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

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

Обманчивая программа

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

Bot-сети

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

Эксплойт

Компьютерная программа или скрипт, известный как “эксплойт”, использует определенные слабые места в операционной системе или программе.

Скрытый майнер (stealth miner, майнер-бот, ботнет)

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

Фарминг

Фарминг – это практика изменения файла хоста веб-браузера для направления трафика на поддельный веб-сайт. Это разновидность традиционного фишинга. Мошенники, занимающиеся фармингом, держат большие серверы в качестве поддельных веб-сайтов. Общий термин для различных видов DNS-атак – фермерство. Система манипулируется, когда троян или вирус изменяет файл хоста. Даже если вы правильно введете адрес, система сможет загрузить только поддельные веб-сайты.

Пишем свой credential provider на c# для авторизации в windows

Стек безопасности Windows может получать учетные данные пользователя с помощью инструмента Credential Provider. По умолчанию в системе есть провайдеры для Windows Hello, смарт-карт и входа по паролю. Что если они не будут работать на нас?

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

Перед началом разработки необходимо настроить взаимодействие COM так, чтобы можно было вызывать код из компонентов. Вы можете использовать стандартную версию NET с помощью файла MSDN из Windows SDK, чтобы правильно настроить интерфейсы для взаимодействия с компьютером. Его нужно только преобразовать в библиотеку типов и конструкцию a. NET

Прежде чем использовать инструмент midl.exe для компиляции библиотеки типов, необходимо исправить файл credentialprovider idl. Для этого необходимо переместить объявление CLSID в начало файла.

// C:Program Files (x86)Windows Kits10Include10.0.19041.0umcredentialprovider.idl
[
    uuid(d545db01-e522-4a63-af83-d8ddf954004f), // LIBID_CredentialProviders
]
library CredentialProviders
{
	// код credentialprovider.idl
}

После выполнения команды:

midl .credentialprovider.idl -target NT100 /x64

После выполнения мы получим несколько файлов, но нас интересует только тип. Утилита tlbimp.exe, которая обычно используется для преобразования с помощью библиотеки NET, по умолчанию ожидает, что вы будете генерировать исключения, а не возвращать HRESULT. Альтернативой этой утилите является файл tlbimp2.exe, найденный в репозитории Steeves. После выполнения команды мы получаем OTP. Для подключения библиотеки ProviderInteropdl к проекту требуется ссылка на полученный файл в исходном коде проекта.

./TlbImp2.exe .credentialprovider.tlb /out:OTP.Provider.Interop.dll /unsafe /preservesig namespace:OTP.Provider

Затем он получит доступ к следующим интерфейсам, работу которых необходимо объяснить:

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

 [ComVisible(true)]															
 [Guid("D26F523C-A346-4FC8-B9B4-2B57EAEDA723")]
 [ClassInterface(ClassInterfaceType.None)]
 [ProgId("OTP.Provider")]
 public class CredentialProvider : ICredentialProvider
 {
 		// код CredentialProvider
 }

Чтобы правильно создать манифест, необходимо также включить параметр EnableComHosting во время сборки проекта. Когда этот параметр включен, в дополнение к основной библиотеке создается библиотека с префиксом comhost. Настраиваем ее для работы в системе. CopyLocalFileAsseblies, первый параметр, который требуется для правильной сборки, легко доступен библиотеке. Программа. Рисунок плитки отображается с помощью редактора DrawingCommon, но я вижу только пустой квадрат или прямоугольник с картинкой.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net6.0-windows</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>annotations</Nullable>
    <EnableComHosting>true</EnableComHosting>
    <PlatformTarget>x64</PlatformTarget>
    <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
    <AllowUnsafeBlocks>True</AllowUnsafeBlocks>
  </PropertyGroup>

// ...

</Project>

Метод Initialize является одним из немногих доступных методов для изменения конфигурации. Для добавления поля необходимо использовать метод AddFields; все, что от нас требуется, это указать несколько параметров. По умолчанию Windows предоставляет нам шесть различных типов полей, включая текстовые поля и поля для ввода пароля, ярлыки для поставщиков услуг, текстовые или графические элементы для ввода логина/пароля, а также изображения значков на экране клавиатуры, которые отображают “настроение” пользователя (от 0 до 10 МБ включительно).

protected override CredentialView Initialize(_CREDENTIAL_PROVIDER_USAGE_SCENARIO cpus, uint dwFlags)
{
	var flags = (CredentialFlag)dwFlags;

	Logger.Write($"cpus: {cpus}; dwFlags: {flags}");

	var isSupported = IsSupportedScenario(cpus);
            
	if (!isSupported)
	{
		if (NotActive == null) NotActive = new CredentialView(this) { Active = false };
			return NotActive;
	}

	var view = new CredentialView(this) { Active = true };
	var userNameState = (cpus == _CREDENTIAL_PROVIDER_USAGE_SCENARIO.CPUS_CREDUI) ?
		_CREDENTIAL_PROVIDER_FIELD_STATE.CPFS_DISPLAY_IN_SELECTED_TILE : _CREDENTIAL_PROVIDER_FIELD_STATE.CPFS_HIDDEN;
	var confirmPasswordState = (cpus == _CREDENTIAL_PROVIDER_USAGE_SCENARIO.CPUS_CHANGE_PASSWORD) ?
		_CREDENTIAL_PROVIDER_FIELD_STATE.CPFS_DISPLAY_IN_BOTH : _CREDENTIAL_PROVIDER_FIELD_STATE.CPFS_HIDDEN;

						view.AddField(
                cpft: _CREDENTIAL_PROVIDER_FIELD_TYPE.CPFT_TILE_IMAGE,
                pszLabel: "Icon",
                state: _CREDENTIAL_PROVIDER_FIELD_STATE.CPFS_DISPLAY_IN_BOTH,
                guidFieldType: Guid.Parse(CredentialView.CPFG_CREDENTIAL_PROVIDER_LOGO)
            );

            view.AddField(
                cpft: _CREDENTIAL_PROVIDER_FIELD_TYPE.CPFT_EDIT_TEXT,
                pszLabel: "Username",
                state: userNameState
            );

            view.AddField(
                cpft: _CREDENTIAL_PROVIDER_FIELD_TYPE.CPFT_PASSWORD_TEXT,
                pszLabel: "Password",
                state: _CREDENTIAL_PROVIDER_FIELD_STATE.CPFS_DISPLAY_IN_SELECTED_TILE,
                guidFieldType: Guid.Parse(CredentialView.CPFG_LOGON_PASSWORD_GUID)
            );

            view.AddField(
                cpft: _CREDENTIAL_PROVIDER_FIELD_TYPE.CPFT_PASSWORD_TEXT,
                pszLabel: "Confirm password",
                state: confirmPasswordState,
                guidFieldType: Guid.Parse(CredentialView.CPFG_LOGON_PASSWORD_GUID)
            );

            view.AddField(
                cpft: _CREDENTIAL_PROVIDER_FIELD_TYPE.CPFT_LARGE_TEXT,
                pszLabel: "Custom Provider",
                defaultValue: "Custom Provider",
                state: _CREDENTIAL_PROVIDER_FIELD_STATE.CPFS_DISPLAY_IN_DESELECTED_TILE
            );

		return view;
	}

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

private static bool IsSupportedScenario(_CREDENTIAL_PROVIDER_USAGE_SCENARIO cpus)
{
	switch (cpus)
  {
  	case _CREDENTIAL_PROVIDER_USAGE_SCENARIO.CPUS_CREDUI:
    case _CREDENTIAL_PROVIDER_USAGE_SCENARIO.CPUS_UNLOCK_WORKSTATION:
    case _CREDENTIAL_PROVIDER_USAGE_SCENARIO.CPUS_LOGON:
    case _CREDENTIAL_PROVIDER_USAGE_SCENARIO.CPUS_CHANGE_PASSWORD:
    	return true;
                
    case _CREDENTIAL_PROVIDER_USAGE_SCENARIO.CPUS_PLAP:
    case _CREDENTIAL_PROVIDER_USAGE_SCENARIO.CPUS_INVALID:
    default:
    	return false;
	}
}

И последний подход, который немедленно реагирует на учетные данные, отправленные для аутентификации. Этот метод возвращает указатель на учетные данные пользователя, а также сигнал, указывающий, была ли попытка сериализации учетных данных успешной или неуспешной. В примере Стива мы можем создать стандартную аутентификацию с использованием учетных данных локального или доменного пользователя с помощью метода из библиотеки CredPackAuthenticationBuffer. Этот подход эффективен в Windows 10, поскольку сценарии авторизации и разблокировки были объединены в один сценарий CPUS_LOGON. Я столкнулся с этой проблемой во время тестирования провайдера, который написал Стив. Возникла проблема, когда я попытался разблокировать рабочую станцию, но когда я нажал кнопку Switch User, авторизация прошла успешно! Компания Microsoft рекомендовала пользователям входить в систему с помощью определенного метода. Для авторизации разработчики Windows полагаются на пластырь.

HRESULT KerbInteractiveUnlockLogonInit(
    _In_ PWSTR pwzDomain,
    _In_ PWSTR pwzUsername,
    _In_ PWSTR pwzPassword,
    _In_ CREDENTIAL_PROVIDER_USAGE_SCENARIO cpus,
    _Out_ KERB_INTERACTIVE_UNLOCK_LOGON *pkiul
    )
{
    // Note: this method uses custom logic to pack a KERB_INTERACTIVE_UNLOCK_LOGON with a
    // serialized credential.  We could replace the calls to UnicodeStringInitWithString
    // and KerbInteractiveUnlockLogonPack with a single cal to CredPackAuthenticationBuffer,
    // but that API has a drawback: it returns a KERB_INTERACTIVE_UNLOCK_LOGON whose
    // MessageType is always KerbInteractiveLogon.
    //
    // If we only handled CPUS_LOGON, this drawback would not be a problem.  For
    // CPUS_UNLOCK_WORKSTATION, we could cast the output buffer of CredPackAuthenticationBuffer
    // to KERB_INTERACTIVE_UNLOCK_LOGON and modify the MessageType to KerbWorkstationUnlockLogon,
    // but such a cast would be unsupported -- the output format of CredPackAuthenticationBuffer
    // is not officially documented.
}

Нам нужно создать небольшую библиотеку на языке C и скопировать в нее функции KerbInteractiveUnlockLogonPack и KERB IntrastineRockinit, поскольку стандартных библиотек для упаковки учетных данных не существует. После этого проблема с неподдерживаемым скриптом будет решена, и мы сможем использовать PInvoke для вызова нужной функции. Основное отличие, которое интересно, заключается в том, как скрипт авторизации устанавливается в качестве типа сообщения сериализации для библиотеки ntsecapi. Он имеет различные техники для стирания данных при перемещении между библиотеками и использует различные техники для сбора учетных данных:

switch (cpus)
{
	case CPUS_UNLOCK_WORKSTATION:
  	pkil->MessageType = KerbWorkstationUnlockLogon;
    hr = S_OK;
    break;

  case CPUS_LOGON:
  	pkil->MessageType = KerbInteractiveLogon;
    hr = S_OK;
    break;

  case CPUS_CREDUI:
  	pkil->MessageType = (KERB_LOGON_SUBMIT_TYPE)0; // MessageType does not apply to CredUI
    hr = S_OK;
    break;

  default:
  	hr = E_FAIL;
    break;
}

Достаточно включить его в основную библиотеку Middle Knowledge после составления нашей скромной библиотеки Credential Provider.

[DllImport("./OTP.Provider.Helper.dll", CharSet = CharSet.Unicode, SetLastError = true)]
public static extern uint ProtectIfNecessaryAndCopyPassword(
	string pwzPassword,
  _CREDENTIAL_PROVIDER_USAGE_SCENARIO cpus,
  ref string ppwzProtectedPassword
);

[DllImport("./OTP.Provider.Helper.dll", CharSet = CharSet.Unicode, SetLastError = true)]
	public static extern uint KerbInteractiveUnlockLogonInit(
  	string pwzDomain,
    string pwzUsername,
    string pwzPassword,
    _CREDENTIAL_PROVIDER_USAGE_SCENARIO cpus,
    ref IntPtr prgb,
    ref int pcb
);

Это можно использовать в методе GetSerialization.

try
{
  PInvoke.ProtectIfNecessaryAndCopyPassword(password, usage, ref protectedPassword); 
}
catch (Exception ex)
{
	Logger.Write(ex.Message);
}

var inCredSize = 0;
var inCredBuffer = Marshal.AllocCoTaskMem(0);
try
{
	Marshal.FreeCoTaskMem(inCredBuffer);
  inCredBuffer = Marshal.AllocCoTaskMem(inCredSize);
  PInvoke.KerbInteractiveUnlockLogonInit(domain, shortUsername, protectedPassword, usage, ref inCredBuffer, ref inCredSize);

	pcpcs.clsidCredentialProvider = Guid.Parse("D26F523C-A346-4FC8-B9B4-2B57EAEDA723");
  pcpcs.rgbSerialization = inCredBuffer;
  pcpcs.cbSerialization = (uint)inCredSize;
  pcpcs.ulAuthenticationPackage = authPackage;
  pcpgsr = _CREDENTIAL_PROVIDER_GET_SERIALIZATION_RESPONSE.CPGSR_RETURN_CREDENTIAL_FINISHED;

	return HRESULT.S_OK;

}
catch (Exception ex)
{
  Logger.Write(ex.Message);
}

После создания библиотеки необходимо добавить ключ в реестр для ее использования. Мы создаем вертикальную структуру в ветке [HKE_LOCAL_MACHINES], используя GUID библиотеки, который мы указали на странице CredentialProvider. В любом случае, необходимо ввести CLSID нашего провайдера в строку HKE_CLASSES, когда при авторизации появится плитка с запросом вашего провайдера.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionAuthenticationCredential Providers{D26F523C-A346-4FC8-B9B4-2B57EAEDA723}] 
@="OTP.Provider"
[HKEY_CLASSES_ROOTOTP.ProviderCLSID]
@="{D26F523C-A346-4FC8-B9B4-2B57EAEDA723}"
Отображение плитки кастомного провайдера
Отображение плитки кастомного провайдера

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

➤