Развертывание PKI на основе Windows server 2008 R2
 

Всем доброго времени суток! Руководство поставило задачу в очень сжатые сроки развернуть PKI в сети компании. Цель развертывания исключительно удаленный доступ с помощью Смарт карт. Вобщем перелопатив интернет пришел к выводу, что структура должна состоять из: Корневого центра сертификации, который почти все время находится в Offline и не входит в домен AD. Так же нужен подчиненный центр сертификации Enterprise. Он входит в домен и раздает клиентам сертификаты. И 3-й сервер, который входит в такую структуру - это Шлюз удаленных рабочих столов на основе 2008 R2. Вобщем в результате развертывания хотелось бы увидеть следующее: Сотрудник подсоединяется из дома по RDP к шлюзу удаленных рабочих столов и проходит аутентификацию на основе Etoken, дальше уже по своему основному паролю заходит на другие ресурсы, куда у него есть доступ согласно политикам. В силу сжатых сроков нет времени в тестовой среде проверять тонкости такой структуры и есть некоторые вопросы:
1.Если не публиковать списки отзывов сертификатов на внешнем web-сервере(У нас его просто сейчас нет). При присоединении к шлюзу удаленных рабочих столов, при условии что на нем настроена аутентификация на основе Etoken, кто будет проверять цепочку доверия сертификату и как: это будет пытаться сделать сам клиент или же это уже будет делать шлюз? Т.е. другими словами пройдет ли клиент аутентификацию на шлюзе с etoken, на котором находится наш внутренний сертификат, если нет внешнего Web-сервера. Теперь другой вопрос.
2. Если все-таки всю процедуру проверки делает шлюз при подсоединении к нему, то тогда по логике можно указывать размещение CRL как в Ldap так и просто в обычной шаре сетевой по UNC пути. Только не пойму как поступить в случае с корневым центром. Т.к он ничего не знает о домене нужно воспользоваться утилитой CertUtil для того, чтобы он о нем узнал. Но даже если это сделать(тоже пока не очень понял, что конкретно нужно, но думаю с этим разберусь), то остается не понятным, куда потом в Active directory копировать эти самые списки, чтобы ссылки на CRL оказались рабочими. Ведь понятно, что корневой центр не находится вообще в сети и перемещение этих списков производится в ручную. Если в списках, скажем указана ссылка на сетевую шару, то тут все понятно - просто списки туда копируются и все. Только сразу встает вопрос с разрешениями на такую папку... очевидно, что надо ставить чтение всем тем, кто будет использовать etoken. Еще наверно придется запретить удаление. Надеюсь на Вашу помощь.

Для сетевой папки (можно указать разрешения как на уровне NTFS, так и на уровне SMB) указать "ВСЕ: Чтение" и "Администраторы: Полный доступ"

Кстати, насчёт сетевых папок.
Используйте DFS с доменными именами, которые не привязаны к конкретному серверу.
Потому что иначе в случае переименования сервера или переноса списка отзывов на другой сервер вам придётся перевыпускать ВСЕ сертификаты, в которых было указано старое имя сервера.

Поскольку ПК пользователя, подключаясь к серверу по защищённому каналу, должен проверить сертификат сервера (во избежании ситуации "человек посередине"), ему тоже потребуется доступ к спискам отзывов сертификатов.
Таким образом также скорее всего потребуется указывать размещение по HTTP на официальном сервере организации.

Спасибо за ответ. Логика понятна. Думаю, по пунктам все ответы верны. Т.к в сертификате явно указаны ссылки на сами сертификаты и списки отзывов, то клиент тоже должен проверять эти списки и доверять цепочке. Просто достаточно почитать про принципы работы Certificate Chaining Engine. А по поводу того, как реализовать такую схему работы со шлюзом, частично есть в моей другой теме:
http://forum.oszone.net/thread-281228.html