Update 04.08.2011: добавлено примечание по AlternateSignatureAlgorithm в CAPolicy.inf и пост-конфигурационном скрипте. Обязательно прочтите.

Ссылки на другие материалы из этой серии:

• Устанавливаем Certification Authority — Подведение итогов

В первой части установки Certification Authority мы рассмотрели общие вопросы планирования иерархии центров сертификации для сферических задач в вакууме. Я намерено опустил организационные вопросы, которые тоже должны решаться на этапе планирования и остановился лишь на технических аспектах планирования. Итак, как мы договорились в первой части, у нас будет двухуровневая иерархия с Offline Root CA и Online Issuing  Subordinate CA.

Step 1 — Preparing to install

Примечание: по различым причинам я не описываю процедуру установки и настройки Certificate Services на систему под управлением Windows Server 2003. Многое из изложенного будет справедливо и для Windows Server 2003, но часть из этого не будет справедливо для него.

Предполагается, что компьютер с именем RootCA установлен, обновлён и сконфигурированы параметры безопасности. Данный компьютер будет выполнять роль корневого центра сертификации (Root Certification Authority). Поскольку корневой CA — самая важная точка в иерархии PKI, этот сервер будет нормально выключен и включаться только для следующих целей:

• Отправка новой заявки на сертификат;
• Публикация CRL;
• Обновление сертификата самого CA;
• Установка обновлений безопасности.

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

Вводные данные для корневого сервера CA:

• Имя CA — Adatum Class 1 Root Certification Authority;
• Тип CA — Standalone.
• Срок действия сертификата CA — 10 лет;
• Срок действия издаваемых сертификатов — 10 лет;
• Срок действия Base CRL — 90 дней (3 месяца);
• Delta CRL публиковаться не будет;
• Расширения CDP (CRL Distribution Point) и AIA (Authority Information Access) будут настроены в соответствии с: Планирование расширений CDP и AIA;
• CDP и AIA будут использовать только ссылки на HTTP. LDAP использоваться не будет.
• OCSP для Offline Root CA предусмотрен.

Step 2 — Installing AD CS role on Offline Root CA

Перед установкой роли AD CS, необходимо создать конфигурационный файл, который будет использоваться установщиком роли. Для этого в папке %systemroot% необходимо создать файл с именем CAPolicy.inf и внести в него следующий текст:

[Version]
Signature= "$Windows NT$"

[certsrv_server]
; Устанавливаем длину ключа, которая будет использоваться
; *только* при обновлении сертификата CA
RenewalKeyLength = 2048
; Устанавливаем срок действия обновлённого сертификата.
; Будет использоваться *только* при обновлении сертификата CA
RenewalValidityPeriodUnits = 10
; Устанавливаем единицу измерения для предыдущего параметра
RenewalValidityPeriod = years
; Устанавливаем периодичность публикации CRL в 90 дней (или 3 месяца)
CRLPeriodUnits = 90
CRLPeriod = days
; Устанавливаем срок продления CRL. Фактический срок действия CRL для клиентов увеличивается на
; на заданный период, который в нашем случае равен 2 неделям. Это означает, что сервер CA будет
; публиковать новый CRL каждые 90 дней, а срок действия этого CRL будет 104 дня. Это даст
; администраторам возможность успеть забрать новый CRL с сервера и распространить его в нужные локации
CRLOverlapUnits = 2
CRLOverlapPeriod = weeks
; Отключаем публикацию Delta CRL
CRLDeltaPeriodUnits = 0
CRLDeltaPeriod = hours
; Включаем дискретные алгоритмы для подписей. Не включайте его если у вас есть клиенты под управлением
; Windows 2000, Windows XP, Windows Server 2003, поскольку указанные системы не поддерживают альтернативные подписи.
;AlternateSignatureAlgorithm = 1

Примечание: конфигурационный файл должен обязательно называться CAPolicy.inf и обязательно храниться в %systemroot%. Другие имена и локации файла не допускаются, иначе он попросту будет проигнорирован. Данный файл доступен для скачивания по ссылке в конце поста.

Когда конфигурационный сохранён в нужном месте, можно приступать к установке роли CA. Для этого запустите Server Manager, перейдите на секцию Roles и нажмите Add Roles. После этого запустится мастер установки ролей.

Примечание: если у вас используется HSM (Hardware Security Module), его драйвер должен быть установлен заранее. И на шаге 8 в списке криптопровайдеров необходимо выбрать CSP производителя вашего HSM.

Примечание: в ходе установки роли AD CS на шаге 9 вместо Adatum укажите название вашей компании. Места, в которых необходимо прописать свои данные заключены в фигурные скобки — {}.

1. На странице Before You Begin вы можете ознакомиться с информацией об этом мастере. После ознакомления нажмите Next.
2. На странице Select Roles выберите Active Directory Certificate Services и нажмите Next.
3. На следующей странице прочтите вводную информацию о роли AD CS и нажмите Next.
4. На странице Role Services убедитесь что установлен чек-бокс только напротив Certification Authority и нажмите Next.
5. На странице Setup Type выберите Standalone. Поскольку компьютер не является членом домена, Enteprise нам недоступен. Нажмите Next.
6. На странице выбора типа CA выберите Root CA и нажмите Next.
7. На странице Private Key выберите Create a new private key и нажмите Next.
8. На странице Cryptography выберите следующий криптопровайдер из списка: RSA#Microsoft Software Key Storage Provider
   Установите длину ключа в 2048 бит и алгоритм подписи в SHA1. После чего нажмите Next.
9. На странице выбора имени CA введите следующее:
   
   {Adatum} Class 1 Root Certification Authority.
   
   в поле Distinguished name suffix укажите примерно такое:
   
   OU=Information Systems,O={Adatum Ltd.},C={LV}
   
   и нажмите Next.
10. На странице Validity Period укажите срок действия сертификата. В большинстве случаев 10 лет — наиболее оптимальный срок действия корневого сертификата. Нажмите Next.
11. На странице Certificate database укажите путь, по которому будет храниться БД сервера CA. Можно использовать и дефолтное или, если на сервере есть отказоустойчивый массив (Raid1, Raid5 и производные от них), рекомендуется размещать БД именно на них. Нажмите Next.
12. На странице Confirmation просмотрите настройки, которые вы указали. Если вы ошиблись на каком-то этапе — вернитесь назад и исправьте ошибку. Если всё правильно, нажмите Install и подождите пока мастер сконфигурирует роль.

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

