Регистрация

Доклады

Готовые решения

Докладчики

Записи мероприятий

Обратная связь

Расширенный поиск

DevCon 11

Вход на сайт:

Альтернативные системы входа

Популярные ключевые слова

Для IT-специалистов

Для разработчиков

Важные ссылки

Двухфакторная аутентификация в Службе Каталога AD DS

8,26

Рейтинг доклада:

Главная

Информационная безопасность

Высокое качество (800*600) | Низкое качество (320*240)

Описание доклада

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

Переключиться в Windows Media Player

Ресурсы для дальнейшего изучения

Комментарии пользователей (19)

Пользователь snegovic написал 25.04.2010 в 20:35

Спасибо, хороший доклад.

Пользователь Fuzzy_logik написал 28.04.2010 в 13:44

Спасибо! очень интересный доклад!

Пользователь Konstantin Leontiev написал 01.05.2010 в 12:56

Важные комментарий/предостережения к докладу:
1) Ничего (даже короткого предостережения) не сказано о важности планирования иерархии PKI и что одноранговая иерархия несет в себе определенные риски безопасности.
2) Инсталляция Certification Authority на контроллер домена является крайне не рекомендуемой практикой.
3) Так же Web-Enrollmet не нужен для реализаии Smart Card Logon сценария (особенно в конфигурации стенда в докладе) и даже для выписки сертификата Enrollment Agent, более того такая конфигурация может являться потенциальным источником уязвимости при инсталяции IIS 7.5 на контроллер домена (как это сделано в докладе).
4) Реализация Smart Card Logon вполне возможна на Stand Alone CA (требуются лишь дополнительные действия по публикации AIA/CDP и по запросу/получению клиентами сертификатов). Заявление о единственности выбора Enterprise CA безосновательно.
5) Никак не прокоментирован выбор крипто-провайдера и длины ключа, а так же имени CA (это по меньшей мере не аккуратно).
6) Нарушена рекомендация по сохранению неизменными Default политик GPO. Кроме того, при инсталяции Enterprise Root CA он автоматом вносит себя в AIA контейнер и нет необходимости добавлять его сертификат в групповую политику (тем более в Default).
7) Никак не прокоментирована и не продемонстрирована настройка ТРЕБУЮЩАЯ использовать Enrollment Agent для выпуска Smart-Card сертификатов по шаблону Smart Card Logon Template.
8) Не сказано, что для возможности выбора eToken Base Crypto Provider нужно установить соответствующий CSP (Aladdin eToken RTE)
9) Выбор продуктов Aladdin по меньшей мере странен, так как требует явной установки CSP, в то время как использование ключевых носителей Gemalto (обладающих той же функциональностью и широтой вариантов) позволяет использовать встроенные в ОС CSP без инсталляции каких-либо дополнительных драйверов и ПО.

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

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

Пользователь leonid_s написал 04.05.2010 в 12:21

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

1. Я не ставил целью этого доклада рассказать о методиках внедрения PKI и наилучших практиках. Я хотел проиллюстрировать, что внедрение PKI не так страшно, как может показаться на первый взгляд, и вполне под силу многим администраторам. «Не так страшен черт», так сказать.
2. Развертывание УЦ на контроллер домена не является рекомендуемой практикой, я нигде не рекомендую это в качестве решения. Тот факт, что на стенде используется единственный сервер, являющийся контроллером домена, преследует две цели: упрощение самого стенда и демонстрацию того, что даже в небольшой организации вполне доступно внедрение двухфакторной аутентификации.
3. Web Enrollment показан преднамеренно для того, чтобы продемонстрировать невозможность запроса сертификата на смарт карту от имени другого пользователя через Web enrollment, как это было возможно раньше в предыдущих версиях операционных систем. Возможно, это лишний шаг, т.к. демонстрация рассчитана на начинающих знакомство с PKI и «не отягощённых» особенностями PKI в Windows Server 2003.
4. Использование Enterprise CA действительно не является обязательным, тем не менее, выбор, на мой взгляд, оправдан ввиду того, что нам чрезвычайно удобно использовать службу каталога AD DS для проверки возможности получения сертификата пользователем, контролируя это на уровне групп, что и было продемонстрировано. Также наличие функционала Enrollment Agent значительно упрощает процедуру выдачи. В случае Standalone CA выпуск сертификата аналогичного шаблону Smartcard User – нетривиальная задача, плюс вопросы ручного одобрения запросов на выдачу сертификата…
5. Выбор криптопровайдера, длины ключа и имени удостоверяющего центра не прокомментирован. Думаю, что это также лучше сделать в докладе по проектированию инфраструктуры PKI.
6. Согласен. Это мое упущение.
7. Я не ставил целью в настоящем докладе рассказывать наилучшие практики по внедрению PKI. Это тема отдельного доклада, в рамках которого на это, несомненно, имеет смысл обратить внимание. С другой стороны указанный Вами «момент» важен, с точки зрения внедрения двухфакторной аутентификации, и об этой особенности нового удостоверяющего центра мне стоило бы рассказать.
8. Действительно, без установки eToken PKI Client, невозможно использовать eToken Base Crypto Provider. В качестве альтернативы можно использовать стандартный криптопровайдер Microsoft (Microsoft Smartcard Base CSP + SafeNet Minidriver), не устанавливая eToken PKI Client. Тем не менее, у меня на стенде установлен eToken PKI Client, т. к. он предоставляет не только функции криптопровайдера, но и ряд дополнительных возможностей по работе с самим USB - ключом или смарт картой, плюс утилита управления (eToken Properties) и интерфейсная библиотека PKCS11.
9. Мой выбор Aladdin eToken обусловлен тем, что на сегодняшний день это средство аутентификации обладает сертификатом ФСТЭК России №1883 на весь модельный ряд и является рекомендуемым средством аутентификации во всех защищенных системах на территории Российской Федерации. Мне ничего неизвестно о наличии подобных сертификатов у ключей Gemalto, а на это в проектах реально обращают внимание и безопасники, и IT-шники. Кроме того, смарт карты и USB ключи eToken обладают возможностью встраивания меток RFID, позволяя интегрировать систему аутентификации с системой разграничения физического доступа. Таким образом, выбор в качестве средства аутентификации решения от Aladdin мне представляется вполне оправданным.

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

Пользователь tipo_opa написал 27.06.2010 в 00:18

Спасибо, очень познавательно

Пользователь sivtsovib написал 10.08.2010 в 12:37

Как рекомендуется действовать по п. 6? Каую политику изменять?

Пользователь Konstantin Leontiev написал 10.08.2010 в 15:10

По п.6: Если все клиенты вашего PKI подключены к тому лесу AD, в котором этот PKI развернут, то они автоматом получат в состав списка доверенных CA сертификаты опубликованные в AIA. Таким образом вообще нет необходимости размещать эти сертификаты в каких либо политиках. Размещение сертификатов в политике необходимо в том случае, если вы ходите сделать доверенным для большого числа компьютеров сертификат CA из внешнего леса или вообще от внешней организации.

Пользователь sivtsovib написал 10.08.2010 в 17:24

Ок, спасибо. Понял.

Пользователь igor-n написал 03.11.2010 в 18:22

Для внедрения данного решения (2-факторной аутентификации) необходимо поднятие центра сертификации в домене. В связи с этим вопросы:
1. Что будет, если, к примеру, центр сертификации окажется недоступным? Пользователи смогут выполнить вход на рабочие станции с использованием своих токенов?
2. Что будет, если контрллеры домена окажутся недоступными?

Пользователь leonid_s написал 08.11.2010 в 14:52

#10

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

Пользователь igor-n написал 08.11.2010 в 19:18

#11

Леонид, спасибо за быстрый ответ!
Правильно ли я его трактую:
1. Если УЦ окажется недоступным, то пользователи смогут выполнить вход с текущими токенами?
2. Если контроллеры домена окажутся недоступными, то пользователи (а речь идет о фиксированном количестве рабочих мест и людях, постоянно на них работающих) смогут войти в систему с кэшированными данными?
3. Можно ли реализовать "резервный" УЦ? Например, поднять на соседнем контроллере домена?

Пользователь igor-n написал 11.11.2010 в 13:11

#12

Можно ли реализовать 2-факторную аутентификацию в терминальном сеансе? Терминальный сервер - ОС Win2003R2 St.Ed.

Пользователь leonid_s написал 23.11.2010 в 10:40

#13

Да, разумеется, терминальный сеанс не является препятствием. Вы можете это реализовать.
На контроллерах домена не рекомендуется разворачивать УЦ.

Пользователь igor-n написал 23.11.2010 в 11:03

#14

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

Пользователь leonid_s написал 23.11.2010 в 12:49

#15

Если Вы не можете следовать рекомендациям, которые дает Microsoft, Вы вынуждены идти на снижения уровня безопасности, однако еще раз хочу отметить, что это не Best Practice.

Если я правильно понимаю, то Вам требуется обеспечить повышенный уровень доступности УЦ. В Windows 2008 появилась новая возможность - отказоустойчивая кластеризация УЦ.

Кластер поддерживает режим только Active/Passive, т. е. один узел находится в активном, а другой в пассивном режиме. При выходе из строя узла не прекращается доступ УЦ его БД и спискам отзыва сертификатов.

Пользователь igor-n написал 25.11.2010 в 13:00

#16

Леонид, спасибо за ответы!

Скажите, можно ли сделать, чтобы несколько человек работали (каждый со своим токеном) под 1 учетной записью?
- Как это сделать?

Пользователь leonid_s написал 07.12.2010 в 16:46

#17

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

Пользователь kvazar1984 написал 06.12.2011 в 17:04

#18

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

Пользователь leonid_s написал 07.12.2011 в 17:35

#19

Дело в том, что в Вашем вопросе, по сути, содержится два вопроса:

1. Можно ли обойтись без дополнительного ПО на клиентские компьютеры?
2. Если нет, то есть ли бесплатные продукты?

Ответы на оба эти вопроса положительные.
1. Вы можете использовать ряд карт и токенов, не требующих дополнительного ПО.
2. Существуют программные продукты по работе с картами и токенами, которое является бесплатным. Например, PKI Client, который я использовал в демонстрациях, таковым и является, и доступен для скачивания на сайте производителя. Что касается методики развртывания ПО, то вариантов автоматизации этого процесса множество.
С уважением,
Леонид.

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

Подписаться на комментарии

Чтобы оставить комментарий вам нужно авторизоваться или зарегистрироваться.

Теги доклада

Active Directory, Windows 7, Windows Server 2008 R2, Windows XP

Файлы для загрузки

Презентация (1,13 Mb)

Звуковая трансляция (7,65 Mb)

WMV 800*600 (47,15 Mb)

WMV 320*240 (15,84 Mb)

Видео для Ipod, 320x240 (57,49 Mb)

Авторы: Леонид Шапиро

Просмотров: SilverLight: 953
Windows Media Player: 215
Уровень: 200
Публикация: 25.04.2010

Нужно ли добавить на TechDays.ru записи живых выступлений?

Да, но только в хорошем качестве
Да, пусть даже в более плохо качестве
Нет, пусть будут только скринкасты

Разместить в сервисах

Спонсоры и партнеры проекта