Как при помощи токена сделать Windows домен безопаснее? Часть 1

[Francyz]

Интересно, спасибо! Чем подробнее будут след. статьи тем лучше )

[vesper-bot]

Вопрос, а в чужом домене по тому же сертификату авторизоваться можно? Предполагается, что в чужом домене сертификат root CA прописан в NTAuth.

[Tto_ogarin]

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

[nmk2002]

1. Закрытый и открытый ключи ЧЕГО вы предлагаете внести в центр сертификации? И вообще как это «внести закрытый и открытый ключ в центр сертификации»?
2. Что значит опубликован наружу? Зачем? В действительности доступен должен быть только список отзыва — CRL и/или OCSP-респондер.
Смотрите мой ответ ниже.

[nmk2002]

Конечно, вы можете использовать сертификат для любого домена. Важно понимать, что PKI может быть любой, не обязательно MSCA как в статье. Все, что вам нужно — настроить контроллеры домена:
1. Контроллеры домена должны доверять УЦ (то, о чем вы написали)
2. У самих контроллеров домена должны быть сертификаты, выпущенные этим УЦ. Это в статье опущено, так как если УЦ MSCA и сам находится в домене(что, как вы понимаете, не всегда так), то он автоматически выпускает сертификаты для всех контроллеров своего домена. В противном случае их надо просто выпустить вручную.

[vesper-bot]

> 2. У самих контроллеров домена должны быть сертификаты, выпущенные этим УЦ.

Вот это интересно. Я последний раз настраивал такую инфраструктуру, и этого пункта не требовалось. Но инфраструктура была на 2003м домене, как «своя» с УЦ, так и «чужая». Сейчас усиленно маюсь с настройками 2012го домена, уперся в NLA, которая мешает аутентификации, заставляя сначала подтвердить валидность сертификата на «своем» домене, после чего отдает «свой» домен на другую сторону.

[nmk2002]

Тут можете поподробнее посмотреть.

[vesper-bot]

В принципе так и настроено. Спасибо, я ещё покопаюсь, но обойти NLA при доступе к удаленному домену с ПК в локальном домене может оказаться невозможно.

[pnetmon]

Как пользователи заходят на терминальные сервера?

[aeowka]

Точно так же, используя токен. Вместо ввода user\pass, предлагается ввести пин от токена.

[DenSyo]

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

[nmk2002]

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

[DenSyo]

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

[vov_i]

Не совсем так. В RDP сеансе не будут работать удаленные карты, подключенные к хосту. RDP запрещает так делать. Локальные токены и карты пробрасывать в RDP сеанс можно при защищенном соединении.

[DenSyo]

http://www.rohos.com/support/rohos-logon-key-support/access-your-remote-desktop-in-a-secure-way-by-usb-stick-2/#4
Здесь токен перенаправляют в сеанс и все происходит на стороне сервера. Возможно есть разные варианты, но этот вполне пригоден даже для собственных поделок.

[Busla]

Наверное, не стоит бросаться подобными фразами:

Например, PIN-код от токена можно диктовать по телефону другим лицам

А использовать более аккуратные формулировки.

[sergeyns]

Хотелось бы поподробней про «Токен является уникальным некопируемым физическим объектом»

[vov_i]

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

[Nordicx86]

строго говоря извлечь данные можно, но довольно таки сложно — http://russian-karding.ucoz.ru/forum/15-19-1

[vov_i]

Так-то да, конечно. Вопрос в практической целесообразности на самом деле. Чтобы извлечь данные, нужно получить физический доступ к токену или карте. То есть, например, украсть. Если не рассматривать злонамеренного инсайдера, который поставил целью наделать дубликатов своей карты (вопрос — зачем?), пропажу карты или токена обнаружить куда проще, чем угон пароля. Это как раз дает время на реакцию, за которое можно успеть отозвать сертификат. Таким образом извлечение закрытого ключа аутентификации теряет практический смысл.
А в случае со злонамеренным инсайдером действия будут производиться от его имени. Реализация неотказуемости (non-repudation) от действий влечет ответственность за действия, произведенные с использованием закрытого ключа.
Извлекать ключи из карт имеет смысл в массовых сервисах типа платного спутникового телевидения для организации несанкционированного доступа к контенту. При этом обнаружить наличие дубликатов сложно, поскольку по факту абоненты не регистрируются в системе. То есть спутник вещает на всех, а карта используется просто для декодирования сигнала. Вот прямой экономический смысл. :)

[pnetmon]

А в случае со злонамеренным инсайдером действия будут производиться от его имени. Реализация неотказуемости (non-repudation) от действий влечет ответственность за действия, произведенные с использованием закрытого ключа.

Так в примере бывший сотрудник использует чужие данные — "Используя учетные данные бывшего коллеги и рабочий ноутбук", а если во время подготовки (узнать учетные данные другого сотрудника — логин — пароль) он так же скопировал токен?

[vov_i]

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

[pnetmon]

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

[vov_i]

Почему первый вход не будет обнаружен? Если коллега обнаружил пропажу токена или карты вовремя, то первого входа не будет.