Примечание: у вас может быть соблазн выбрать более стойкий алгоритм подписи. Например, SHA256 или SHA384. Однако, следует учесть, что предыдущие системы (например, Windows XP/Server 2003) могут испытывать трудности с проверкой подписей с использованием алгоритмов SHA-2. Более подробно можно почитать тут: http://blogs.msdn.com/alejacma/archive/2009/01/23/sha-2-support-on-windows-xp.aspx

Когда мастер установит роль AD CS, вы можете уже запустить оснастку Certification Authority из папки Administrative Tools. Однако, на этом ещё не всё закончилось. Сейчас нам необходимо применить скрипт, который сконфигурирует остальные настройки.

Step 3 — Finalizing Offline Root CA installation

Для настройки следующих параметров можно воспользоваться следующим скриптом (с правкой его под местные условия):

Примечание: места в которых необходимо подставить свои данные заключены в фигурные скобки — {}.

:: Создаём папку в корне диска C, где будут храниться CRT и CRL файлы
md C:\CertData

:: Задаём точки публикации CRL файлов и ссылки, публикуемые в издаваемых сертификатах. То же самое и для CRT файлов.
certutil -setreg CA\CRLPublicationURLs "65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n65:C:\CertData\{Adatum}_RCA%%8.crl\n2:http://www.{adatum.com}/pki/{Adatum}_RCA%%8.crl"
certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:http://www.{adatum.com}/pki/{Adatum}_RCA%%4.crt"

:: Если будет использоваться OCSP для корневого CA, расширение AIA должно выглядеть примерно cледующим образом:
:: certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:http://www.{adatum.com}/pki/{Adatum}_RCA%%4.crt\n32:http://www.{adatum.com}/ocsp"
:: учтите, что при использовании этого варианта, предыдущую строку требуется закомментировать или удалить
:: а эту строку раскомментировать соответственно.

:: Поскольку мы не можем управлять публикацией CRT файлов, мы его
:: переименовываем в нужное имя и копируем в папку CertData
ren %windir%\system32\CertSrv\CertEnroll\*.crt {Adatum}_RCA.crt
copy %windir%\system32\CertSrv\CertEnroll\{Adatum}_RCA.crt C:\CertData

:: задаём срок действия издаваемых сертификатов равным 10 лет
certutil -setreg CA\ValidityPeriodUnits 10
certutil -setreg CA\ValidityPeriod "Years"

:: Задаём параметры публикации CRL (повторяем, что было указано в CAPolicy.inf)
certutil -setreg CA\CRLPeriodUnits 90
certutil -setreg CA\CRLPeriod "Days"
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg CA\CRLDeltaPeriod "Days"
certutil -setreg CA\CRLOverlapPeriod "Weeks"
certutil -setreg CA\CRLOverlapUnits 2

:: Включаем AlternateSignatureAlgorithm. Не включайте его если у вас есть клиенты под управлением
:: Windows 2000, Windows XP, Windows Server 2003, поскольку указанные системы не поддерживают альтернативные подписи.
:: Certutil -setreg CA\csp\AlternateSignatureAlgorithm 1

:: включаем полный аудит для сервера CA
certutil -setreg CA\AuditFilter 127

:: Включаем поддержку сертификатов OCSP Response Signing на Offline CA:
certutil -v -setreg policy\editflags +EDITF_ENABLEOCSPREVNOCHECK

net stop certsvc && net start certsvc

:: Публикуем новый CRL в новую локацию.
certutil -CRL

Примечание: данный скрипт необходимо запустить только один раз. Скрипт доступен для скачивания по ссылке в конце поста.

Данный скрипт создаст в корне диска C: папку CertData, в которой будут храниться опубликованные списки CRL и файлы сертификатов сервера CA. При этом CRL'ы будут автоматически публиковаться в эту папку, а CRT нет. Это связано с тем, что начиная с Windows Server 2003 мы больше не имеем возможности управлять публикацей файлов CRT. Для этого мы берём файл из оригинальной папки CertEnroll, переименовываем в нужное нам имя и копируем в папку CertData. Здесь я ещё хочу остановиться на построении ссылок в CDP и AIA, поскольку они выглядят предельно ужасно. Давайте разберёмся с этим.

Step 4 — Understanding post-installation script

Возьмём следующую строку:

"65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n65:C:\CertData\Adatum_RCA%%8.crl\n2:http://www.adatum.com/pki/Adatum_RCA%%8.crl"

Как мы видим, данная строка строится из 3-х составляющих:

1. 65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl
2. 65:C:\CertData\Adatum_RCA%%8.crl
3. 2:http://www.adatum.com/pki/Adatum_RCA%%8.crl

Каждое составляющее является отдельной ссылкой, которую видно во вкладке Extensions свойств сервера CA в оснастке CertSrv.msc. Все эти составляющие пишутся в одну строку и разделяются символом новой строки: \n. Парсер CMD автоматически режет строку на куски по знаку новой строки. Когда мы разложили строку на более читабельные ссылки, пора и заняться ими. Первое, что нам бросается в глаза — это циферки перед ссылками. Циферки означают сумму параметров публикации. Т.е. что данная ссылка будет делать, публиковать физический файл, добавляться в расширение сертификатов или в расширение CRL и т.д. Это эквивалентно галочкам во вкладке Extensions. Каждая такая галочка имеет определённый числовой эквивалент (числовое значение). Предлагаю 2 таблички, которые покажут соответствие каждой галочке числовому значению для ссылок в расширении CDP и AIA:

Как видите, для расширения CDP число 65 является суммой чисел 1 и 64. Исходя из таблички мы можем узнать, что ссылка с таким префиксом публикует физические файлы для Base и Delta CRL. А цифра 2 (в третьей ссылке) означает, что эта ссылка будет добавляться в расширение CDP издаваемых сертификатов. Префикс ставится всегда перед самой ссылкой и отделяется от неё двоеточием — :. То же самое и касается ссылок в AIA.

Теперь осталось разобраться со знаками процента (%) и цифрами после них. Например: %windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl. Данные кракозябры представляют переменные, которые вы можете указывать при создании ссылок. Вот ещё одна табличка, которая показывает соответствие переменных их числовым значениям:

Примечание: данные значения справедливы как для расширения CDP, так и AIA.

Особо пытливые умы должны заметить, что в таблице указан один знак процента, а в скрипте по два знака. Никакой магии здесь нет, просто парсер CMD использует проценты для других целей. Следовательно, чтобы парсер CMD его не удалил, знак процента необходимо заэскейпить другим знаком процента. Более подробно об этих переменных и их значениях можно прочитать здесь:

• CRL Publishing Properties
• AIA Publishing Properties
• CRL Distribution Point Replacement Token

Правда, на технетах информация несколько устаревшая, но в целом сгодится для понимания.

Вот и всё, что я хотел рассказать про установку Offline Root CA. В следующей части я расскажу про установку Online Issuing CA и что-нибудь ещё.

Файлы для скачивания:

(для скачивания файла нажмите на кнопку правой кнопкой и выберите Save target as…)

Update 11.11.2010: Windows Server 2008 R2 Standard не поддерживает роль OCSP Responder.

Ссылки на другие материалы из этой серии:

• Устанавливаем Certification Authority — Подведение итогов

Prologue

Одной из самых больших проблем при внедрении PKI на предприятии является отсутствие навыков планирования и установки Certification Authority. Как я уже неоднократно отмечал, потребность в PKI возрастает с каждым днём, а вот понимания вопроса у людей не увеличивается. К чему это приводит? В лучшем случае это приводит к установке вида Next –> Next –> ????? –> PROFIT и последующей нетривиальной и болезненной переконфигурации инфраструктуры под бизнес-задачи. Но чаще это заканчивается смачным эпик-фейлом в виде абсолютно неработающей PKI. Вот один из примеров: Помогите установить и настроить службу сертификации. Пробояню себя ещё раз, сказав, что для многих планирование, установка и поддержка PKI кажется задачей не сложнее администрирования нотепада и укладывается по времени в промежуток обеденного перерыва. При этом они глубоко заблуждаются, поскольку даже книга Брайана Комара и Пола Адаре по PKI (Windows Server® 2008 PKI and Certificate Security) не даёт полного и детального представления о работе PKI, хотя там ТЗ хватит на не один год. В реальности для полного понимания материала ещё необходимо прочитать десяток вайтпеперов и всяческие RFC. Я не претендую на попытку устранить этот пробел, поскольку это нереально, но стараюсь дать какие-то полезные понятия и какие-то другие вещи в соответствии с бест-практисами.

PKI tasks

Во-первых, нужно определиться с задачами, которые могут потребовать внедрения PKI:

• Внедрение защищённых механизмов аутентификации — смарт-карты, сертификаты для аутентификации в IIS/VPN;
• Внедрение защищённых сетевых протоколов — L2TP, SSL, IPsec;
• Внедрение защищённой почты с шифрованием и/или подписью писем;
• Внедрение цифровых подписей документов и файлов, что гарантирует их целостность и альтернативу ручной подписи.
• Внедрение защищённых файловых хранилищ с шифрованием особо конфиденциальной информации.

Если из всего вышеперечисленного вам не нужно, PKI вам не нужна так же.

Planning CA hierarchy

В одном из своих предыдущих постов я вёл дискуссию об иерархиях PKI: Обсуждение схем иерархии Certification Authority. На основе этого материала мы подбеёрм схему для нашей инсталляции, которая будет описана в данном материале. Исходя из написанного по ссылке мы сразу отметаем вариант одноуровневой иерархии. Двухуровневая иерархия выглядит крайне привлекательно:

В принципе, если сеть достаточно сконцентрирована, такая схема будет идеальной для многих случаев. А если сеть географически распределена с крупными филиалами (сайтами), в каждый такой филиал можно добавить по ещё одному сертификату CA и получить вот такую схему:

Создание 3-х уровневой иерархии уже будет подразумевать разделение иерерхии на области действий CPS (Certificate Practice Statement) и будут подвержены различным политикам управления серверами CA. Это достаточно долгая песня и о ней говорить не будем. Поэтому мы остановимся на двухуровневой иерархии с одним корневым центром сертификации (Root CA) и одним издающим центром сертификации (Issuing CA).

Planning CA types

Microsoft поддерживает два типа центров сертификации — Standalone и Enterprise. Обычно администраторы привыкли устанавливать Enterprise CA и по очевидным причинам не используют Standalone CA. Чем они отличаются?

• Standalone

Характеризуются нетребовательностью к наличию домена Active Directory. Так же Standalone CA не использует шаблоны, следовательно вы не можете запрашивать сертификаты на таком CA через оснастку Certificates консоли MMC. Что означает, что вы не можете пользоваться функциями autoenrollment'а. Так же при выдаче сертификатов, Standalone CA не может автоматически публиковать сертификаты в свойства учётной записи пользователя или компьютера. Энролить сертификаты в Standalone CA можно только через Enrollment Web Pages, либо вручную генерируя запросы (файлы с расширением .req) и отправляя их через оснастку CertSrv.msc. Причём отправка запросов через оснастку CertSrv.msc является новой возможностью в Windows Server 2008. В связи с этим необходимость в Enrollment Web Pages отпала совсем.

По своим возможностям Standalone CA выглядит убогим чуть более, чем полностью. Но этот тип CA имеет одно сильное преимущество — он не зависит от наличия домена. Кажется — фигня. Домены даже рулят и педалят и всё, что работает без домена не нужно! Но давайте посмотрим на ситуацию немного с другой стороны. Центры сертификации верхних уровней (корневые и подчинённые центры сертификации первого уровня) имеют как правило очень большой срок действия — от 10 до 20 лет. При этом очень часто домены и леса AD живут значительно меньше, поскольку они постоянно реструктуирутся, переименовываются, мигрируются и т.д. А центр сертификации в домене (Enteprprise CA) лишает нас некоторых возможностей, как переименование домена и усложняют процессы реструктуризации доменов и лесов. По этой причине, Enterprise CA имеет небольшой срок действия своих сертификатов — от 5 до 10 лет максимум. В принципе, если есть независимый от домена AD центр сертификации (Standalone CA в рабочей группе) гораздо проще проводить миграцию и реструризацию лесов AD, поскольку эти процессы не затрагивают корневой CA и избавляют от проблем построения новой иерархии PKI. В такой ситуации достаточно только сменить центры сертификации 2-го и 3-го уровней (последний обычно является Enterprise CA). Именно по этой причине корневые центры сертификаций целесообразно устанавливать вне домена, в рабочей группе.

• Enterprise

Центр сертификации уровня предприятия (как это следует из названия) совершенно не похож на Standalone CA по своим возможностям. Во-первых Enterprise CA требует наличия домена для хранения там своей информации и шаблонов сертификатов. Данный тип CA имеет очень большие возможности по выдаче и обслуживанию сертификатов. Enterprise CA не требует генерации файлов запросов со стороны клиентов, а позволяет подавать заявки на сертификаты через оснастку Certificates консоли MMC и автоматически распространять сертификаты в масштабах целого леса AD при минимальном участии конечного пользователя. Чаще всего это участие сводится к настройке администратором политик autoenrollment'а и всё. Плюс, Enterprise CA может публиковать сертификаты в свойства учётных записей пользователей и компьютеров.

Однако, зависимость от домена вносит некоторые ограничения в свою жизнь. Поскольку домены достаточно подвижные единицы и подвержены изменениям, Enterprise CA имеют достаточно короткий срок действия своих сертификатов — от 5 до 10 лет максимум. В случае Enterprise Root CA, удаление домена автоматически ведёт к краху всей иерархии PKI и её придётся строить с нуля, что может вылиться в большие трудности в довесок к текущим проблемам удаления домена. Именно поэтому компании никогда не устанавливают корневой центр сертификации на Enterprise CA, а только Issuing CA, которые уже издают сертификаты конечным потребителям, где и восстребованы все возможности Enterprise CA. Хотя, в очень небольших компаниях этого будет вполне достаточно, когда корневой CA устанавливается на Enterprise CA и имеет срок действия сертификата 5 лет.

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

Planning validity periods

На какой срок будем выдавать сертификаты для каждого типа CA? 20 лет мне кажется слишком круто, ведь через 20 лет в вашей компании может всё круто поменяться и если ваш бизнес не завязан на предоставлении услуг цифровых сертификатов, 20 лет, наверное, слишком большой срок. А вот 10 лет для корневого и издающего будет вполне достаточно. Не надо думать, что через 10 лет всё умрёт. Просто через 10 лет (фактически чуть раньше, через 8-9 лет) вам придётся обновить сертификаты обоих CA и всё, жизнь будет продолжаться дальше. Издержки на обновлении сертификатов CA минимальные, поскольку никаких изменений в конфигурации производить не придётся.

Planning CDP/AIA extensions

Об этом у меня написано уже достаточно много:

• CRL Distribution Points и Authority Information Access
• Certificate chaining engine (CCE) и отзыв корневых сертификатов
• Планирование расширений CDP и AIA

Исходя из описанного по ссылкам (читать обязательно!) мы полностью откажемся от LDAP-ссылок и в сертификатах будем публиковать только ссылки на HTTP. Для этой цели нам потребуется веб-сервер, который будет хранить наши CRL/CRT файлы и поддерживать работоспособность ссылок. Поскольку корневой CA не будет издавать сертификаты конечным потребителям, а только для других CA, риск компрометации которых невелик (но всё же существует) и он большую часть времени будет выключен, мы отключим публикацию Delta CRL для корневого CA, но включим для Issuing CA. Основной CRL (Base CRL) мы будем публиковать каждые 3 месяца для корневого сертификата и каждые 5 дней для Issuing CA. Для обеспечения более быстрой реакции на отзыв сертификатов, для Issuing CA будем публиковать Delta CRL каждые 12 часов.

Так же можно предусмотреть использование OCSP (Online Certificate Status Protocol). Хоть обычно OCSP и используется только для Enterprise CA, ничего не мешает использовать его для корневого CA. С учётом роста количества клиентов под управлением Windows Vista и выше, это будет хороший экспериенс и я расскажу, как это можно будет реализовать.

Conclusion

Исходя из вышесказанного мы можем сформулировать программные требования для нашей иерархии PKI:

1. Windows Server 2008/2008 R2 Standard Edition.
   Компьютер является членом рабочей группы WORKGROUP, с именем хоста RootCA. Компьютер не подключен к локальной сети или к интернетам. В принципе, для это задачи можно использовать и Enterprise/Datacenter редакции, но от них вы никакого профита не получите в случае использования роли ADCS (Active Directory Certificate Services). Редакции Standard хватит вполне.
2. Windows Server 2008 Enterprise/Datacenter или Windows Server 2008 R2 Standard/Enterprise/Datacenter.
   Компьютер является членом домена Adatum.com с именем хоста Issuing CA. Компьютер не должен держать роль контроллера домена.
3. Домен Adatum.com содержит выделенный веб-сервер под управлением любой ОС и который доступен из интернета (только для обслуживания внешних клиентов).
4. Домен Adatum.com содержит сервер способный выполнять роль OCSP Responder'а. Если это будет Windows Server, требования к версии будут такие же, как и для Enterprise CA. Т.е. Windows Server 2008 R2 Standard/Enterprise/Datacenter или Windows Server 2008 Enterprise/Datacenter.

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

Примечание: для успешного освоения данного материала, необходимо прочитать мою предыдущую запись по теме: Встречаем – AppLocker!

Я в своё время написал пост о порядке сортировки правил в Software Restriction Policies (Секреты Software Restriction Policies (часть 4)). Некоторые вопросы в интернетах говорят мне о том, что с AppLocker'ом люди не особо разобрались и сильно путаются. Виной тому — полное отсутствие вменяемой документации по вопросам практической реализации и отсутствие серого вещества у некоторых администраторов. Сегодня я покажу как AppLocker выявляет результирующий статус для запускаемого приложения/скрипта.

