Остальные материалы цикла:
В предыдущей части мы поговорили о процессе и методах ассоциации сертификата с учётной записью пользователя в Active Directory. Сегодня мы поговорим уже про сами сертификаты, каким требованиям они должны удовлетворять и всё такое. Я пообещал, что в этой части мы приобщимся к практике. Но я передумал и мы снова займёмся теорией :-)
Необходимый набор сертификатов
Поскольку у нас разговор идёт об аутентификации при помощи цифровых сертификатов, они нам обязательно потребуются. Для различных сетевых протоколов и методов аутентификации нам потребуется различный набор сертификатов. Итак:
Интерактивный логон при помощи смарт-карты
Для поддержки интерактивного логона при помощи смарт-карты, нам потребуется как минимум 2 вида сертификатов: клиентский сертификат, который записан на смарт-карте и сертификат контроллера домена. Каким условиям должен удовлетворять клиентский сертификат?
- Должен быть выдан доверенным (как клиентом, так и контроллером домена) центром сертификации;
- Должен быть действителен по времени;
- Поле Subject — не имеет значения. Может быть пустым;
- Расширение Enhanced Key Usage (EKU) должно содержать Smart Card Logon (1.3.6.1.4.1.311.20.2.2) и/или Client Authentication (1.3.6.1.5.5.7.3.2). Smart Card Logon обязателен для Windows XP и Windows Server 2003. В Windows Vista для логона смарт-картой можно использовать только Client Authentication. Но я буду советовать использовать оба;
- Расширение Key Usage должно содержать Digital Signature (0x80);
- Расширение Subject Alternative Name (SAN) должно содержать User Principal Name (UPN) пользователя. Если для каких-то целей этих UPN'ов прописано несколько, UPN для логона должен быть первым в списке.
Примечание: хоть мы и говорили, что расширение SAN в клиентском сертификате вовсе не обязательно и можно использовать различные формы explicit mapping, вы должны при любой возможности использовать implicit certifiate mapping по UPN и использовать explicit только когда другого выхода нет.
Windows CA предлагает нам 2 шаблона по умолчанию, которые годятся для этих целей: Smart Card Logon и Smart Card User. Единственное отличие этих шаблонов — Smart Card User содержит ещё EKU Secure Email (1.3.6.1.5.5.7.3.4). Вам следует использовать только шаблон Smart Card Logon или производный из него. Дело в том, что не рекомендуется объединять сертификаты, которые используются для логона (или цифровой подписи) с сертификатами, которые используются для шифровния.
Сертификат контроллера домена (KDC) должен удовлетворять следующим требованиям:
- Должен быть выдан доверенным (как клиентом, так и контроллером домена) центром сертификации;
- Должен быть действителен по времени;
- Поле Subject — не имеет значения;
- Расширение Enhanced Key Usage (EKU) должно содержать как минимум Server Authentication (1.3.6.1.5.5.7.3.1) и Client Authentication (1.3.6.1.5.5.7.3.2). Желательно в EKU включить Smart Card Logon (1.3.6.1.4.1.311.20.2.2), чтобы обозначить, что данный сертификат будет использоваться для аутентификации клиента по смарт-карте. Для того, чтобы обеспечить поддержку строгой проверки сертификата для KDC, в EKU необходимо включить KDC Authentication (1.3.6.1.5.2.3.5);
- Расширение Key Usage должно содержать Digital Signature и Key Encipherment (0xa0);
- Расширение Subject Alternative Name (SAN) должно содержать как минимум FQDN контроллера домена. А в идеале, ещё и FQDN и NetBIOS имена рассматриваемого домена.
Windows CA предлагает нам 3 шаблона по умолчанию, которые годятся для этих целей: Domain Controller, Domain Controller Authentication и Kerberos Authentication. Если у вас в домене есть контроллеры под управлением Windows Server 2003, следует использовать Domain Controller Authentication. Если у вас в домене все контроллеры под управлением Windows Server 2008 и выше, следует использовать шаблон Kerberos Authentication.
Примечание: для доменов с контроллерами на основе Windows Server 2003 можно использовать и шаблон Kerberos Authentication. Но контроллеры не извлекут таких профитов, как strong KDC validation. Так же, возможно появление следующей ошибки: Automatic certificate enrollment for local system detected the DNS name in the Kerberos Authentication certificate does not match the DNS name of the local computer. A new enrollment for one Kerberos Authentication certificate will be performed in 24 hours. Это известная проблема, поэтому для таких доменов лучше использовать шаблон Domain Controller Authentication.
В чём заключается суть аутентификации KDC? Если доменная машина выполняет аутентификацию с использованием PKINIT, клиентский компьютер убеждается, что удалённый хост не только имеет серверный сертификат и его имя соответствует имени в сертификате, но и является именно контроллером домена или сервером KDC, который является авторитарным для рассматриваемого домена. В процессе аутентификации, клиентский компьютер не имеет нотариально заверенногодостоверного списка контроллеров в домене. И наличие EKU = KDC Authentication и FQDN + NetBIOS имён домена в расширении SAN гарантированно идентифицирует хост как контроллер для домена, указанного в расширении SAN.
Логон на веб-странице
Для использования клиентских сертификатов для аутентификации пользователя на веб-сайте, веб-сайт должен быть сконфигурирован на использование SSL (это обязательное требование). Сертификат веб-сервера (сертификат SSL) должен отвечать следующим требованиям:
- Должен быть выдан доверенным (клиентом и сервером) центром сертификации;
- Должен быть действителен по времени;
- Поле Subject — имя сервера, которое клиент вводит в адресной строке веб-браузера;
- Расширение Enhanced Key Usage (EKU) должно содержать Server Authentication (1.3.6.1.5.5.7.3.1);
- Расширение Key Usage должно содержать Digital Signature и Key Encipherment (0xa0);
- Опционально, расширение Subject Alternative Name (SAN) может содержать дополнительные имена, которые могут использоваться для доступа к серверу. Если расширение SAN представлено в сертификате и поле Subject не пустое, SAN должен включать себя и имя из поля Subject. Подробнее здесь: Как правильно задавать имя сертификата при использовании расширения Subject Alternative Name (SAN).
Windows CA предлагает по умолчанию один шаблон, который годится для этой цели: Web Server.
Если вы не используете смарт-карту для аутентификации пользователя, сертификат для контроллера домена и смарт-карты (как описано в предыдущем параграфе). В противном случае (клиентский сертификат просто установлен в пользовательском хранилище сертификатов на клиенте), вам потребуется сертификат, отвечающий следующим условиям:
- Должен быть выдан доверенным (клиентом и сервером) центром сертификации;
- Должен быть действителен по времени;
- Поле Subject — не имеет значения. Может быть пустым;
- Расширение Enhanced Key Usage (EKU) должно содержать Client Authentication (1.3.6.1.5.5.7.3.2);
- Расширение Key Usage должно содержать Digital Signature (0x80);
- Расширение Subject Alternative Name (SAN) должно содержать User Principal Name (UPN) пользователя. Если для каких-то целей этих UPN'ов прописано несколько, UPN для логона должен быть первым в списке.
Windows CA предлагает нам по умолчанию 2 шаблона, которые отвечают предъявленным требованиям: Authenticated Session и User. Вам следует использовать шаблон Authenticated Session или производный от него для создания клиентских сертификатов. Шаблон User дополнительно содержит EKU для Secure Email и EFS. Как я уже говорил, не следует комбинировать в одном сертификате EKU для цифровых подписей или логона с EKU для шифрования.
Логон на сервере VPN
В зависимости от типа VPN (L2TP, SSTP) вам потребуется различный набор сертификатов (для PPTP отдельный серверный сертификат не требуется). Клиентский сертификат для любых видов VPN должен отвечать требованиям, описанным в параграфе «Интерактивный логон при помощи смарт-карты» (если используется смарт-карта) или «Логон на веб-странице» (если не используется смарт-карта). Далее, вам потребуется сертификат для RADIUS сервера. Этот сертификат должен быть установлен на RADIUS сервере или на самом сервере VPN, если используется Integrated Authentication и который отвечает следующим требованиям:
- Должен быть выдан доверенным (клиентом и VPN сервером) центром сертификации;
- Должен быть действителен по времени;
- Поле Subject — FQDN сервера;
- Расширение Enhanced Key Usage (EKU) должно содержать Server Authentication (1.3.6.1.5.5.7.3.1) и Client Authentication (1.3.6.1.5.5.7.3.2);
- Расширение Key Usage должно содержать Digital Signature и Key Encipherment (0xa0);
- Расширение Subject Alternative Name (SAN) должно содержать FQDN сервера.
Windows CA предлагает по умолчанию шаблон RAS and IAS Servers, который удовлетворяет всем требованиям для RADIUS сервера.
Для L2TP вам ещё потребуются компьютерные сертификаты для обоюдной аутентификации узлов и которые отвечают следующим требованиям:
- Должен быть выдан доверенным (клиентом и сервером) центром сертификации. Причём, цепочки сертификатов обоих узлов должны заканчиваться одним и тем же сертификатом корневого CA;
- Должен быть действителен по времени;
- Поле Subject — имя сервера, которое клиент вводит при подключении к VPN серверу;
- Расширение Enhanced Key Usage (EKU) должно содержать IP security IKE intermediate (1.3.6.1.5.5.8.2.2);
- Расширение Key Usage должно содержать Digital Signature и Key Encipherment (0xa0);
- Опционально, расширение Subject Alternative Name (SAN) может содержать дополнительные имена, которые могут использоваться для доступа к серверу. Если расширение SAN представлено в сертификате и поле Subject не пустое, SAN должен включать себя и имя из поля Subject. Подробнее здесь: Как правильно задавать имя сертификата при использовании расширения Subject Alternative Name (SAN).
Windows CA по умолчанию предлагает два шаблона, которые годятся для аутентификации узлов в L2TP: IPsec и IPsec (Offline). Если один из узлов не является членом одного и того же леса Active Diretory, следует использовать IPsec (Offline), потому что этот шаблон позволяет указывать поле Subject и расширение Subject Alternative Names в запросе. Шаблон IPsec автоматически строит эту информацию из Active Directory.
Для SSTP VPN вам потребуется сертификат SSL, который отвечает тем же самым требованиям, что и сертификат SSL для веб-сервера (см. параграф «Логон на сервере VPN»).
Логон в 802.11x сетях (Wireless)
Для получения доступа в беспроводную 802.11x сеть, точка доступа (WAP) должна быть настроена на использование RADIUS сервера для аутентификации и авторизации клиента. RADIUS сервер должен иметь сертификат, как описано в параграфе «Логон на сервере VPN». Требования к пользовательскому сертификату описаны в параграфе «Интерактивный логон при помощи смарт-карты» (если используется смарт-карта) или в параграфе «Логон на веб-странице» (если используется сертификат, установленный в пользовательское хранилище сертификатов).
Сертификаты центров сертификаций
При использовании сертификатов для аутентификации пользователей вам необходимо, что сертификат центра сертификации, который выпускает логонные сертификаты для пользователей и контролллеров домена, опубликованы в хранилище NTAuthCertificates в Active Directory. Если вы используете свой собственный Windows Enterprise CA, никаких дополнительных действий не требуется. Если вы используете сторонний CA (внешний, или CA на базе линупса), сертификат CA необходимо вручную опубликовать в указанное храналище. Например, можно использовать certutil.exe:
certutil –dspublish –f CAcertfile.crt NTAuthCA
Альтернативно вы можете это сделать через оснастку PKI Health Tool:
- Войдите в систему с правами Enterprise Admins;
- Запустите оснастку PKI Helath Tool (Start –> Run... –> pkiview.msc);
- Выделите корневой узел (Enterprise PKI) и в контекстном меню выберите Manage AD Containers. Перейдите во вкладку NTAuthCertificates. Используйте кнопку Add для того, чтобы добавить туда сертификат издающего CA.
Эпилог
В принципе, на этом можно завершать теоретическую часть, потому что этих знаний уже достаточно, чтобы переходить к практике. В следующей части я покажу, как применить аутентификацию пользователей при помощи сертификатов на примере веб-сервера (IIS).
Что бы почитать?
- Что-нибудь почитайте, не сидите без дела :-)
Comments: