Настройка аутентификации с использованием смарт-карт
Эллес поддерживает аутентификацию в домене с использованием цифровых сертификатов и ключей, хранящихся на физических устройствах (смарт-картах).
Данный раздел содержит пример настройки работы со смарт-картами на клиентских машинах под управлением ОС Windows в домене с контроллером домена Эллес, развернутым на сервере под управление ОС Astra Linux, и удостоверяющим центром сертификации на основе OpenSSL.
Предварительные требования
Перед началом настройки ознакомьтесь с требованиями к сертификатам и ключам, которые будут использоваться для аутентификации, требованиями к домену, в который будет осуществляться вход с использованием сертификатов и ключей, а также требованиями к идентификаторам контроллера домена и пользователей.
Требования к ключам и сертификатам
Для успешной аутентификации пользователя на клиентской машине должна быть в наличии пара сертификат — закрытый ключ, которая, в том числе, может храниться и на смарт-карте.
Клиентская машина использует закрытый ключ для шифрования временной метки, а сертификат вместе с зашифрованной меткой отправляется на контроллер домена в запросе к KDC (AS-REQ) для проверки его действительности и извлечения открытого ключа пользователя, который используется для расшифровки временной метки.
На контроллере домена также должна быть установлена пара закрытый ключ — сертификат: закрытый ключ используется для подписания сессионного ключа и временной метки в ответе контроллера домена на запрос (AS-REP).
Общие требования к ключам и сертификатам
К ключам и сертификатам предъявляются следующие общие требования:
-
все сертификаты должны выпускаться одним и тем же удостоверяющим центром сертификации;
-
все сертификаты и ключи должны использовать одинаковый тип ключа (например, RSA 2048 бит) и одинаковый тип хеширования (например, SHA256RSA);
-
все сертификаты и ключи должны быть действительными (в рамках установленного для них периода действия).
Требования к ключам и сертификатам удостоверяющего центра
В Табл. 1 приводятся требования к ключам и сертификатам удостоверяющего центра.
| Требование | Пример |
|---|---|
В качестве данных субъекта (поле |
|
Если сертификат самоподписанный, то данные издателя (поле |
|
Базовые ограничения X509v3 ( |
|
Использования ключа X509v3 ( |
|
Точки распространения списков отзыва сертификатов X509v3 ( |
|
Тип сертификата Netscape ( |
|
Альтернативное имя субъекта X509v3 ( |
|
Требования к ключам и сертификатам пользователей
В Табл. 2 приводятся требования к ключам и сертификатам пользователей.
| Требование | Пример |
|---|---|
Данные издателя (поле |
|
Данные субъекта (поле |
|
Альтернативное имя субъекта X509v3 ( |
|
Базовые ограничения X509v3 ( |
|
Использование ключа X509v3 ( |
|
Расширенное использование ключа X509v3 ( |
|
Точки распространения списков отзыва сертификатов X509v3 ( |
|
Альтернативное имя издателя X509v3 ( |
|
Тип сертификата Netscape ( |
|
Адрес списка отзыва сертификатов Netscape ( |
|
Идентификатор ключа подлинности X509v3 ( |
|
Требования к ключам и сертификатам контроллеров домена
В Табл. 3 приводятся требования к ключам и сертификатам контроллеров домена.
| Требование | Пример |
|---|---|
Данные издателя (поле |
|
Данные субъекта (поле |
|
Альтернативное имя субъекта X509v3 ( |
|
Базовые ограничения X509v3 ( |
|
Использование ключа X509v3 ( |
|
Расширенное использование ключа X509v3 ( |
|
Точки распространения списков отзыва сертификатов X509v3 ( |
|
Альтернативное имя издателя X509v3 ( |
|
Тип сертификата Netscape ( |
|
Адрес списка отзыва сертификатов Netscape ( |
|
Идентификатор ключа подлинности X509v3 ( |
|
Требования к домену
Для успешного выполнения действий по настройке работы со смарт-картами, описываемых в данном разделе, должны быть выполнены следующие требования к конфигурации домена:
-
в домене развернут контроллер домена Эллес актуальной версии на сервере с ОС Astra Linux;
-
функциональный уровень домена и контроллера домена — 2016;
-
в домене развернут удостоверяющий центр сертификации, на котором установлена библиотека OpenSSL актуальной версии;
-
аутентификация с использованием смарт-карт выполняется на клиентских машинах под управлением ОС Windows.
На Рис. 1 представлена схема простейшего домена, удовлетворяющего перечисленным требованиям.
Требования к идентификаторам контроллера домена и пользователей
Аутентификация пользователей в домене по смарт-картам использует технологию Public Key Cryptography for Initial Authentication in Kerberos (PKINIT). Поэтому для генерации сертификатов требуются следующие идентификаторы:
-
в качестве идентификатора контроллера домена — значение атрибута
objectGUIDобъекта компьютера контроллера домена в шестнадцатеричном формате (например:85 42 0f cd 86 7f ca 40 be 8a cd a1 c9 87 87 62); -
в качестве идентификатора пользователя — значение атрибута
userPrincipalNameобъекта пользователя.Для пользователей, проходящих аутентификацию с использованием смарт-карт, заполнение этого атрибута является обязательным. Значение соответствует адресу электронной почты пользователя (например:
iivanov@elles.inno.tech).
Создание ключей и сертификатов
Для генерации ключей и сертификатов используется библиотека OpenSSL.
Настройка OpenSSL
Для генерации ключей и сертификатов:
-
Создайте рабочий каталог для размещения файла openssl.cnf. Например — /home/<user>/ca.
-
Поместите в созданный каталог файл openssl.cnf, который изначально был создан при установке OpenSSL, или же создайте новый файл.
Пример файла openssl.cnf
############# Секция кастомизации ################ set_countryName_default = RU set_stateOrProvinceName_default = RU set_localityName_default = SPb set_organizationName_default = Innotech set_organizationalUnitName_default = DS Solutions set_crp_default = http://dc1.elles.inno.tech/ca.crl set_dns = dc1.elles.inno.tech # См. ниже пример скрипта для преобразования objectGUID в HEX-формат set_dc_guid =85420fcd867fca40be8acda1c9878762 ###### Конец секции кастомизации ###### # This definition stops the following lines choking if HOME isn't # defined. HOME = . #RANDFILE = $ENV::HOME/.rnd CRLDISTPT = $set_crp_default # Extra OBJECT IDENTIFIER info: oid_section = new_oids # To use this configuration file with the "-extfile" option of the # "openssl x509" utility, name here the section containing the # X.509v3 extensions to use: # extensions = # (Alternatively, use a configuration file that has only # X.509v3 extensions in its main [= default] section.) [ new_oids ] # Ordinarily, certificates must have this oid as an enhanced key usage in order for Windows to allow them to be used as a login credential # Identifies the AD GUID msADGUID=1.3.6.1.4.1.311.25.1 #################################################################### [ ca ] default_ca = CA_default # The default ca section #################################################################### [ CA_default ] dir = . # Where everything is kept certs = $dir/certs # Where the issued certs are kept crl_dir = $dir/crl # Where the issued crl are kept database = $dir/index.txt # database index file. unique_subject = yes # Set to 'no' to allow creation of # several certificates with same subject. new_certs_dir = $dir/newcerts # default place for new certs. certificate = $dir/cacert.pem # The CA certificate serial = $dir/serial # The current serial number crlnumber = $dir/crlnumber # the current crl number # must be commented out to leave a V1 CRL crl = $dir/ca-crl.pem # The current CRL private_key = $dir/private/cakey.pem # The private key RANDFILE = $dir/private/.rand # private random number file #x509_extensions = # The extensions to add to the cert # Comment out the following two lines for the "traditional" # (and highly broken) format. name_opt = ca_default # Subject Name options cert_opt = ca_default # Certificate field options # Extension copying option: use with caution. copy_extensions = copy # Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs # so this is commented out by default to leave a V1 CRL. # crlnumber must also be commented out to leave a V1 CRL. crl_extensions = crl_ext default_days = 730 # how long to certify for default_crl_days= 30 # how long before next CRL default_md = sha256 # use public key default MD preserve = no # keep passed DN ordering # A few difference way of specifying how similar the request should look # For type CA, the listed attributes must be the same, and the optional # and supplied fields are just that :-) policy = policy_match # For the CA policy [ policy_match ] countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional # For the 'anything' policy # At this point in time, you must list all acceptable 'object' # types. [ policy_anything ] countryName = match stateOrProvinceName = match localityName = match organizationName = match organizationalUnitName = match commonName = supplied emailAddress = supplied #################################################################### [ req ] default_bits = 2048 default_keyfile = privkey.pem distinguished_name = req_distinguished_name attributes = req_attributes x509_extensions = v3_ca # The extensions to add to the self signed cert # Passwords for private keys if not present they will be prompted for # input_password = secret # output_password = secret # This sets a mask for permitted string types. There are several options. # default: PrintableString, T61String, BMPString. # pkix : PrintableString, BMPString (PKIX recommendation before 2004) # utf8only: only UTF8Strings (PKIX recommendation after 2004). # nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings). # MASK:XXXX a literal mask value. # WARNING: ancient versions of Netscape crash on BMPStrings or UTF8Strings. string_mask = utf8only # req_extensions = v3_req # The extensions to add to a certificate request [ req_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = $set_countryName_default countryName_min = 2 countryName_max = 2 stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = $set_stateOrProvinceName_default localityName = Locality Name (eg, city) localityName_default = $set_localityName_default organizationName = Organization Name (eg, company) organizationName_default = $set_organizationName_default organizationalUnitName = Organizational Unit Name (eg, section) organizationalUnitName_default = $set_organizationalUnitName_default commonName = Common Name (eg, YOUR name) commonName_max = 64 emailAddress = Email Address emailAddress_max = 64 # SET-ex3 = SET extension number 3 [ req_attributes ] challengePassword = A challenge password challengePassword_min = 4 challengePassword_max = 20 unstructuredName = An optional company name [ v3_req ] # Extensions to add to a certificate request basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment [ v3_ca ] # Extensions for a typical CA # PKIX recommendation. subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always,issuer # This is what PKIX recommends but some broken software chokes on critical # extensions. #basicConstraints = critical,CA:true # So we do this instead. basicConstraints = CA:true # Key usage: this is typical for a CA certificate. keyUsage = cRLSign, keyCertSign crlDistributionPoints=URI:$CRLDISTPT # Some might want this also nsCertType = sslCA, emailCA # Include email address in subject alt name: another PKIX recommendation #subjectAltName=email:copy # Copy issuer details issuerAltName=issuer:copy [ crl_ext ] # CRL extensions. # Only issuerAltName and authorityKeyIdentifier make any sense in a CRL. issuerAltName=issuer:copy authorityKeyIdentifier=keyid:always ########################################## Domain Controller Certificate ##################################### [ usr_cert_mskdc ] # These extensions are added when 'ca' signs a request for a domain controller certificate. # This goes against PKIX guidelines but some CAs do it and some software # requires this to avoid interpreting an end user certificate as a CA. basicConstraints=CA:FALSE crlDistributionPoints=URI:$CRLDISTPT # Here are some examples of the usage of nsCertType. If it is omitted # the certificate can be used for anything *except* object signing. # This is OK for an SSL server. nsCertType = server # This is typical in keyUsage for a client certificate. keyUsage = nonRepudiation, digitalSignature, keyEncipherment # This will be displayed in Netscape's comment listbox. nsComment = "Domain Controller Certificate" # PKIX recommendations harmless if included in all certificates. subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer # This stuff is for subjectAltName and issuerAltname. subjectAltName=@dc_subjalt # Copy subject details issuerAltName=issuer:copy nsCaRevocationUrl = $CRLDISTPT #nsBaseUrl #nsRevocationUrl #nsRenewalUrl #nsCaPolicyUrl #nsSslServerName #Extended Key requirements for our domain controller certs # serverAuth - says cert can be used to identify an ssl/tls server # pkInitKDC - says cert can be used to identify a Kerberos Domain Controller. extendedKeyUsage = clientAuth,serverAuth,pkInitKDC [dc_subjalt] DNS=$set_dns otherName=msADGUID;FORMAT:HEX,OCTETSTRING:$set_dc_guid ########################################### User Certificates ################################################ [ usr_cert_scarduser ] # These extensions are added when 'ca' signs a request for a certificate that will be used to login from a smart card # This goes against PKIX guidelines but some CAs do it and some software # requires this to avoid interpreting an end user certificate as a CA. basicConstraints=CA:FALSE crlDistributionPoints=URI:$CRLDISTPT # For normal client use this is typical nsCertType = client, email # This is typical in keyUsage for a client certificate. keyUsage = nonRepudiation, digitalSignature, keyEncipherment # This will be displayed in Netscape's comment listbox. nsComment = "Smart Card Login Certificate" # PKIX recommendations harmless if included in all certificates. subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer # This stuff is for subjectAltName and issuerAltname. #subjectAltName=email:copy,otherName:msUPN;UTF8:[UPN of user] # Copy subject details issuerAltName=issuer:copy nsCaRevocationUrl = $CRLDISTPT #nsBaseUrl #nsRevocationUrl #nsRenewalUrl #nsCaPolicyUrl #nsSslServerName #Extended Key requirements for client certs extendedKeyUsage = clientAuth,msSmartcardLogin -
Отредактируйте значения переменных в блоке «Секция кастомизации»:
Переменная Описание Пример set_countryName_defaultСтрана
RUset_stateOrProvinceName_defaultРегион
RUset_localityName_defaultНаселенный пункт
SPbset_organizationName_defaultОрганизация
Innotechset_organizationalUnitName_defaultПодразделение
DS Solutionsset_crp_defaultURL для доступа к списку отзыва сертификатов
http://dc1.elles.inno.tech/ca.crlset_dnsDNS-имя контроллера домена
dc1.elles.inno.techset_dc_guidИдентификатор (
objectGUID) контроллера домена85420fcd867fca40be8acda1c9878762Для получения значения атрибута
objectGUIDконтроллера домена в шестнадцатеричном формате может использоваться приведенный ниже скрипт.Скрипт должен запускаться на контроллере домена, значение
objectGUIDкоторого требуется получить, от имени пользователя с правами на чтение локальной базы данных Эллес.Он использует утилиту
ldbsearch, которая доступна после установки пакета inno-samba. Если утилита отсутствует, предварительно установите ее:sudo apt install ldb-tools
При необходимости перед запуском скрипта отредактируйте пути к файлам базы данных и конфигурации Эллес. В примере указываются пути, используемые по умолчанию при установке пакета inno-samba.
Скрипт преобразования objectGUID в шестнадцатеричный формат
#!/usr/bin/env bash # Пути к файлам БД и конфигурации Эллес SAM_LDB_PATH="/app/inno-samba/private/sam.ldb" SMB_CONF_PATH="/app/inno-samba/etc/smb.conf" # Функция для преобразования GUID в шестнадцатеричный формат convertToHex() { RAW="$1" GUID=$(echo "$RAW" | sed 's/\-//g') HEX="${GUID:6:2}" HEX="${HEX}${GUID:4:2}" HEX="${HEX}${GUID:2:2}" HEX="${HEX}${GUID:0:2}" HEX="${HEX}${GUID:10:2}" HEX="${HEX}${GUID:8:2}" HEX="${HEX}${GUID:14:2}" HEX="${HEX}${GUID:12:2}" len=${#HEX} HEX="${HEX}${GUID:16:${len}}" echo "$RAW -> $HEX" } # Получение значения realm из smb.conf realm=$(grep -i realm "$SMB_CONF_PATH" | awk '{print $3}' | tr '[:upper:]' '[:lower:]') # Формирование DN для контроллеров домена dc=$(echo "$realm" | awk -F '.' '{for(i = 1; i <= NF; i++) {printf ",DC=" $i}}') base="OU=Domain Controllers${dc}" # Получение имени текущего хоста cn=$(hostname -s) # Получение GUID контроллера домена GUID=$(ldbsearch -H "$SAM_LDB_PATH" --basedn="$base" "CN=${cn}" objectGUID \ | grep '^objectGUID:' \ | awk '{print $2}' \ ) # Преобразование GUID в шестнадцатеричный формат convertToHex "$GUID" -
В каталоге ca создайте файлы index.txt, serial, crlnumber и подкаталоги private, newcerts:
touch index.txt echo "00" > serial echo "00" > crlnumber mkdir private newcerts
Описание назначения и содержимого файлов:
Файл Содержимое Описание index.txt
Используется для учета выпущенных и отозванных сертификатов; изначально пустой
serial
00Указывает на серийный номер следующего выпускаемого сертификата; шестнадцатеричное число
crlnumber
00Указывает на серийный номер следующего генерируемого списка CRL; шестнадцатеричное число
Создание корневого ключа и сертификата
Данный шаг выполняется, если корневого сертификата и ключа, которым удостоверяющий центр будет подписывать запросы на сертификаты в домене, еще не существует. В инструкции используется самоподписанный сертификат X509.
Ключи (закрытый и открытый) выпускаются с типом RSA 2048 бит и алгоритмом хеширования sha256RSA. Срок действия сертификата — 365 дней.
Для создания корневого ключа и сертификата:
-
В каталоге ca выполните команду:
openssl req -new -x509 -days 3650 -sha256 -extensions v3_ca -addext 'subjectAltName = email:copy' -keyout private/cakey.pem -out cacert.pem -config openssl.cnf
В процессе генерации ключа и сертификата:
-
в ответ на запрос "Enter PEM pass phrase" придумайте и укажите пароль для закрытого ключа;
-
укажите имя удостоверяющего центра (Common name) — в данном примере настройки используется имя домена (elles.inno.tech);
-
укажите адрес электронной почты (Email Address) — в данном примере настройки используется ca@elles.inno.tech.
В результате работы команды:
-
в подкаталоге private создается файл cakey.pem с новым закрытым ключом удостоверяющего центра;
-
в каталоге ca создается файл сертификата удостоверяющего центра cacert.pem.
-
-
Для использования на клиентских компьютерах под управлением ОС Windows конвертируйте сертификат удостоверяющего центра в формат DER:
openssl x509 -in cacert.pem -inform PEM -out cacert.cer -outform DER
В результате в каталоге ca создается файл cacert.cer.
Создание ключа и сертификата для контроллера домена
Ключи (закрытый и открытый) выпускаются с типом RSA 2048 бит и алгоритмом хеширования sha256RSA. Срок действия сертификата по умолчанию — 730 дней (равен значению параметра default_days в файле openssl.cnf).
Для создания закрытого ключа и запроса сертификата:
-
В каталоге ca выполните команду:
openssl req -new -addext 'subjectAltName = email:copy' -newkey rsa:2048 -keyout private/dc-key.pem -out dc-req.pem -config openssl.cnf
В процессе генерации ключа и запроса сертификата:
-
в ответ на запрос "Enter PEM pass phrase" придумайте и укажите пароль для закрытого ключа;
-
укажите имя контроллера домена (Common name) — в данном примере настройки используется DNS-имя контроллера домена (dc1.elles.inno.tech).
В результате работы команды:
-
в подкаталоге private создается файл dc-key.pem с новым закрытым ключом контроллера домена;
-
в каталоге ca создается файл запроса сертификата dc-req.pem.
-
-
Подпишите запрос сертификата ключом удостоверяющего центра, чтобы выпустить сертификат:
openssl ca -config openssl.cnf -extensions usr_cert_mskdc -in dc-req.pem -out dc-cert.pem
В процессе генерации сертификата:
-
в ответ на запрос "Enter pass phrase for ./private/cakey.pem" укажите пароль для закрытого ключа удостоверяющего центра;
-
подтвердите выпуск сертификата.
В результате работы команды в каталоге ca создается файл dc-cert.pem с выпущенным сертификатом.
-
-
При необходимости для просмотра на клиентских компьютерах под управлением ОС Windows конвертируйте сертификат контроллера домена в формат DER:
openssl x509 -in dc-cert.pem -inform PEM -out dc-cert.cer -outform DER
В результате в каталоге ca создается файл dc-cert.cer.
Добавление пользователей, использующих смарт-карты для аутентификации
Для добавления пользователей, которые должны проходить аутентификацию только с использованием смарт-карт (сертификатов), используйте команду:
samba-tool user add <user name> --smartcard-required --no-pass
| См. описание синтаксиса и параметров в разделе «Администрирование пользователей». |
Создание ключа и сертификата для пользователя
Ключи (закрытый и открытый) выпускаются с типом RSA 2048 бит и алгоритмом хеширования sha256RSA. Срок действия сертификата по умолчанию — 730 дней (равен значению параметра default_days в файле openssl.cnf).
Пример создания закрытого ключа и запроса сертификата для пользователя Ivan Ivanov (iivanov) с атрибутом userPrincipalName=iivanov@elles.inno.tech:
-
В каталоге ca выполните команду:
openssl req -new -addext 'subjectAltName = otherName:msUPN;UTF8:iivanov@elles.inno.tech,email:copy' -newkey rsa:2048 -keyout private/iivanov-key.pem -out iivanov-req.pem -config openssl.cnf
В процессе генерации ключа и запроса сертификата:
-
в ответ на запрос "Enter PEM pass phrase" придумайте и укажите пароль для закрытого ключа;
-
укажите имя пользователя (Common name);
-
укажите адрес электронной почты пользователя (Email Address).
Это значение будет использоваться в поле
RFC822атрибутаSubject Alternative Nameв сертификате.
В результате работы команды:
-
в подкаталоге private создается файл iivanov-key.pem с новым закрытым ключом пользователя;
-
в каталоге ca создается файл запроса сертификата iivanov-req.pem.
-
-
Подпишите запрос сертификата ключом удостоверяющего центра, чтобы выпустить сертификат:
openssl ca -config openssl.cnf -extensions usr_cert_scarduser -in iivanov-req.pem -out iivanov-cert.pem
В процессе генерации сертификата:
-
в ответ на запрос "Enter pass phrase for ./private/cakey.pem" укажите пароль для закрытого ключа удостоверяющего центра;
-
подтвердите выпуск сертификата.
В результате работы команды в каталоге ca создается файл iivanov-cert.pem с выпущенным сертификатом.
-
-
Для использования на клиентских компьютерах под управлением ОС Windows конвертируйте сертификат контроллера домена в формат DER:
openssl x509 -in iivanov-cert.pem -inform PEM -out iivanov-cert.cer -outform DER
В результате в каталоге ca создается файл iivanov-cert.cer.
Проверка сертификатов
Для проверки выпущенных сертификатов может использоваться команда, позволяющая вывести содержимое указанного файла сертификата в текстовый файл для дальнейшего анализа.
Пример выполнения команды для сертификата удостоверяющего центра:
openssl x509 -in cacert.pem -text -out cacert.txt
Также существует возможность просмотра содержимого сертификатов, преобразованных в формат DER, в оснастке certmgr.msc на компьютере с ОС Windows.
Генерация списка отзыва сертификатов
При валидации сертификатов контроллером домена и клиентской машиной в процессе PKINIT используется проверка сертификатов на отзыв.
Для генерации файла списка отзыва выполните:
echo 1000 > ca.crl openssl ca -config openssl.cnf -gencrl -out ca.crl
В результате создается файл ca.crl.
Публикация списка отзыва сертификатов на веб-сервере
Файл со списком отзыва сертификатов ca.crl должен быть доступен всем, кто проверяет сертификаты, выпущенные удостоверяющим центром, на отзыв.
Для этой цели на одном из контроллеров домена может быть развернут веб-сервер (например, Nginx), куда должен быть помещен этот файл. Файл должен быть доступен без аутентификации. При этом адрес размещения файла должен совпадать с адресом, указанным в сертификатах.
Генерация файла с параметрами DH для доменного контроллера
Для генерации файла с параметрами для алгоритма Diffie-Hellman, который позволяет двум сторонам создать общий секретный ключ по незащищенному каналу связи, выполните команду:
openssl dhparam -outform PEM -out dcdhparams.pem 2048
В результате создается файл dcdhparams.pem.
Использование этого файла не является обязательным для аутентификации по смарт-картам, но повышает уровень безопасности.
Конфигурирование контроллера домена Эллес
На контроллере домена Эллес:
-
Поместите сертификаты удостоверяющего центра (cacert.pem), контроллера домена (dc-cert.pem), файл параметров DH (dcdhparams.pem) и файл списка отзыва (ca.crl) в каталог /app/inno-samba/private/tls. Если в каталоге есть другие файлы, удалите их.
-
Расшифруйте файл закрытого ключа контроллера домена (Эллес не может работать с ключами, зашифрованными паролем):
sudo openssl rsa -in dc-key.pem -inform PEM -out dc-privkey.pem
-
Создайте подкаталог secure в /app/inno-samba/private/tls и скопируйте в него файл с расшифрованным закрытым ключом контроллера домена dc-privkey.pem.
-
В файле конфигурации /app/inno-samba/etc/smb.conf в разделе
globalвключите TLS и укажите относящиеся к TLS параметры.Пример раздела global с установленными параметрами
[global] ad dc functional level = 2016 dns forwarder = 127.0.0.1 netbios name = DC1 realm = ELLES.INNO.TECH server role = active directory domain controller workgroup = ELLES idmap_ldb:use rfc2307 = yes tls enabled = yes tls certfile = /app/inno-samba/private/tls/dc-cert.pem tls keyfile = /app/inno-samba/private/tls/secure/dc-privkey.pem tls cafile = /app/inno-samba/private/tls/cacert.pem tls crlfile = /app/inno-samba/private/tls/ca.crl tls dhparams file = /app/inno-samba/private/tls/dcdhparams.pem log level = 3См. описание параметров TLS в разделе «Конфигурационные параметры (smb.conf)». -
Убедитесь, что пользователь, от имени которого запущена служба
inno-samba(например root), имеет разрешение на чтение файлов в каталогах /app/inno-samba/private/tls и /app/inno-samba/private/tls/secure.
Другим пользователям доступ туда должен быть ограничен, в особенности — к /app/inno-samba/private/tls/secure. -
В конфигурации Kerberos в файле /etc/krb5.conf включите и настройте поддержку PKINIT, обращая внимание на следующее:
-
в секции
libdefaultsатрибутpkinit_anchorsдолжен указывать путь к файлу сертификата удостоверяющего центра; -
в секции
appdefaultsатрибутpkinit_anchorsтакже должен указывать путь к файлу сертификата удостоверяющего центра; -
в секции
realmsдля области безопасности домена должен быть указан атрибутpkinit_require_eku = true, устанавливающий требование использования расширений X509v3 в сертификатах; -
в секции
kdcдолжны быть заданы:-
enable-pkinit = yes— включение PKINIT; -
pkinit_identity— путь к файлу закрытого ключа контроллера домена; -
pkinit_anchors— путь к файлу сертификата удостоверяющего центра; -
pkinit_principal_in_certificate = yes— учетная запись указывается в сертификате; -
pkinit_win2k = no— требование использования актуальной версии PKINIT; -
pkinit_win2k_require_binding = yes— требование строгой связи X509v3Subject Alternative Name/Other Name/Principal Nameс атрибутомuserPrincipalNameпользователя со смарт-картой.
-
Пример файла /etc/krb5.conf с настроенной поддержкой PKINIT
[libdefaults] default_realm = ELLES.INNO.TECH dns_lookup_realm = false dns_lookup_kdc = true pkinit_anchors = FILE:/app/inno-samba/private/tls/cacert.pem [appdefaults] pkinit_anchors = FILE:/app/inno-samba/private/tls/cacert.pem [realms] ELLES.INNO.TECH = { default_domain = elles.inno.tech pkinit_require_eku = true } [domain_realm] dc1 = ELLES.INNO.TECH [kdc] enable-pkinit = yes pkinit_identity = FILE:/app/inno-samba/private/tls/dc-cert.pem,/app/inno-samba/private/tls/secure/dc-privkey.pem pkinit_anchors = FILE:/app/inno-samba/private/tls/cacert.pem pkinit_principal_in_certificate = yes pkinit_win2k = no pkinit_win2k_require_binding = yes -
|
В секции kdc_tcp_listen = 88 |
Установка сертификатов и ключей на клиентском компьютере под управлением Windows
Для обеспечения возможности аутентификации по смарт-карте на клиентском компьютере с ОС Windows, введенном в домен, необходимо внести корневой сертификат удостоверяющего центра в список доверенных и перенести ключ и сертификат пользователя на смарт-карту.
Добавление корневого сертификата удостоверяющего центра в список доверенных
Корневой сертификат удостоверяющего центра может быть добавлен в список доверенных на компьютере с ОС Windows с помощью группой политики или локально.
Для добавления с помощью групповой политики:
-
Выполните вход на введенный в домен компьютер с учетной записью администратора домена. Скопируйте на компьютер файл сертификата в формате DER (cacert.cer).
-
Откройте оснастку управления групповыми политиками — нажмите Win+R, введите gpmc.msc и нажмите Enter.
-
Создайте или измените существующий объект групповой политики (например, Default Domain Policy). Чтобы создать новый объект, нажмите правой кнопкой мыши на имени домена, выберите Создать объект групповой политики и далее — Изменить.
-
Чтобы добавить сертификат удостоверяющего центра, в редакторе GPO откройте Конфигурация компьютера → Политики → Параметры Windows → Параметры безопасности → Политики открытых ключей → Доверенные корневые центры сертификации.
-
Импортируйте корневой сертификат:
-
щелкните правой кнопкой по Доверенные корневые центры сертификации и выберите Импорт…;
-
в мастере импорта сертификатов выберите файл сертификата cacert.cer;
-
нажмите Далее и затем Готово.
После этого сертификат появится в списке.
-
-
Дождитесь автоматического применения политики на клиентских компьютерах или примените вручную:
gpupdate /force
-
Для проверки на клиентской машине:
-
откройте оснастку для работы с сертификатами — нажмите Win+R, введите certmgr.msc и нажмите Enter;
-
выберите Сертификаты – Текущий пользователь → Доверенные корневые центры сертификации → Сертификаты;
-
убедитесь, что сертификат удостоверяющего центра отображается в списке.
-
Для добавления вручную на отдельном клиентском компьютере:
-
Выполните вход на введенный в домен компьютер с учетной записью администратора домена. Скопируйте на компьютер файл сертификата в формате DER (cacert.cer).
-
Откройте оснастку для работы с сертификатами — нажмите Win+R, введите certmgr.msc и нажмите Enter.
-
Выберите Доверенные корневые центры сертификации → Сертификаты.
-
Щелкните правой кнопкой по Сертификаты, выберите Все задачи → Импорт…, выберите файл cacert.cer и нажмите Готово.
Добавление корневого сертификата центра сертификации в реестр Windows
Корневой сертификат удостоверяющего центра должен быть внесен в реестр Windows на машине, с которой будет выполняться вход по смарт-карте. Сертификат помещается в контейнер HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseCertificates\NTAuth\Certificates.
Для добавления корневого сертификата удостоверяющего центра в реестр Windows:
-
Выполните вход на введенный в домен компьютер с учетной записью с достаточными для работы с реестром правами. Скопируйте на компьютер файл сертификата в формате DER (cacert.cer).
-
Добавьте файл в реестр:
certutil -enterprise -addstore NTAuth cacert.cer
Если в домене развернуты службы сертификации Active Directory (Active Directory Certificate Services, AD CS), распространение сертификата удостоверяющего центра на клиентские машины может быть автоматизировано. Для этого необходимо добавить его в контейнер CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=<domain name>,DC=<domain suffix> с помощью команды:
certutil -dspublish -f cacert.cer NTAuthCA
Перенос ключа и сертификата пользователя на смарт-карту
Способ переноса закрытого ключа и сертификата пользователя на смарт-карту зависит от используемого драйвера смарт-карт.
Например, если необходимы ключ и сертификат в контейнере PKCS12:
-
Сформируйте токен для пользователя:
openssl pkcs12 -in iivanov-cert.pem -inkey private/iivanov-key.pem -export -out iivanov.p12
-
Импортируйте токен на смарт-карту в соответствии с поставляемой с ней документацией.
-
Обновите конфигурацию групповых политик:
gpupdate
Для проверки выполните вход на клиентский компьютер от имени учетной записи пользователя, для которой выполнялась настройка, с использованием смарт-карты.
Установка сертификатов и ключей на клиентском компьютере под управлением Linux
Для обеспечения возможности получения билетов Kerberos с использованием сертификатов на клиентском компьютере с ОС Linux, введенном в домен:
-
Предварительно расшифруйте файл закрытого ключа пользователя, так как Эллес не поддерживает работу с зашифрованным паролем:
openssl rsa -in iivanov-key.pem -inform PEM -out iivanov-privkey.pem
-
Разместите файлы ключа и сертификатов на компьютере в каталогах, доступных для чтения тем пользователям, которым будет разрешено использовать их для аутентификации.
Пример размещения файлов в домашнем каталоге пользователя:$ ls -la drwx------ 22 user user 4096 окт 10 12:55 . drwxr-xr-x 4 root root 4096 окт 16 2023 .. -rw-r--r-- 1 user user 1598 окт 17 15:34 cacert.pem -rw-r--r-- 1 user user 5713 окт 17 15:34 iivanov-cert.pem -rw-r--r-- 1 user user 1675 окт 17 15:34 iivanov-privkey.pem
Закрытый ключ в расшифрованном виде не следует хранить с доступом для чтения любому пользователю, поэтому для него необходимо ограничить права доступа:
chmod 600 iivanov-privkey.pem
-
Настройте поддержку PKINIT в конфигурации Kerberos в файле /etc/krb5.conf в соответствии с документацией MIT Kerberos, используя следующие параметры в разделе области безопасности домена в секции
realms:-
pkinit_anchors— путь к файлу или каталогу, содержащему доверенный корневой сертификат удостоверяющего центра; -
pkinit_identities— пути к файлам сертификата клиента и его закрытого ключа (через запятую без пробелов);В клиентской конфигурации Kerberos наименование параметра для указания пути к файлам сертификата и ключа — pkinit_identities. В серверной конфигурации KDC аналогичный параметр имеет другое наименование —pkinit_identity. -
pkinit_kdc_hostname— имя хоста KDC, указанное в полеSubject Alternative Nameсертификата KDC.
Пример файла /etc/krb5.conf с настроенной поддержкой PKINIT
[libdefaults] default_realm = ELLES.INNO.TECH dns_lookup_realm = false dns_lookup_kdc = true [realms] ELLES.INNO.TECH = { pkinit_anchors = FILE:/home/user/cacert.pem pkinit_identities = FILE:/home/user/iivanov-cert.pem,/home/user/iivanov-privkey.pem kdc = dc1.elles.inno.tech admin_server = dc1.elles.inno.tech pkinit_kdc_hostname = dc1.elles.inno.tech default_domain = elles.inno.tech } [domain_realm] .elles.inno.tech = ELLES elles.inno.tech = ELLES -
Для проверки корректности настройки запросите билет Kerberos для пользователя:
kinit iivanov
Аутентификация будет произведена с использованием сертификатов, указанных в файле /etc/krb5.conf.
Настройка PKINIT Freshness
Расширение Freshness в PKINIT позволяет подтвердить, что клиент имеет доступ к закрытому ключу в момент запроса билета Kerberos, а не только ранее или в будущем. Для этого на этапе предварительной аутентификации KDC выдает токен (freshness token), подтверждающий актуальность запроса (см. RFC 8070).
При работе с Эллес для управления поддержкой расширения PKINIT Freshness могут использоваться (элементы списка расположены в порядке возрастания приоритета):
-
файл конфигурации Kerberos (krb5.conf);
-
файл конфигурации контроллера домена Эллес (smb.conf);
-
объект групповой политики (GPO).
См. описание перечисленных способов настройки в подразделе «Настройка поддержки расширения PKINIT Freshness».