В Software Restriction Policies правила достаточно простые, хотя и со своими тараканами. Например, у нас есть возможность использовать один из двух уровней по умолчанию — Disallowed и Unrestricted. Правила в SRP так же могут быть определены одним из двух уровней (на самом деле в SRP ещё есть Basic User, но я его опускаю, как незначительный момент). Т.е. правило либо однозначно запрещает, либо однозначно разрешает вне зависимости от уровня по умолчанию. А результирующий уровень определялся нехитрым методом сортировок правил.

С AppLocker'ом ситуация немного иная. Теперь уровень по умолчанию только Disallowed. Т.е. запрещено всё, что не разрешено. Вроде бы и просто, но сами правила стали немного сложнее — появились исключения. В результате этих исключений значительно усложнилась и изменилась методика определения результирующего уровня для запускаемого файла.

Примечание: под «файлом» я здесь подразумеваю файл с расширением, контролируемым в AppLocker'е.

Итак, AppLocker позволяет создавать правила с уровнем Deny или Allow. Каждое правило пути или издателя (Publisher), кроме правила хешей, могут содержать исключения. Поскольку правило издателя не может уникально идентифицировать конкретный файл, т.к. поле Subject сертификата достаточно абстрактное понятие и под одно такое правило может подпадать сотни различных файлов. Причём, ситуация усугубляется тем, что в Software Restriction Policies в правило сертификата указывался конкретный сертификат подписи, AppLocker их просто перестаёт различать! Т.е. область действия правила издателя становится ещё шире, чем с классическими правилами сертификатов в SRP. То же самое и с правилами пути, поскольку по указанному пути сегодня может быть один файл, а завтра уже другой. Но для AppLocker'а это будет всё один файл. А ещё могут быть ситуации, когда по некоторому пути нужно разрешить всё, кроме какого-то набора файлов. Недостатки (и достоинства одновременно) компенсируются наличием в правилах исключений. Исключения позволяют значительно сократить количество правил в AppLocker'е.

Примечание: Единственный способ уникальной идентификации файла в AppLocker'е (равно как и в SRP) может быть только правило хеша, поскольку хеш условно говоря уникально идентифицирует файл (в пределах коллизий хеша). Именно по этой причине правило хеша не поддерживает возможность использования исключений.

Основной сценарий, который многих сбивает с толку: создаём запрещающее правило по правилу издателя или правилу пути. Однако определённые файлы, подпадающие под этот запрет должны быть разрешены для запуска. Для этих целей мы можем смело воспользоваться исключениями. Поэтому мы вносим такие файлы в исключения по пути, хешу или издателю. И, казалось бы, исключение из запрета означает явное разрешение. На первый взгляд это так и есть. Однако, следует помнить, что AppLocker использует неотключаемое действие по умолчанию — Disallowed. И когда файл выпадает из явного запрета, он не разрешается автоматически, поскольку подпадает под действие по умолчанию, если нет явного разрешения. Вот такие пирожки. Следовательно, можно вывести общий постулат AppLocker'а: разрешённый файл не должен быть явно запрещён и должен быть явно разрешён. Этот постулат будет доказан и продемонстрирован чуть ниже.

Если SRP использовал сортировку правил по их типу, устанавливая заданный приоритет для каждого вида, AppLocker более не использует такой метод. Запрет по правилу пути не может быть перекрыт даже разрешением по хешу или правилу издателя, как это работает в SRP. AppLocker сортирует правила по их действию — Deny и Allow. Запреты отрабатываются в первую очередь и затем разрешения. Опираясь на мои исследования я составил примерно такой алгоритм работы правил аплокера:

• Сначала проверяются все явные запреты (в произвольном порядке).
  • Если файл подпал под явный запрет, то для этого запрета отрабатываются все исключения. Если файл всё ещё подпадает под явный запрет, то файл помещается в список «Denied» и блокируется для запуска. Остальные шаги проверки не производятся.
  • Если после обработки исключений больше не подпадает под явный запрет, то берётся следующее запрещающее правило и так продолжается, пока не будут проверены все явные запреты.
  • Если после отработки всех запретов, файл больше не подпадает под явный запрет, он помещается в список «Processing».
• Если файл находится в списке «Processing», файл проходит через второй этап проверки. Если список «Processing» пуст, файл не проходит через второй этап и хмуро блокируется для запуска.
• Если файл подпал под явное разрешение, то для этого разрешения отрабатываются все исключения. Если файл всё ещё подпадает под разрешение, файл помещается в список «Allowed» и разрешается для запуска. Остальные шаги проверки не производятся.
• Если после обработки исключений файл больше не подпадает под явное разрешение, то берётся следующее разрешающее правило, и процесс повторяется для каждого разрешающего правила.
• Если после отработки всех разрешений, файл всё ещё находится в списке «Processing», к файлу применяется действие по умолчанию. Т.е. файл блокируется для запуска.

Примечание: на самом деле никаких таких списков не существует, это я всё соврал. Я их придумал только для улучшения понимания.

Для наглядной демонстрации алгоритма я нарисовал следующую картинку:

Ну и в качестве бонуса — практическая задача, которая продемонстрирует этот алгоритм в действии.

Задача:

На компьютере в каталог по умолчанию установлен пакет Microsoft Office, которым можно пользоваться всем. Но группе «Accountants» необходимо разрешить запускать только программы Word и Excel. Запуск остальных файлов из «Program Files» разрешён без ограничений.

Решение:

Для решения этой задачи мы должны разрешить весь каталог «Program Files» по правилу пути для группы «Everyone». Поскольку доступ к программам Microsoft Office будет ограничен только для группы «Accountants», мы создаём новое запрещающее правило (с действием «Deny»), которое применяется только к группе «Accountants». Теперь программы из пакета Microsoft Office будут разрешены для запуска всем, кроме группы «Accountants». Чтобы обеспечить запуск только необходимых приложений из этой папки, мы редактируем запрещающее правило и добавляем два исключения (по правилу пути, хеша или издателя) для файлов «Excel.exe» и «Winword.exe».

Проверка:

