Варианты двухкратной аутентификации для windows server 2008 r2

Настройка двухфакторной аутентификации на сервере Windows со службой RD Gateway

В статье описывается настройка Windows сервера для включения двухфакторной аутентификации при подключении удаленного рабочего стола (RDP) со службой RD Gateway.

RD Gateway — компонент Windows сервера, позволяющий подключаться к рабочему столу через шлюз, который выполняет функции VPN, а именно создает зашифрованное подключение по протоколу TLS.

Применимо к версиям:

• Windows Server 2012 R2
• Windows Server 2016
• Windows Server 2019

Возможные способы аутентификации:

• Telegram
• Звонок (нужно принять вызов и нажать #)
• Мобильное приложение (скоро)

1. Пользователь подключается к удаленному рабочему столу через шлюз RD Gateway;
2. RD Gateway проверяет логин, пароль, политику авторизации ресурсов (RAP) и переадресовывает запрос в Network Policy Server (NPS);
3. NPS получает запрос от RD Gateway, запрашивает второй фактор аутентфикации по RADIUS протоколу в компоненте MultiFactor Radius Adapter;
4. Мультифактор отправляет на телефон пользователя запрос подтверждения входа;
5. Пользователь подтверждает запрос в телефоне и подключается к VPN.

Требования к серверу

1. На сервере должны быть установлены и настроены компоненты Remote Desktop Gateway и Network Policy and Access Service.
2. На сервере с NPS необходимо установить компонент MultiFactor Radius Adapter.
3. Для работы Мультифактора серверу необходим доступ к хосту api.multifactor.ru по порту 443 (TLS).

Настройка MultiFactor Radius Adapter

Разверните компонент MultiFactor Radius Adapter, настройте файл конфигурации следующим образом:

Придумайте сложное значение SHARED_SECRET и запишите в конфигурационный файл.

1. В разделе Remote RADIUS Server Groups создайте новую группу:
   • Group name: MFA
   • Нажмите Add:
     • Server: 127.0.0.1
     • Shared secret: ранее придуманный SHARED_SECRET
     • Load Balancing: поставьте таймауты по 60 секунд

1. В разделе Connection Requests Policies, откройте свойства политики TS GATEWAY AUTHORIZATION POLICY:
   • На вкладке Settings:
     • в разделе Authentication выберите вариант Forward requests to the following remote RADIUS server group for authentication: MFA

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Аутентификация в системах Windows. Часть 2 — Kerberos

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

Протокол Kerberos был разработан в Массачусетском технологическом институте (MIT) в рамках проекта «Афина» в 1983 году и долгое время использовался в качестве образовательного, пока версия 4 не была сделана общедоступной. В настоящий момент принята в качестве стандарта и широко используется следующая версия протокола Kerberos 5.

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

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

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

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

Основой инфраструктуры Kerberos является Центр распространения ключей (Key Distribution Center, KDC), который является доверенным центром аутентификации для всех участников сети (принципалов). Область Kerberos (Realm) — пространство имен для которых данный KDC является доверенным, как правило это область ограниченная пространством имен домена DNS, в Active Directory область Kerberos совпадает с доменом AD. Область Kerberos записывается в виде соответствующего ему доменного имени DNS, но в верхнем регистре. Принципалом или учетной записью Kerberos является любой участник отношений безопасности: учетная запись пользователя, компьютер, сетевая служба и т.д.

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

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

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

Рассмотрим каким образом происходит аутентификация клиента по протоколу Kerberos.

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

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

Убедившись, что метка времени действительна KDC выдает клиенту сеансовый ключ и билет (тикет) на получение билета (ticket granting ticket, TGT), который содержит копию сеансового ключа и сведения о клиенте, TGT шифруется с помощью долговременного ключа KDC и никто кроме него билет расшифровать не может. Сеансовый ключ шифруется с помощью долговременного ключа клиента, а полученная от клиента метка времени возвращается обратно, зашифрованная уже сеансовым ключом. Билет на получение билета является действительным в течении 8 часов или до завершения сеанса пользователя.

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

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

Успешно пройдя аутентификацию, клиент будет располагать сеансовым ключом, которым впоследствии он будет шифровать все сообщения для KDC и билетом на получение билета (TGT).

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

Для этого он снова обращается к KDC и посылает ему билет на получение билета, зашифрованную сеансовым ключом метку времени и имя сервера. Прежде всего KDC расшифровывает предоставленный ему TGT и извлекает оттуда данные о клиенте и его сеансовый ключ, обратите внимание, что сам KDC сеансовые ключи не хранит. Затем сеансовым ключом он расшифровывает данные от клиента и сравнивает метку времени с текущим. Если расхождения нет, то KDC формирует общий сеансовый ключ для клиента и сервера.

Теоретически теперь данный ключ следует передать как клиенту, так и серверу. Но KDC имеет защищенный канал и установленные доверительные отношения только с клиентом, поэтому он поступает по-другому. Экземпляр сеансового ключа для клиента он шифрует сессионным ключом, а копию сеансового ключа для сервера он объединяет с информацией о клиенте в сеансовый билет (session ticket), который шифрует закрытым ключом сервера, после чего также отправляет клиенту, дополнительно зашифровав сессионным ключом.

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

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

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

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

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

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

Источник

Шифрование в Windows Server 2008 R2

Сегодня уже никто не сомневается в необходимости шифрования. Однако обращать внимание следует не только на шифрование данных ноутбуков, но и на шифрование серверов и, самое главное, — на шифрование внешних устройств (жестких дисков, флэш-накопитель USB-дисков и т. д.).

С появлением Windows Server 2008, а теперь и Windows Server 2008 R2 возможность шифрования стала уже встроенной функцией операционной системы. В данной статье я попытаюсь описать процесс шифрования с помощью функции BitLocker в новой версии Windows Server 2008 R2.

Начинаем шифровать

Прежде чем приступать к шифрованию, необходимо открыть «Задачи начальной настройки» и добавить компонент «Шифрование BitLocker» (экран 1).

После этого придется перезагрузить сервер, и можно начинать шифрование.

Важно учесть, что в Windows Server 2008 R2, в отличие от Windows 7 и более старых версий, по умолчанию считается, что система оборудована модулем Trusted Platform Module (ТРМ). Если ваш сервер не оборудован соответствующим модулем, то вам до начала шифрования необходимо обратиться к редактору локальных групповых политик, запустив файл gpedit.msc. В редакторе локальных групповых политик в разделе «Конфигурация компьютера» раскройте контейнер «Административные шаблоны», затем «Компоненты Windows» и выберите объект «Шифрование диска BitLocker» (экран 2).

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

Включите данный параметр и обязательно оставьте флажок для параметра «Разрешить использовать BitLocker без совместимого ТРМ». Не забудьте, что при этом потребуется флэш-накопитель USB для хранения ключа. Примените данную политику, и вы сможете шифровать свои жесткие диски. Для этого необходимо перейти в панель управления, запустить модуль «Шифрование диска BitLocker» и указать тот диск, который предстоит шифровать.

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

Обратите внимание! В перечне дисков, доступных для шифрования, перечислены не только жесткие диски, но и внешний жесткий диск и даже флэш-накопитель USB. Впрочем, те из читателей, кто уже тестировал шифрование в Windows 7, скорее всего, знают о данной возможности.

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

Так как в данной статье рассматривается шифрование без модуля ТРМ, параметры, относящиеся к ТРМ, соответственно недоступны (выделены серым цветом на экране 3).

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

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

Вы можете использовать:

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

Последний пункт имеет смысл использовать только в том случае, если вы предварительно зашифровали системный диск.

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

Локальная групповая политика шифрования BitLocker

Рассмотрим некоторые параметры локальной групповой политики, относящиеся к шифрованию BitLocker в версии Windows Server 2008 R2.

Обязательная проверка подлинности при запуске. Данный параметр позволяет указать, будет ли BitLocker требовать дополнительной проверки подлинности при каждом запуске ПК, а также используете ли вы ТРМ. Если сервер не оснащен ТРМ, следует установить флажок «Разрешить использование BitLocker, без совместимого ТРМ». В этом случае при запуске ключ шифрования будет считываться с USB-устройства. Если устройство недоступно (не работает), необходимо воспользоваться одним из способов восстановления BitLocker.

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

Установить минимальную длину PIN-кода для запуска. Данный параметр устанавливает минимальную длину PIN-кода. Длина PIN-кода составляет от 4 до 20 разрядов.

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

Настройка профиля проверки ТРМ. Этот параметр политики позволяет указать, как оборудование безопасности для модуля TPM обеспечивает безопасность ключа шифрования BitLocker. Данный параметр неприменим, если на компьютере нет совместимого модуля либо же если BitLocker уже включен и используется защита с помощью этого модуля.

Параметры шифрования дисков с данными

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

Запретить запись на фиксированные диски, не защищенные BitLocker. С помощью данного параметра можно разрешить запись на жесткие диски, не зашифрованные с помощью BitLocker. При включении этого параметра все фиксированные диски, не защищенные BitLocker, подключаются как доступные только для чтения. Если диск защищен с помощью BitLocker, он подключается с доступом для чтения и записи.

Разрешить доступ к фиксированным дискам с данными, защищенными с помощью BitLocker, из более ранних версий Windows. Этот параметр политики определяет, можно ли разблокировать и просматривать фиксированные диски с данными, форматированные с файловой системой FAT, на компьютерах под управлением операционных систем Windows Server 2008, Windows Vista, Windows XP с пакетом обновлений 3 (SP3) и Windows XP с пакетом обновлений 2 (SP2). У этих операционных систем есть доступ только для чтения к дискам, защищенным с помощью BitLocker. Обратите внимание, что этот параметр политики не применяется к дискам, отформатированным с файловой системой NTFS.

Настроить использование паролей для фиксированных дисков с данными. С помощью данного параметра можно определить, требуется ли пароль для разблокирования фиксированных дисков данных, шифрованных с помощью BitLocker. Если разрешить использование пароля, можно сделать его обязательным, установить требования к сложности и задать минимальную длину. Для активации параметра требований к сложности следует включить параметр групповой политики «Пароли должны соответствовать требованиям к сложности», размещенный в разделе Конфигурация компьютера\Параметры Windows\Параметры безопасности\Политики учетной записи\Политика паролей\.

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

Параметры управления шифрованием съемных дисков с данными

Управление использованием BitLocker для съемных дисков. При включении этого параметра можно устанавливать значения свойств, управляющие тем, как пользователи могут настраивать BitLocker. Установите флажок «Разрешить пользователям применять защиту с помощью BitLocker на съемных дисках с данными», чтобы разрешить пользователю запускать мастер установки BitLocker на съемном диске с данными. Установите флажок «Разрешить пользователям отключать и использовать BitLocker для шифрования съемных дисков с данными», чтобы разрешить пользователям удалять шифрование диска BitLocker или временно отключать шифрование на период обслуживания.

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

Запретить запись на съемные диски, не защищенные BitLocker. При включении этого параметра все съемные диски, не защищенные BitLocker, подключаются как доступные только для чтения. Если диск защищен с помощью BitLocker, он подключается с доступом для чтения и записи.

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

Разрешить доступ к съемным дискам с данными, защищенным с помощью BitLocker из более ранних версий Windows. Этот параметр политики определяет, можно ли разблокировать и просматривать съемные диски с данными, форматированные с файловой системой FAT, на компьютерах под управлением Windows Server 2008, Windows Vista, Windows XP с пакетом обновлений 3 (SP3) и Windows XP с пакетом обновлений 2 (SP2).

Настроить использование паролей для съемных дисков с данными. Данный параметр определяет, требуется ли пароль для разблокирования съемных дисков, зашифрованных BitLocker.

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

Владимир Безмалый (vladb@windowslive.com) — специалист по обеспечению безопасности, MVP Consumer Security, Microsoft Security Trusted Advisоr

Поделитесь материалом с коллегами и друзьями

Источник