Пароли могут создать большую головную боль в плане безопасности и управляемости для ИТ-администраторов предприятий и организаций. Пользователи часто создают простые пароли или записывают пароли, чтобы не забыть их. Вдобавок лишь немногие из процедур сброса паролей эффективны и безопасны. Учитывая эти ограничения, как можно смягчить проблемы безопасности подобного типа, когда доступ к сети производится удаленными пользователями? Как можно сделать решение паролей своей компании более надежным, зная, что многие пользователи записывают свои пароли?
Решение есть – это внедрение в организации дополнительной систему защиты доступа на основе ввода одноразовых паролей (OTP – One Time Password) , которые генерируются на мобильном устройстве вашего сотрудника. Переход к аутентификации на основе одноразовых паролей обычно происходит в ситуации, когда приходит понимание, что стандартные долговременные пароли недостаточны с точки зрения безопасности и при этом возможности использования смарт-карт ограничены, например, в ситуации массового применения мобильных клиентов.
Нашей компанией разработано технологическое решение , которое позволит получить дополнительный рубеж защиты для терминального сервера или сервера 1С на основе одноразовых паролей , к которому удаленно подсоединяются сотрудники.
Состав работ по развертыванию и настройке OTP-системы
На вашем сервере устанавливается и настраивается специализированное программное обеспечение для работы системы аутентификации доступа на основе одноразовых паролей (OTP) В OTP-систему заводятся все сотрудники организации, которым необходим доступ к серверу Для каждого сотрудника производится первичная настройка мобильного телефона с установкой программы для генерации одноразового пароля
Стоимость внедрение в организацию системы аутентификации доступа на терминальный сервер или сервер 1С на основе одноразовых паролей (OTP) начинается от 6 400 руб .
В случаях, если OTP-система будет развернута в комплексе с арендой инфраструктуры в нашем защищенном «облаке», скидка на внедрение системы защиты с помощью одноразовых паролей (OTP) может достигать 50 % .
Одноразовые пароли - дополнительный уровень безопасности данных
Традиционный, статичный пароль, обычно меняется лишь при необходимости: либо когда он истекает, либо когда пользователь забыл его и хочет его сбросить. Поскольку пароли кэшируются на жестких дисках компьютера и хранятся на сервере, они уязвимы для взлома. Эта проблема стоит особо остро для переносных компьютеров, поскольку их легко украсть. Многие компании дают сотрудникам переносные компьютеры и открывают свои сети для удаленного доступа. Они также нанимают временных сотрудников и поставщиков. В такой среде простое статичное решение пароля становится недостатком.
В отличие от статичного пароля, одноразовый пароль меняется при каждом входе пользователя в систему и действителен только в течении короткого промежутка времени (30 сек).
Сами пароли создаются и шифруются по сложному алгоритму зависящих от многих переменных: времени, количеству успешных\неудачных входов, случайно сгенерированных чисел и т.д. Данный на первый взгляд сложный подход требуют от пользователя простых действий – Установить на свой телефон специальное приложение, которое синхронизируется один раз с сервером и в дальнейшем генерирует одноразовый пароль. При каждом новом успешном входе происходит автоматическая пере синхронизация клиента и сервера независимо друг от друга по специальному алгоритму. Значение счетчика растет каждый раз, как от устройства требуется значение OTP и когда пользователь желает войти в систему, он вводит OTP, отображенные на своем мобильном устройстве в настоящий момент.
1) В самом начале настройки сервера, вводите команду:
multiotp.exe -debug -config default-request-prefix-pin=0 display-log=1 после неё не требуется вводить пин-код при настройке пользователя и включается отображение лога каждой операции в консоль.
2) С помощью этой команды можно регулировать bantime, для пользователей, которые ошиблись с паролем (по умолчанию 30 сек):
multiotp.exe -debug -config failure-delayed-time=60
3) То, что будет написано в приложении google Authenticator над 6 цифрами, называется issuer, можно поменять с дефолтного MultiOTP на что-то другое:
multiotp.exe -debug -config issuer=other
4) После проделанных операций, команда по созданию пользователя становится чуть проще:
multiotp.exe -debug -create user TOTP 12312312312312312321 6
(время обновления цифр, равное 30 секундам, я не задаю, кажется оно по умолчанию равно 30).
5) Каждому пользователю можно изменить description (текст под цифрами в приложении Google Auth):
multiotp.exe -set username description=2
6) QR-коды можно создавать сразу в приложении:
multiotp.exe -qrcode username c:\multiotp\qrcode\user.png:\multiotp\qrcode\user.png
7) Можно использовать не только TOTP, но и HOTP (на вход функции хэширования подаётся не текущее время, а значение инкрементального счетчика):
multiotp.exe -debug -create username HOTP 12312312312312312321 6
- Tutorial
Кто-то из вас наверняка слышал про инцидент , который был обнародован совсем недавно. Американский производитель полупроводников Allegro MicroSystem LLC подал в суд на своего бывшего IT-специалиста за саботаж. Нимеш Пател, проработавший в компании 14 лет, уничтожил важные финансовые данные в первую неделю нового фискального года.
Как это произошло?
Через две недели после своего увольнения Пател зашел на территорию штаб-квартиры компании в Вустере (штат Массачусетс, США) с целью поймать корпоративную сеть Wi-Fi. Используя учетные данные бывшего коллеги и рабочий ноутбук, Пател авторизовался в корпоративной сети. Затем он внедрил в модуль Oracle код и запрограммировал его выполнение на 1 апреля 2016 года - первую неделю нового финансового года. Код предназначался для копирования определенных заголовков или указателей в отдельную таблицу базы данных и следующего удаления их из модуля. Ровно 1 апреля данные были удалены из системы. И поскольку злоумышленник авторизовался в сети Allegro легально, его действия были замечены не сразу.
Подробности широкая общественность не знает, но скорее всего инцидент стал возможен во многом благодаря тому, что в компании для доступа в сеть использовалась парольная аутентификация. Наверняка там были и другие проблемы с безопасностью, но именно пароль можно похитить незаметно для пользователя и факт кражи пароля не будет обнаружен, в лучшем случае вплоть до момента использования похищенных учетных данных.
Применение строгой двухфакторной аутентификации и запрет на использование паролей в сочетании с грамотной политикой безопасности могли бы помочь, если не избежать описанного развития событий, то сильно затруднить реализацию такого плана.
Мы расскажем о том, как можно значительно повысить уровень безопасности вашей компании и защитить себя от подобных инцидентов. Вы узнаете, как настроить аутентификацию и подпись важных данных, используя токены и криптографию (как иностранную, так и отечественную).
В первой статье мы объясним как настроить строгую двухфакторную аутентификацию с использованием PKI при входе в доменную учетную запись в Windows.
В следующих статьях мы расскажем вам, как настроить Bitlocker, защитить электронную почту и простейший документооборот. Также мы вместе с вами настроим безопасный доступ к корпоративным ресурсам и безопасный удаленный доступ по VPN.
Двухфакторная аутентификация
Опытным системным администраторам и службам безопасности хорошо известно, что пользователи крайне не сознательны в вопросе соблюдения политик безопасности, они могут записать свои учетные данные на стикере и приклеить его рядом с компьютером, передать пароли своим коллегам и тому подобное. Особенно часто это происходит, когда пароль сложный (содержащий более 6 знаков и состоящий из букв разного регистра, цифр и специальных символов) и его трудно запомнить. А ведь такие политики администраторами задаются не просто так. Это необходимо для защиты учетной записи пользователя от простого перебора паролей по словарю. Также администраторы рекомендуют менять пароли хотя бы раз в 6 месяцев, просто из того соображения, что за это время теоретически можно отбрутфорсить даже сложный пароль.
Давайте вспомним, что такое аутентификация. В нашем случае это процесс подтверждения подлинности субъекта или объекта. Аутентификация пользователя - это процесс подтверждения подлинности пользователя.
А двухфакторная аутентификация - это такая аутентификация, в которой необходимо использовать не менее двух различных способов для подтверждения своей личности.
Простейшим примером двухфакторной аутентификации в реальной жизни является сейф с замком и кодовой комбинацией. Чтобы открыть такой сейф необходимо знать код и владеть ключом.
Токен и смарт-карта
Наверно, самым надежным и простым в реализации способом двухфакторной аутентификации является использование криптографического токена или смарт-карты. Токен - это USB-устройство, которое является и считывателем, и смарт-картой одновременно. Первым фактором в таком случае является факт владения устройством, а вторым - знание его PIN-кода.
Использовать токен или смарт-карту, тут кому, что удобнее. Но исторически так сложилось, что в России больше привыкли использовать токены, так как они не требуют использования встроенных или внешних считывателей смарт-карт. У токенов есть и свои минусы. Например, на нем не напечатаешь фотографию.
На фотографии изображена типичная смарт-карта и считыватель.
Однако вернемся к корпоративной безопасности.
А начнем мы с домена Windows, ведь в большинстве компаний в России корпоративная сеть построена именно вокруг него.
Как известно, политики Windows-домена, настройки пользователей, настройки групп в Active Directory предоставляют и разграничивают доступ к огромному количеству приложений и сетевых сервисов.
Защитив учетную запись в домене, мы можем защитить большинство, а в некоторых случаях и вообще все внутренние информационные ресурсы.
Почему двухфакторная аутентификация в домене по токену с PIN-кодом безопаснее обычной парольной схемы?
PIN-код привязан к определенному устройству, в нашем случае к токену. Знание PIN-кода само по себе ничего не дает.
Например, PIN-код от токена можно диктовать по телефону другим лицам и это ничего не даст злоумышленнику, если вы достаточно бережно относитесь к токену и не оставляете его без присмотра.
С паролем же ситуация совершенно иная, если злоумышленник подобрал, угадал, подсмотрел или еще каким-то образом завладел паролем от учетной записи в домене, то он сможет беспрепятственно зайти, как в сам домен, так и в другие сервисы компании, в которых используется эта же учетная запись.
Токен является уникальным некопируемым физическим объектом. Им обладает легитимный пользователь. Двухфакторную аутентификацию по токену можно обойти только тогда, когда администратор намеренно или по недосмотру оставил для этого «лазейки» в системе.
Преимущества входа в домен по токену
PIN-код от токена проще запомнить, так как он может быть намного проще пароля. Каждый наверняка хоть раз в жизни видел, как «опытный» пользователь мучительно не может с нескольких попыток аутентифицироваться в системе, вспоминая и вводя свой «безопасный» пароль.
PIN-код не обязательно постоянно менять, так как токены более устойчивы к перебору PIN-кодов. После некоторого числа неудачных попыток ввода, токен блокируется.
При использовании токена для пользователя вход в систему выглядит следующим образом: после загрузки компьютера, он просто подключает токен к USB-порту компьютера, вводит 4-6 цифр и нажимает кнопку Enter. Скорость ввода цифр у обычных людей выше, чем скорость ввода букв. Поэтому PIN-код вводится быстрее.
Токены позволяют решить проблему «брошенного рабочего места» - когда пользователь уходит со своего рабочего места и забывает выйти из своей учетной записи.
Политика домена может быть настроена таким образом, чтобы компьютер автоматически блокировался при извлечении токена. Также токен может быть оснащен RFID-меткой для прохода между помещениями компании, поэтому не забрав токен со своего рабочего места, сотрудник просто не сможет перемещаться по территории.
Недостатки, куда же без них
Токены или смарт-карты не бесплатные (решается бюджетом).
Их нужно учитывать, администрировать и обслуживать (решается системами управления токенами и смарт-картами).
Некоторые информационные системы могут «из коробки» не поддерживать аутентификацию по токенам (решается системами типа Single Sign-On - предназначенными для организации возможности использования единой учетной записи для доступа к любым ресурсам области).
Настройка двухфакторной аутентификации в домене Windows
Теоретическая часть:
Служба каталога Active Directory поддерживает возможность аутентификации с помощью смарт-карты и токена, начиная с Windows 2000. Она заложена в расширении PKINIT (public key initialization - инициализация открытого ключа) для протокола Kerberos RFC 4556 .
Протокол Kerberos был специально разработан для того, чтобы обеспечить надежную аутентификацию пользователей. Он может использовать централизованное хранение аутентификационных данных и является основой для построения механизмов Single Sing-On. Протокол основан на ключевой сущности Ticket (билет).
Ticket (билет) является зашифрованным пакетом данных, который выдается доверенным центром аутентификации, в терминах протокола Kerberos - Key Distribution Center (KDC, центр распределения ключей).
Когда пользователь выполняет первичную аутентификацию после успешного подтверждения его подлинности, KDC выдает первичное удостоверение пользователя для доступа к сетевым ресурсам - Ticket Granting Ticket (TGT).
В дальнейшем при обращении к отдельным ресурсам сети, пользователь, предъявляет TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу - Ticket Granting Service (TGS).
Одним из преимуществ протокола Kerberos, обеспечивающим высокий уровень безопасности, является то, что при любых взаимодействиях не передаются ни пароли, ни значения хеша паролей в открытом виде.
Расширение PKINIT позволяет использовать двухфакторную аутентификацию по токенам или смарт-картам на этапе предаутентификации Kerberos.
Вход в систему может быть обеспечен, как при использовании службы каталога домена, так и локальной службы каталога. TGT создается на основе электронной подписи, которая вычисляется на смарт-карте или токене.
Все контроллеры доменов должны иметь установленный сертификат Domain Controller Authentication, или Kerberos Authentication, т. к. реализуется процесс взаимной аутентификации клиента и сервера.
Практика:
Приступим к настройке.
Сделаем так, чтобы в домен под вашей учетной записью можно было зайти только по предъявлению токена и зная PIN-код.
Для демонстрации мы будем использовать Рутокен ЭЦП PKI производства компании «Актив».
1 Этап - Настройка домена Первым делом установим службы сертификации.
Дисклеймер.
Эта статья не является туториалом по внедрению корпоративного PKI. Вопросы проектирования, разворачивания и грамотного применения PKI тут не рассматриваются ввиду необъятности этой темы.
Все контроллеры доменов и все клиентские компьютеры в рамках леса, где осуществляется внедрение такого решения, обязательно должны доверять корневому Удостоверяющему Центру (Центру Сертификации).
Задача центра сертификации - подтверждать подлинность ключей шифрования с помощью сертификатов электронной подписи.
Технически центр сертификации реализован как компонент глобальной службы каталогов, отвечающий за управление криптографическими ключами пользователей. Открытые ключи и другая информация о пользователях хранится удостоверяющими центрами в виде цифровых сертификатов.
Удостоверяющий центр, выдающий сертификаты для использования смарт-карт или токенов, должен быть помещен в хранилище NT Authority.
Зайдите в Диспетчер сервера и выберите «Добавить роли и компоненты».
При добавлении ролей сервера выберите «Службы сертификации Active Directory» (Microsoft категорически рекомендует не делать это на контроллере домена, дабы не огрести проблем с производительностью). В открывшемся окне выберите «Добавить компоненты» и выберите пункт «Центр сертификации».
На странице для подтверждения установки компонентов нажмите «Установить».
2 Этап - Настройка входа в домен с помощью токена
Для входа в систему нам понадобится сертификат, который содержит идентификаторы Smart Card Logon и Client Authentication.
Сертификат для смарт-карт или токенов также должен содержать UPN пользователя (суффикс имени участника-пользователя). По умолчанию суффиксом имени участника-пользователя для учетной записи является DNS-имя домена, которое содержит учетную запись пользователя.
Сертификат и закрытый ключ должны быть помещены в соответствующие разделы смарт-карты или токена, при этом закрытый ключ должен находиться в защищенной области памяти устройства.
В сертификате должен быть указан путь к точке распространения списка отзыва сертификатов (CRL distribution point). Такой файл содержит список сертификатов с указанием серийного номера сертификата, даты отзыва и причины отзыва. Он используется для передачи сведений об отозванных сертификатах пользователям, компьютерам и приложениям, пытающимся проверить подлинность сертификата.
Настроим установленные службы сертификации. В правом верхнем углу нажмите на желтый треугольник с восклицательным знаком и щелкните «Настроить службы сертификации…».
В окне «Учетные данные» выберите необходимые учетные данные пользователя для настройки роли. Выберите «Центр сертификации».
Выберите «ЦС предприятия».
ЦС предприятия интегрированы с AD. Они публикуют сертификаты и списки отзыва сертификатов в AD.
Укажите тип «Корневой ЦС».
На следующем этапе выберите «Создать новый закрытый ключ».
Выберите период действия сертификата.
3 этап - Добавление шаблонов сертификатов
Для добавления шаблонов сертификатов откройте Панель управления, выберите пункт «Администрирование» и откройте Центр сертификации.
Щелкните по названию папки «Шаблоны сертификатов», выберите пункт «Управление».
Щелкните по названию шаблона «Пользователь со смарт-картой» и выберите пункт «Скопировать шаблон». На следующих скриншотах показано, какие параметры в окне «Свойства нового шаблона» необходимо изменить.
Если в списке поставщиков нет «Aktiv ruToken CSP v1.0», то необходимо установить комплект «Драйверы Рутокен для Windows».
Начиная с Windows Server 2008 R2 вместо специального провайдера от производителя можно использовать «Microsoft Base Smart Card Crypto Provider».
Для устройств Рутокен библиотека «минидрайвера», поддерживающая «Microsoft Base Smart Card Crypto Provider», распространяется через Windows Update.
Проверить установился ли «минидрайвер» на вашем сервере можно подключив Рутокен к нему и посмотрев в диспетчер устройств.
Если «минидрайвера» по каким-то причинам нет, его можно установить принудительно, инсталлировав комплект «Драйверы Рутокен для Windows», а после этого воспользоваться «Microsoft Base Smart Card Crypto Provider».
Комплект «Драйверы Рутокен для Windows» распространяется бесплатно с сайта Рутокен .
Добавьте два новых шаблона «Агент сертификации» и «Пользователь с Рутокен».
В окне «Оснастки диспетчера сертификатов» выберите «моей учетной записи пользователя». В окне «Добавление и удаление оснастки» подтвердите добавление сертификатов.
Выберите папку «Сертификаты».
Запросите новый сертификат. Откроется страница для регистрации сертификата. На этапе запроса сертификата выберите политику регистрации «Администратор» и нажмите «Заявка».
Таким же образом запросите сертификат для Агента регистрации.
Чтобы запросить сертификат для определенного пользователя щелкните «Сертификаты», выберите пункт «Зарегистрироваться от имени...».
В окне для запроса сертификата установите флажок «Пользователь с Рутокен».
Теперь необходимо выбрать пользователя.
В поле «Введите имена выбранных объектов» укажите имя пользователя в домене и нажмите «Проверить имя».
В окне для выбора пользователя нажмите «Заявка».
В раскрывающемся списке выберите имя токена и укажите PIN-код.
Таким же образом выберите сертификаты для других пользователей в домене.
4 этап - Настройка учетных записей пользователей
Для настройки учетных записей откройте список пользователей и компьютеров AD.
Выберите папку Users и пункт «Свойства».
Перейдите на вкладку «Учетные записи», установите флажок «Для интерактивного входа в сеть нужна смарт-карта».
Настройте политики безопасности. Для этого откройте Панель управления и выберите пункт «Администрирование». Откройте меню для управления групповой политикой.
В левой части окна «Управление групповой политикой» щелкните «Default Domain Policy» и выберите пункт «Изменить».
В левой части окна «Редактор управления групповыми политиками» выберите пункт «Параметры безопасности».
Откройте политику «Интерактивный вход в систему: требовать смарт-карту».
На вкладке «Параметры политики безопасности» установите флажки «Определить следующий параметр политики» и «Включен».
Откройте политику «Интерактивный вход в систему: поведение при извлечении смарт-карты».
На вкладке «Параметры политики безопасности» установите флажок «Определить следующий параметр политики», из раскрывающегося списка выберите «Блокировка рабочей станции».
Перезагрузите компьютер. И при следующей попытке аутентификации в домене уже можно будет использовать токен и его PIN-код.
Двухфакторная аутентификация для входа в домен настроена, а значит существенно повышен уровень безопасность для входа в Windows домен без траты безумной суммы на дополнительные средства защиты. Теперь без токена вход в систему невозможен, а пользователи могут вздохнуть спокойно и не мучиться со сложными паролями.
Следующий шаг - безопасная почта, об этом и о настройке безопасной аутентификации в других системах читайте в наших следующих статьях.
Теги:
- windows server
- PKI
- Рутокен
- аутентификация
Реалии стран где живёт большинство хабровчан таковы, что держать сервера с важной информацией за пределами страны ведения бизнеса стало хорошим тоном, позволяющим сохранить свои нервы и данные.
Первый вопрос, который возникает при переезде в облако после шифрования данных, а может и перед ним, это гарантия того, что доступ к данным с учетной записью пользователя осуществляется именно пользователем, а не кем-то еще. И если неплохой способ шифрования данных, размещенных в частном облаке, рассмотрен в статье моего коллеги , то с аутентификацией все сложнее.
Про пользователей и методы защиты
Природа типичного пользователя такова, что к сохранности паролей от учетных записей отношение достаточно легкомысленное и исправить это невозможно. Наш опыт показывает, что даже если в компании применяются строгие политики, тренинги пользователей и т.д., все равно найдется незашифрованное устройство, покинувшее стены офиса, а просматривая список продуктов одной известной компании понимаешь, что извлечение паролей из незашифрованного устройства лишь дело времени.
Некоторые компании для контроля доступа к данным в облаке устанавливают туннели между облаком и офисом, запрещают удаленный доступ https://habrahabr.ru/company/pc-administrator/blog/320016/ . На наш взгляд - это не совсем оптимальное решение, во-первых, теряется часть преимуществ облачного решения, а во-вторых есть проблемы с производительностью, отмеченные в статье.
Решение с использованием терминального сервера и Remote Desktop Gateway (RDG) более гибкое, можно настроить высокий уровень безопасности, как описал мой коллега https://habrahabr.ru/post/134860/ (статья 2011 года, но сам принцип до сих пор актуален). Данный способ позволяет предотвратить передачу данных из облака, но накладывает ограничения на работу пользователя и не полностью решает проблему аутентификации, скорее это DLP решение.
Возможно лучшим способом гарантировать, что под учетной записью пользователя не работает злоумышленник, является двухфакторная аутентификация . В статьях моего коллеги https://habrahabr.ru/post/271259/ https://habrahabr.ru/post/271113/ описывается настройка MFA от Microsoft и Google для клиентского VPN. Способ хороший, но, во-первых, он требует наличия CISCO ASA, что не всегда легко реализуемо, особенно в бюджетных облаках, а во-вторых, работа через VPN неудобна. Работа с терминальной сессией через RDG значительно комфортнее, да и SSL протокол шифрования выглядит более универсальным и надежным, чем VPN от CISCO.
Решений с двухфакторной аутентификацией на самом терминальном сервере много, вот пример настройки бесплатного решения - http://servilon.ru/dvuhfaktornaya-autentifikaciya-otp/ . Это решение, к сожалению, не работает через RDG.
RDG сервер запрашивает подтверждение авторизации у сервера MFA. MFA в зависимости от выбранного способа аутентификации звонит, отправляет смс или посылает запрос в мобильное приложение. Пользователь подтверждает или отклоняет запрос на предоставление доступа. MFA возвращает результат второго фактора аутентификации на RDG сервер.
Установка и настройка Azure Multi-Factor Authentication Server
Создание поставщика аутентификации в портале Microsoft Azure
Заходим в Microsoft Azure (учетная запись должна иметь подписку или установлена триальная версия) и находим Multi-Factor Authentication (MFA).На данный момент управление MFA не добавлено в новую версия портала Azure, поэтому откроется старая версия портала.
Для создания нового поставщика многофакторной проверки подлинности необходимо слева внизу нажать «СОЗДАТЬ → Службы приложений → Active directory → Поставщик многофакторной проверки подлинности → Быстрое создание». Указать имя и модель использования.
От модели использования зависит как будет начисляться оплата, либо по количеству пользователей, либо по количеству аутентификаций.
После создания MFA отобразится в списке. Далее переходим к управлению, нажав соответствующую кнопку.
Переходим в загрузки и скачиваем MFA сервер
Развертывание MFA сервера
Устанавливать MFA сервер необходимо на виртуальную машину отличную от RDG сервера. Поддерживаются ОС старше Windows Server 2008 или Windows 7. Для работы необходим Microsoft .NET Framework 4.0.Должны быть доступны адреса по 443 порту:
Устанавливаем MFA сервер, при установке отказываемся от мастера настроек.
При первом запуске необходимо ввести данные от учетной записи, которые надо сгенерировать на странице загрузки сервера.
Далее добавляем пользователей. Для этого переходим в раздел Users и нажимаем на Import from Active Directory, выбираем пользователей для импорта.
При необходимости можно настроить автоматическое добавление новых пользователей из АД:
«Directory Integration → Synchronization → Add», а т.ж. добавить каталог, который будет автоматически синхронизироваться по указанному интервалу времени.
Проведем тест работоспособности MFA сервера. Переходим в раздел Users. Для своей учетной записи указываем номер телефона (если еще не задан) и выбираем способ аутентификации «Звонок телефона». Нажимаем кнопку Test и вводим логин, пароль. На телефон должен прийти вызов. Отвечаем на него и нажимаем #.
Настройка MFA сервера на работу с Radius запросами
Переходим в раздел Radius Authentication и ставим галочку «Enable RADIUS Authentication».Добавляем нового клиента, указывая IP адрес NPS сервера и общий секретный ключ. Если аутентификация должна проводиться для всех пользователей, ставим соответствующую галочку (в данном случае все пользователи должны быть добавлены на MFA сервер).
Так же необходимо убедиться, что указанные для соединения порты соответствуют портам, указанным на NPS сервере и их не блокирует брандмауэр.
Переходим на вкладку Target и добавляем Radius сервер.
Примечание: Если в сети нет центрального NPS сервера, IP адреса Radius клиента и сервера будут одинаковыми.
Настройка RDG и NPS сервера на работу совместно с MFA
Шлюз удаленных рабочих столов необходимо настроить на отправку Radius запросов на сервер MFA. Для этого открываем свойства шлюза и переходим на вкладку «RDG CAP Store», выбираем «NPS работает на центральном сервере» и указываем адрес MFA сервера и общий секретный ключ.
Далее производим настройку NPS сервера. Разворачиваем раздел «Клиенты и серверы Radius → Удаленные группы серверов Radius». Открываем свойства группы «TS gateway server group» (группа создаётся при настройке RDG) и добавляем наш MFA сервер.
При добавлении, на вкладке «Load Balancing» увеличиваем лимиты времени ожидания сервера. Выставляем «Число секунд без ответа, после которого запрос считается отброшенным» и «Число секунд между запросами, после которого сервер считается недоступным» в диапазоне 30-60 секунд.
На вкладке «Authentication/Accounting» проверяем правильность указанных портов и задаем общий секретный ключ.
Теперь перейдем в раздел «Клиенты и серверы Radius → Клиенты Radius» и добавим MFA сервер, указав «Friendly name», адрес и общий секрет.
Переходим в раздел «Политики → Политики запросов на подключение». В данном разделе должна быть политика, созданная при настройке RDG. Эта политика направляет запросы Radius на MFA сервер.
Дублируем политику и заходим в ее свойства. Добавляем условие сопоставляющее «Client Friendly Name» c «Friendly name», заданным в предыдущем шаге.
На вкладке «Settings» меняем поставщика услуг аутентификации на локальный сервер.
Данная политика будет гарантировать то, что при получении Radius запроса от MFA сервера, запрос будет обработан локально, что избавит от зацикливания запросов.
Проверяем что данная политика размещена над исходной.
На данном этапе связка RDG и MFA находится в рабочем состоянии. Следующие шаги необходимы тем, кому требуется иметь возможность использовать аутентификацию с помощью мобильного приложения или предоставить пользователям доступ к некоторым настройкам многофакторной авторизации через пользовательский портал.
Установка SDK, веб-службы мобильного приложения и пользовательского портала
Подключение к данным компонентам производиться по HTTPS протоколу. Поэтому, на сервера где они будут развернуты, необходимо установить SSL сертификат.Пользовательский портал и веб-служба мобильного приложения используют пакет SDK для связи с сервером MFA.
Установка SDK
SDK устанавливается на сервер MFA и требует наличия IIS, ASP.NET, Basic Authentication, которые необходимо предварительно установить, используя Server Manager.Для установки SDK переходим в раздел Web Service SDK в Multi-Factor Authentication Server и нажимаем кнопку установить, следуем мастеру установки.
Установка веб-службы мобильного приложения
Данная служба необходима для взаимодействия мобильного приложения с сервером MFA. Для корректной работы службы, компьютер, на который она будет установлена, должен иметь выход в интернет и открыт 443 порт для подключения из интернета.Файл установки службы находиться в папке C:\Program Files\Azure Multi-Factor Authentication на компьютере с установленным MFA. Запускаем установщик и следуем мастеру установки. Для удобства пользователей можно заменить имя виртуального каталога «MultiFactorAuthMobileAppWebService» на более короткое.
После установки заходим в папку C:\inetpub\wwwroot\MultiFactorAuthMobileAppWebService и изменяем файл web.config . В данном файле необходимо задать ключи , отвечающие за учетную запись, входящую в группу безопасности PhoneFactor Admins. Эта учетная запись будет использоваться для подключения к SDK.
В этом же файле необходимо указать URL адрес по которому доступен SDK.
Примечание: Соединение с SDK производиться по SSL протоколу, поэтому необходимо ссылаться на SDK по имени сервера (указанному в SSL сертификате), а не по IP адресу. Если обращение осуществляется по локальному имени, нужно добавить в hosts файл соответствующую запись, чтобы использовать SSL сертификат.
Добавляем URL, по которому доступна веб-служба мобильного приложения, в приложение Multi-Factor Authentication Server в раздел Mobile App. Это необходимо для правильной генерации QR кода в пользовательском портале для подключения мобильных приложений.
Также в этом разделе можно установить галочку «Enable OATH tokens», что позволить использовать мобильное приложения как Software token, для генерации одноразовых паролей на основании времени.
Установка пользовательского портала
Для установки требуется IIS, ASP.NET и роль совместимости мета базы IIS 6 (для IIS 7 или более поздней версии).Если портал устанавливается на сервере MFA, достаточно в Multi-Factor Authentication Server перейти в раздел User Portal, нажать кнопку установить и следовать мастеру установки. Если компьютер присоединен к домену, то при установке будет создан пользователь, входящий в группу безопасности PhoneFactor Admins. Этот пользователь необходим для защищённого соединения с SDK.
При установке на отдельный сервер, необходимо скопировать файл установки с сервера MFA (файл установки располагается в папке C:\Program Files\Multi-Factor Authentication Server ). Произвести установку и отредактировать файл web.config в расположение C:\inetpub\wwwroot\MultiFactorAuth . В данном файле необходимо изменить ключ USE_WEB_SERVICE_SDK со значения false на true. Указать данные учетной записи, входящей в группу PhoneFactor Admins в ключах WEB_SERVICE_SDK_AUTHENTICATION_USERNAME и WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD . И указать URL адрес SDK службы, не забывая при необходимости поправить hosts файл, чтобы работал SSL протокол.
Добавляем URL, по которому доступен пользовательский портал в приложение Multi-Factor Authentication Server в раздел User Portal.
Демонстрация работы Azure MFA для аутентификации RDG подключений
Рассматривать работу MFA будем со стороны пользователя. В нашем случае вторым фактором аутентификации будет мобильное приложение, так как сотовая сеть имеет ряд уязвимостей, позволяющих при должной подготовке перехватывать звонки и SMS.Первым делом, пользователю понадобиться зайти на пользовательский портал и указать свой номер телефона (если не указан в AD) и привязать к аккаунту мобильное приложение. Заходим на портал под своей учетной записью и вводим ответы на секретные вопросы (они нам понадобятся в случае восстановления доступа к аккаунту).
Далее выбираем метод аутентификации, в нашем случае мобильное приложение и нажимаем кнопку «Создать код активации». Будет сгенерирован QR код, который надо отсканировать в мобильном приложении.
Так как при импортировании пользователей на MFA сервер была выставлена аутентификация с помощью PIN кода, нам будет предложено создать его. Вводим желаемый PIN код и нажимаем «Проверить мою подлинность». В мобильном приложении необходимо подтвердить появившийся запрос. После данных действий мы имеем привязанное к аккаунту приложение и полноценный доступ к порталу для изменения личных настроек.
Пароль является не очень надежным средством защиты. Очень часто используются простые, легко подбираемые пароли или же пользователи не особо следят за сохранностью своих паролей (раздают коллегам, пишут на бумажках и т.д.). В Microsoft уже давно реализована технология, позволяющая для входа в систему использовать SmartCard, т.е. аутентифицироваться в системе по сертификату. Но не обязательно использовать непосредственно смарт-карты, ведь для них нужны еще и считыватели, поэтому проще их заменить на usb токены. Они позволят реализовать двухфакторную аутентификацию: первый фактор — это пароль от токена, второй фактор — это сертификат на токене. Далее на примере usb токена JaCarta и домена Windows я расскажу как внедрить этот механизм аутентификации.
Первым делом в AD создадим группу «g_EtokenAdmin» и уч. запись «Enrollment Agent», входящую в эту группу. Эта группа и пользователь будут рулить центром сертификации.
Дополнительно установим Web службу для запроса сертификатов.
Далее выбираем вариант для предприятия. Выбираем Корневой ЦС (если у нас это первый центр сертификации в домене)
Создаем новый закрытый ключ. Длину ключа можно оставить туже, а вот алгоритм хеширования лучше выбрать SHA2 (SHA256).
Введем имя CA и выберем срок действия основного сертификата.
Остальные параметры оставляем по умолчанию и запускаем процесс установки.
После установки зайдем в оснастку центра сертификации и настроим права на шаблоны.
Нас будут интересовать два шаблона: Агент регистрации (Enrollment Agent) и Вход со смарт-картой (Smartcard logon).
Зайдем в свойства этих шаблонов и на вкладке безопасность добавим группу «g_EtokenAdmin» с правами чтение и заявка.
И они появятся у нас в общем списке.
Следующим шагом настроим групповые политики:
Первым делом расскажем всем компьютерам домена о корневом центре сертификации, для этого изменим Default Domain Policy.
Конфигурация компьютера -> Политики -> Конфигурация Windows -> Параметры безопасности -> Политики открытого ключа -> Доверенные корневые центры сертификации -> Импорт
Выберем наш корневой сертификат, расположенный по пути: C:\Windows\System32\certsrv\CertEnroll. Закрываем Default Domain Policy.
На следующем шаге создадим политику для контейнера, в котором будут находится компьютеры с аутентификацией по токену (Смарт-карте).
По пути Конфигурация компьютера -> Политики -> Конфигурация Windows -> Параметры безопасности -> Локальные политики -> Параметры безопасности. Настроим два параметра «Интерактивный вход в систему: требовать смарт-карту» и «Интерактивный вход в систему: поведение при извлечении смарт-карты».
На этом с настройками все, теперь можно генерировать клиентский сертификат и проверять аутентификацию по токену.
Залогинемся на компьютере под учетной записью «Enrollment Agent» и откроем браузер, перейдя по ссылке http://Имя_сервера_MS_CA/certsrv
Выбираем пункт Запрос сертификата -> Расширенный запрос сертификата -> Создать и выдать запрос к этому ЦС
Если возникнет ошибка вида «Чтобы завершить подачу заявки на сертификат, следует настроить веб-узел для ЦС на использование проверки подлинности по протоколу HTTPS», то нужно на сервере IIS, на котором установлен MS CA, сделать привязку сайта к протоколу https.
Продолжим получение сертификата, для этого на открывшейся странице выберем шаблон: «Агент регистрации» и нажмем кнопку выдать и установить сертификат.
Теперь пользователь Enrollment Agent может выписывать сертификаты для других пользователей. К примеру запросим сертификат для пользователя test. Для этого откроем консоль управления сертификатами certmgr.msc, т.к. через web интерфейс не получится записать сертификат на usb токен.
В этой консоли на папке личное сделаем запрос от имени другого пользователя
В качестве подписи выбираем единственный сертификат «Enrollment Agent» и переходим к следующему шагу, на котором выбираем пункт «Вход со смарт-картой» и нажимаем подробности для выбора криптопровайдера.
В моем случае я использую токены JaCarta, поэтому вместе с драйверами был установлен криптопровайдер «Athena…»:
На следующем шаге выбираем доменного пользователя, для которого выписываем сертификат и нажимаем на кнопку «Заявка».
Вставляем токен, вводим пин код и начинается процесс генерации. В итоге мы должны увидеть диалоговое окно с надписью «Успешно».
Если процесс окончился неудачно, возможно дело в шаблоне получения сертификата, в моем случае его надо было немного подправить.
Приступим к тестированию, проверим работу токена на компьютере, находящемся в OU с групповой политикой входа по смарт-карте.
При попытке войти под учетной записью с паролем мы должны получить отказ. При попытке войти со смарт-картой (токеном) мы получим предложение ввести пин и должны успешно зайти в систему.
P.s.
1) Если не работает автоматическая блокировка компьютера или выход из системы, после вытаскивания токена, смотрите запущена ли служба «Политика удаления смарт-карт»
2) На токен можно записать (сгенерировать сертификат) только локально, через RDP не получится.
3) Если не получается запустить процесс генерации сертификата по стандартному шаблону «Вход с смарт-картой», создайте его копию с такими параметрами.
На этом все, если будут вопросы, задавайте, постараюсь помочь.