Исходя из диаграммы, посмотрим, что будет происходить, когда член группы Accountants запустит PowerPNT.exe (PowerPoint).

При запуске мы попадаем на первый условный переход: подпадает ли файл под какой-нибудь запрет? Да, у нас есть запрет на папку %programfiles%\Microsoft Office. Следовательно выходим на следующий условный переход: указан ли PowerPNT.exe в исключениях? Правило запрета не предусматривает исключения для этого файла, следовательно мы выходим на действие «File is blocked to run». При этом алгоритм заканчивается.

А теперь член группы Accountants запускает Excel.exe (Excel). При запуске мы снова попадаем на первый условный переход: подпадает ли файл под запрет? Да, у нас есть запрет на папку %programfiles%\Microsoft Office. Следовательно переходим на следующий условный переход: указан ли Excel.exe в исключениях данного правила? Да, указан в исключениях, поэтому переходим на третий условный переход: есть ли ещё запрещающие правила? Если нет, мы сразу попадаем на четвёртый условный переход, который уже отрабатывает разрешения. Если есть ещё запрещающие правила, в них Excel.exe никак не запрещается (по условию задачи это не подразумевается), мы прямиком с первого условного перехода попадаем на четвёртый условный переход: подпадает ли файл хоть под одно разрешающее правило? Да, файл подпадает под разрешающее правило всего каталога Program Files для группы Everyone, в которую входит и группа Accountants. В результате попадаем на пятый условный переход: есть ли исключение для Excel.exe в этом разрешающем правиле? Нет, исключений для правила не предусмотрено и мы выходим на действие «File is allowed to run».

Как видите, используя эту диаграмму, можно разбирать правила любой сложности в пошаговом режиме и теперь вы знаете, как сортируются и проверяются правила AppLocker'а.

Напоследок ещё хочется отметить ситуацию применения множественных политик. Так же как и в случае с Software Restriction Policies, правила никак не замещаются, а суммируются. Т.е. собираются в один список, после чего AppLocker оперирует правилами, собранных со всех политик, применённых к конкретному компьютеру.

Что бы почитать?

• Встречаем – AppLocker!
• Секреты Software Restriction Policies (часть 4)

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

Примечание: перед проведением любых изменений, описываемых в этом посте, обязательно выполните бэкап.

Большинство администраторов при установки роли Active Directory Certificate Services (AD CS) делают очень просто Next –> Next –> ????? –> PROFIT. С одной стороны это и хорошо, но часто это не очень хорошо. Чем это хорошо — оно будет работать. Чем это плохо — при появлении каких-то специфических условий (например, внешние по отношению к текущему лесу клиенты) оно начинает работать хуже и даже перестаёт быть работоспособным. Сегодня я планирую рассмотреть эти вопросы, как нестанадртные клиенты (не поддерживающие LDAP) и внешние клиенты, тем более это достаточно распространённый сценарий.

Рекомендация 1 — CA и IIS

Самая первая рекомендация будет заключаться в том, что не надо устанавливать службу IIS на сервер CA (кроме случаев, когда у вас в сети всего один сервер). При установке роли AD CS мастер предлагает установить IIS для работы HTTP ссылок на CRT и CRL файлы. Я считаю, что при наличии внутреннего и/или внешнего веб-сервера устанавливать ещё один на сервер CA — затея глупая. Вы этим самым просто добавляете себе лишней работы и не решаете некоторых задач. Установка новой роли увеличивает площадь атаки для злоумышленников, отнимает время администраторов, повышает расходы на организацию защиты IIS и не решает вопрос обслуживания внешних клиентов, поскольку публикация сервера CA в интернет (хоть и только роли IIS. При успешной атаке роли можно получить контроль над всем сервером) идея настолько глупая и неудачная, что её рассматривать нет никакого желания. Я вообще считаю, что на сервере CA кроме роли CA ничего быть не должно. Поэтому при установке роли CA благоразумно отказываемся. Взамен этого мы будем использовать выделенный веб-сервер, который скорее всего установлен в вашей компании. При этом он может работать под управлением любой ОС, хоть линупса. Об этом будет написано чуть ниже.

Рекомендация 2 — CDP/AIA и LDAP

Мы уже рассматривали общую проблематику вопроса в одном из предыдущих постов: CRL Distribution Points и Authority Information Access. По причинам описанным в указанном посте мы хмуро выпиливаем все ссылки на LDAP.

• Необходимые шаги для случаев свежей инсталляции роли CA производимые ДО выпуска первого сертификата.

Для этого запустите оснастку CertSrv.msc, выберите свойства CA и перейдите на вкладку Extensions. В этой вкладке выделите ссылку, начинающуюся с LDAP://{тут_много_букв} и HTTP://{тут_много_букв} и нажмите кнопку Remove. Далее в выпадающем поле со списком выберите Authority Information Access (AIA), выделите ссылку, начинающуюся с LDAP://{тут_много_букв} и HTTP://{тут_много_букв} и нажмите кнопку Remove.

Этим шагом мы отменим использование LDAP ссылок, которые могут быть совершенно не пригодны для ряда типов клиентов, как мобильные клиенты, клиенты из интернета, клиенты рабочих групп, других лесов и т.д. А так же удалили дефолтные HTTP ссылки, которые указывают на сервер CA.

• Необходимые шаги для случаев, когда сервер CA уже выпустил сертификаты.

Для этого запустите оснастку CertSrv.msc, выберите свойства CA и перейдите на вкладку Extensions. В этой вкладке выделите ссылку, начинающуюся с LDAP://{тут_много_букв}. Снимите все галочки, кроме Publish CRLs to this location и Publish Delta CRLs to this location (если вы планируете использовать Delta CRL). А так же удалите ссылки HTTP, которые указывают на сам сервер CA. Сохраните изменения и перезапустите службу Certificate Services.

Этим шагом мы отключили публикацию LDAP и HTTP ссылок во вновь издаваемые сертификаты. Однако, у нас уже работающая инфраструктура PKI, следовательно, ранее выпущенные сертификаты содержат ссылки на LDAP. Для обеспечения их работоспособности мы продолжаем публикацию CRT/CRL файлов в LDAP.

Отсебятина 1 — именование файлов

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

<ServerDNSName>_<CAName><CertificateName>.crt

Т.е. обычно это выглядит так: caserver.company.com_companyca.crt. Скажем, не всем нравится такой формат, поскольку имя файла достаточно длинное и раскрывает внутреннее имя сервера, на котором хостится служба CA. Лично мне нравится другой формат имён файлов — короткое имя компании и аббревиатурное значение роли конкретного сервера CA. Например: company_RCA.crt. Мне кажется, что это хороший выбор. Однако, ни стандартный интерфейс CertSrv.msc, ни реестр не предоставляют возможности изменять имя и путь публикации CRT файла. Учитывая, что сертификаты самих CA обновляются достаточно редко, эту операцию можно выполнить вручную или при помощи скрипта — это уже на ваш выбор. Так что с CRT ничего не остаётся как копировать его вручную на веб-сервер или гонять его по DFS и переименовывать самостоятельно. Однако, следует учесть, что если сертификат CA обновлялся с новой ключевой парой, в конце имени файла добавляется число в круглых скобках. Например: server.domain.com_CAName(1).crt. Вот эта циферка приходит из <CertificateName>. Именно поэтому когда вы будете имзенять ссылку (об этом чуть ниже), которая будет публиковаться в издаваемых сертификатах, не забудьте к имени файла добавить <CertificateName>.

То же самое будет касаться и CRL. В соответствии с параграфом § 3.2.5.1.6 спецификации протокола [MS-CSRA]:

1.When this method is invoked, the CA SHOULD create a new base and/or delta CRL for each CA key, as specified in the following steps 2, 3, 4, 5, 6, and 7. The type of CRL to create (base, delta, or both) for each CA key is determined as follows:<38>

The CA SHOULD create a new base CRL for each CA key.

If the CA has enabled delta CRLs, as indicated by a nonzero Config_Delta_CRL_Validity_Period value, the CA MUST create a new delta CRL in addition to a new base CRL, for each CA key.

If delta CRLs are currently disabled (Config_Delta_CRL_Validity_Period is 0) and were enabled previously (Previous_Delta_CRL_Validity_Period is not equal to zero), the CA MUST create a new delta CRL in addition to a new base CRL for each CA key.

отдельный CRL создаётся для каждой ключевой пары CA. Следовательно, в имени CRL файлов следует оставить значение <CRLNameSuffix>. Этим самым сервер CA при публикации CRL на это место установит версию сертификата, для которого публикуется CRL. Например: CAName(1).crl и CAName(1)+.crl (для Base и Delta CRL). Если сертификат CA ещё не обновлялся, <CRLNameSuffix> будет заменён на пустое значение.

Рекомендация 3 — публикация файлов на Web-сервер

• Prerequisites

На веб-сервере создайте папку с произвольным именем (например, с именем pki), в которой будут храниться наши файлы. Расшарьте эту папку и добавьте в неё права записи для учётной записи компьютера, на котором работает сервер CA. При этом учтите, что права необходимо отредактировать как на уровне NTFS Rights и Share Permissions. В принципе, права Create files/Write data вполне достаточно для данной задачи. В IIS в произвольном веб-узле создайте виртуальную директорию и в качестве пути к ней укажите папку, в которой хранятся CRT/CRL файлы.

• CDP

Поскольку мы будем публиковать файлы на выделенный веб-сервер, мы должны отредактировать расширения соответствующим образом. Запустите оснастку CertSrv.msc, выберите свойства CA и перейдите на вкладку Extensions. Нажмите кнопку Add и в поле Location укажите путь вида:

file://\\WebServerName\pki\MyCRLNewName<CRLNameSuffix><DeltaCRLAllowed>.crl

Я выделил обязательную составляющую имени CRL файла. Остальное уже на ваш вкус. И установите чек-боксы на Publish CRLs to this location и Publish Delta CRLs to this location (если вы планируете использовать Delta CRL). Если Delta CRL на сервере CA использоваться не будет, <DeltaCRLAllowed> можно убрать совсем.

Теперь надо добавить ссылку, которая будет публиковаться в издаваемые сертификаты. Для этого добавьте новую ссылку HTTP, которая будет указывать на веб-сервер, например:

http://www.company.com/pki/MyCRLNewName<CRLNameSuffix><DeltaCRLAllowed>.crl

И проставьте галочки: Include in the CDP extensions of issued certificates и Include in CRLS. Clients use this to find Delta CRL Locations (если используется Delta CRL).

• AIA

То же самое сделать для расширения AIA, чтобы получить ссылку вида:

http://www.company.com/pki/MyCRTNewName<CertificateName>.crt

И поставить галочку напротив Include in the AIA extension of issued certificates. Как я уже говорил, не представляется возможным автоматически публиковать CRT в нестандартные локации, поэтому их придётся переименовать вручную.

Примечание: имена физических файлов должны быть идентичными имени в HTTP ссылке.

В принципе, в конечном итоге вы должны получить примерно такой вид ссылок и установленных галочек:

CDP — новая инсталляция

C:\WINDOWS\system32\CertSrv\CertEnroll\<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl
Publish CRLs to this location
Publish Delta CRLs to this location

file://\\WebServerName\pki\Company_RCA<CRLNameSuffix><DeltaCRLAllowed>.crl
Publish CRLs to this location
Publish Delta CRLs to this location

http://www.company.com/pki/Company_RCA<CRLNameSuffix><DeltaCRLAllowed>.crl
Include in the CDP extensions of issued certificates
Include in CRLS. Clients use this to find Delta CRL Locations

CDP — унаследованная инсталляция

C:\WINDOWS\system32\CertSrv\CertEnroll\<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl
Publish CRLs to this location
Publish Delta CRLs to this location

Примечание: не следует удалять этот путь, поскольку он используется самим сервером CA.

file://\\WebServerName\pki\Company_RCA<CRLNameSuffix><DeltaCRLAllowed>.crl
Publish CRLs to this location
Publish Delta CRLs to this location

ldap:///CN=<CATruncatedName><CRLNameSuffix>, CN=<ServerShortName>, CN=CDP,CN=Public Key Services, CN=Services, <ConfigurationContainer><CAObjectClass>
Publish CRLs to this location
Publish Delta CRLs to this location

http://www.company.com/pki/Company_RCA<CRLNameSuffix><DeltaCRLAllowed>.crl
Include in the CDP extensions of issued certificates
Include in CRLS. Clients use this to find Delta CRL Locations

AIA — новая и унаследованная инсталляции

C:\WINDOWS\system32\CertSrv\CertEnroll\<ServerDNSName>_<CAName><CertificateName>.crt
нет галочек. Остаётся без изменений.

http://www.company.com/pki/Company_RCA<CertificateName>.crt
Include in the AIA extension of issued certificates

Я не призываю сразу бросаться и всё переделывать. Эти рекомендации даны только для понимания сути проблемы и каким образом её можно решить. С их помощью при необходимости можно самостоятельно подготовить план изменения расширений CDP и AIA.

Что-то в последнее время участились вопросы связанные с проблемами Web Enrollment Pages. В этом посте я рассмотрю 3 момента:

1. Запрос сертификатов для компьютера (с установкой сертификата в хранилище LocalMachine);
2. Запрос сертификатов от имени другого пользователя (Enroll On Behalf Of);
3. Настройка Web Enrollment Pages при работе на отдельном от CA сервере.

История Web Enrollment Pages

В системах до Windows Vista/Server 2008 клиентская часть запроса сертификатов была уныла чуть более чем полностью. Из того, что вы могли делать:

• запрашивать сертификаты только тех шаблонов, где Subject строился автоматически на основе данных в Active Directory учётной записи, от имени которой происходил запрос;
• Если в шаблоне разрешено использовать несколько CSP (Cryptographic Service Provider), можно было выбирать тот, который нужен для конкретного сертификата или который вам просто больше нравится;
• Изменять длину ключа;
• Включать/выключать возможность экспорта сертификата вместе с закрытым ключом (в PKCS#12);
• Включать/выключать функцю Private Key Strong Protection (только для пользовательских сертификатов).

Если хотите использовать шаблон, Subject которого должен указываться в запросе (обычно используется для недоменных клиентов или клиентов других лесов Active Directory) или что-то ещё, вам было необходимо решать данный вопрос иными путями. Например, использовать текстовый файл настроек policy.inf совместно с утилитой CertReq.exe, или Web Enrollment Pages. Web Enrollment Pages был неотъемлемой частью компонента Certification Authority. При установке Web Enrollment Pages устанавливалась роль IIS (в реальности, чаще приходилось его устанавливать заранее, чтобы потом не настраивать его вручную) и в систему копировался набор ASP файлов и элемент ActiveX под названием Xenroll. Этот ActiveX является «прослойкой» между клиентом и сервером и отвечал за cookies и много чего ещё. В этих cookies сохраняется некоторая служебная информация, например, номер запроса, который был отправлен на сервер CA и по которому вы потом могли получить сертификат.

И используя Web Enrollment Pages вы могли запрашивать сертификаты для недоменных компьютеров (или клиентов других лесов Active Directory):

У нас там есть поля, которые позволяют вручную указать информацию о владельце сертификата. И галочка, которая указывала, что сертификат будет установлен в компьютерное хранилище. Для выпуска сертификатов для смарт-карт мы могли использовать галочку Enroll On Behalf Of с указанием пользователей для которых предназначен сертификат для смарт-карт.

Так же, как и с консолью MMC, вы не могли переопределять какие-то вещи, например, экспорт закрытого ключа, если это не разрешено в шаблоне и другое. Вобщем, как альтернатива, Web Enrollment Pages была весьма полезная и зачастую нужная вещь.

С выходом Windows Vista и Windows Server 2008 ситуация круто изменилась и началась всеобщая шумиха (она ещё до сих пор не утихает), что это всё перестало работать. В связи с некоторыми проблемами безопасности (любой запрос сертификата выполнялся в контексте пользователя, который аутентифицировался в IIS) и изменением функциональности консоли MMC, некоторые вещи были удалены с Web Enrollment Pages и изменён элемент Activex, который теперь называется CertEnroll. В новой консоли MMC (оснастка Certificates) вы можете выполнять абсолютно любые запросы. В том числе в клиенте реализована возможность ручного указания поля Subject и многих других полей (добавлять Application Policies, управлять экспортом закрытого ключа, его длиной, CSP и многое другое), а так же реализована возможность запрашивать сертификаты для смарт-карт от имени другой учётной записи (Enroll On Behalf Of).

По указанным причинам даже необходимость в Web Enrollment Pages скатилась до отвратительно низкой отметки. Но жадные детипользователи продолжают негодовать: верните всё как было! Я не могу с ними согласиться, поскольку дублировать реализованный функционал совсем не обязательно, а повышение в безопасности лишним не будет. Просто случилась миграция необходимого функционала с серверной части (Web Enrollment Pages) в клиентскую (Certificates snap-in).

Дополнительная информация по проблеме находится здесь: http://support.microsoft.com/kb/922706

Web Enrollment Pages и сервер CA на раздельных компьютерах

Эта проблема появилась начиная с выходом Windows Server 2008, когда этот компонент стал необязательным при установке роли Certification Authority и появилась возможность установить его не на сервере CA. Чаще на выделенном веб-сервере для обслуживания внешних клиентов.

При установке компонента на Web Enrollment Pages вы указываете сервер CA, с которым они будут работать и устанавливаете необходимые компоненты IIS для этого. Однако, сразу это не будет работать. Если быть точнее, то будет, но криво. Итак, какие вещи нужно настроить для такой конфигурации:

• Включить SSL для веб-сайта, в котором будут размещены Web Enrollment Pages:
  • Для IIS 7 и IIS 7.5: How to Setup SSL on IIS 7.0
• Отключить анонимную и ядерную (kernel) аутентификацию и включить только Integrated Authentication:
• Для IIS 7 и IIS 7.5: Configure Windows Authentication (IIS 7)
• Настроить делегирование для учётной записи, от имени которой работает пул, в котором работает веб-сайт с Enrollment Web Pages, как это описано здесь: Install Web Enrollment Support on Another Computer (Optional)

Надеюсь это будет полезным.