Krb5 conf astra linux

Ввод Astra Linux Special Edition 1.6 в Active Directory с настройкой SSO в PostgreSQL.

Настроим ОС Astra Linux SE 1.6 и введем в домен MS Active Directory . В процессе настроим SMABA, WINBIND и POSTGRESQL, а также настроим в POSTGRESQL SSO через GSSAPI.

Данная настройка проводилась с обновлением ОС Astra Linux SE 1.6 — 20191029SE16 . Процесс обновления ОС не описан в процессе конфигурации.

Вводные данные

Контроллеры домена Active Directory

Сервер c базой данных Postgresql

ОС – Astra Linux SE 1.6. Установлена без ALD и без режима киоска. Дополнительное ПО выбрано базовые средства, рабочий стол Fly, средства работы в сети, СУБД.

Разблокировка учетной записи ROOT

Для удобства настройки разблокируем учетную запись ROOT

Для безопасности по окончанию работ требуется заблокировать учетную запись ROOT!

Настройка сети на bd1

Приведем файл /etc/hosts к виду

Проверим правильность имени машины в /etc/hostname

Настроим статический IP-адрес, для этого внесем строки в файл /etc/network/interfaces

Для автоматической генерации файла /etc/resolv.conf установим пакет resolvconf.

Проверим, должен появиться интерфейс eth0 с назначенным нами адресом 192.168.0.100

Проверим доступность контроллеров домена Active Directory

Настроим синхронизацию времени с контроллерами домена, для этого в файле /etc/ntp.conf добавим в секцию «You do need to talk to an NTP server or two (or three)»

Установим требуемые пакеты

Сначала проверим установлены ли пакеты SAMBA, WINBIND, NTP и POSTGRESQL

Произведем до установку пакетов которые нам потребуются далее (потребуется диск с дистрибутивом ОС)

apt-get install nscd nslcd libpam-winbind libpam-krb5 libsasl2-modules-gssapi-mit krb5-user libnss-winbind

Чтобы установить следующий пакет потребуется диск разработчика

Настройка конфигурационных файлов для работы с доменом Active Directory.

Отредактируем конфигурационный файл Kerberos /etc/krb5.conf и приведем его к виду

Источник

Krb5 conf astra linux

Центральной частью схемы аутентификации Kerberos является третья доверенная сторона — Key Distribution Center (KDC), которая является централизованным хранилищем информации о пользователях. Перед разворачиванием Kerberos, должен быть выбран сервер, который будет выполнять роль KDC. Физическая и сетевая безопасность критичны для этого сервера, так как его компрометация ведет к компрометации всего realm.

Выбор хорошего имени для realm так же важен. По правилам, имя realm это доменное имя сайта в верхнем регистре. Например, для сайта или доменной зоны example.com рекомендуется выбрать EXAMPLE.COM в качестве имени realm.

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

Host Names

Каждый сервер внутри Kerberos realm должен иметь Fully Qualified Domain Name (FQDN).

Kerberos так же ожидает, что FQDN сервера является reverse-resolvable. Если выяснение доменного имени по IP недоступно, то установите значение переменной rdns в значение false на клиентах в файле krb5.conf.

Active Directory сильно зависит от DNS, поэтому весьма вероятно что ваш Active Directory Domain Controller уже имеет роль DNS. В этом случае убедитесь в том, что каждый сервер имеет свое FQDN перед выполнением тестов, описанных ниже в этом разделе.

Если сервер уже имеет назначенное FQDN, проверьте корректность обнаружения forward и reverse выполнив на клиенте следующие команды:

$ nslookup server.example.com $ nslookup

Если вы используете Astra Linux (или другой дистрибутив), то для установки программы nslookup, вам необходимо установить пакет dnsutils.

Вы можете воспользоваться Synaptic Package Manager или выполнить из командной строки $ apt-get install dnsutils

Вывод первой команды должен содержать IP адрес сервера. Вывод второй команды должен содержать FQDN сервера.

Если у сервера нет назначенного FQDN и сервис DNS не доступен, то вы можете отредактировать локальные файлы hosts (обычно они находятся в /etc) на сервере добавив туда следующую строку:

127.0.0.1 server.aktiv-test.ru localhost server

А на каждом клиенте добавить строку

Где IP-address — это IP адрес сервера. В нашем примере это будет 10.0.0.1.

После этого проверьте работу локальных DNS имен используя команду nslookup как показано выше.

Наличие соединения

Для проверки соединения между хостами, выполните ping для каждого хоста по его FQDN:

$ ping server.aktiv-test.ru PING server.aktiv-test.ru (10.0.0.1) 56(84) bytes of data. 64 bytes from server.aktiv-test.ru (10.0.0.1): icmp_seq=1 ttl=128 time=0.176ms

Вывод команды ping показывает успешное определение IP адреса по FQDN, и простой ответ от сервера. Ответ от сервера является подтверждением того, что между хостом и сервером есть соединение.

Проблемы при работе ping указывают на проблемы настройки сервера или клиента.

Синхронизация времени

Протокол Kerberos требует синхронизации времени сервера и клиента: если системные часы клиентов и сервера расходятся, то аутентификация не будет выполнена. Простейший способ синхронизировать системные часы — использование Network Time Protocol (NTP) сервера. Некоторый линуксы, например, Astra Linux по-умолчанию синхронизирует время с российскими NTP-серверами. Для настройки собственного NTP-сервера смотрите документацию на ваш дистрибутив (например, UbuntuTime для Ubuntu).

Брандмауэры

Так же как и все остальные сетевые службы, Kerberos должен иметь возможность проходить через любые брандмауэры между хостами. Инструкция Kerberos System Administration Manual имеет детальное описание портов, которые необходимо открыть при настройке брандмауэров.

Проверка модели устройства

1. Подключите USB-токен к компьютеру.
2. Для определения названия модели USB-токена откройте Терминал и введите команду:

В результате в окне Терминала отобразится название модели USB-токена:

Убедитесь, что используете: Aktiv Rutoken ECP

Стенд

Важно : время на клиенте и сервере должно быть синхронизировано. Невыполнение этого требования может привести к возникновению проблем.

Сервер

• Установлены krb5-kdc, krb5-admin-server, krb5-pkinit
• Kerberos realm: AKTIV-TEST , доменное имя aktiv-test.ru (прописано в /etc/hosts на клиенте)
  Примечание: доменное имя стоит делать минимум второго уровня для избежания ошибок
• Пользователи: testuser@AKTIV-TEST

Клиент

• Установлены krb5-user, libpam-krb5, libpam-ccreds, auth-client-config, krb5-pkinit, opensc, libengine-pkcs11-openssl
• default realm: AKTIV-TEST
• серверы (kdc, admin) указаны по IP-адресу (лучше указать их в /etc/hosts)

Первичная настройка

Сервер

Установить пакеты и создать новый realm

$ sudo apt-get install krb5-kdc krb5-admin-server krb5-pkinit # В диалогах указать: # realm = AKTIV-TEST # домен = aktiv-test.ru $ sudo krb5_newrealm # ввести пароль

В файле конфигурации сервера /etc/krb5.conf указать

[domain_realm] .aktiv-test.ru = AKTIV-TEST aktiv-test.ru = AKTIV-TEST

Создать на сервере нового пользователя

$ sudo kadmin.local # username = testuser # password = test kadmin.local:$ addprinc # . kadmin.local:$ quit

На сервере проверить, что для этого пользователя можно получить тикет

Клиент

Установим необходимые пакеты и сконфигурируем kerberos

$ sudo apt-get install krb5-user libpam-krb5 libpam-ccreds auth-client-config krb5-pkinit opensc libengine-pkcs11-openssl # В диалогах указать: # realm = AKTIV-TEST # домен = aktiv-test.ru $ sudo dpkg-reconfigure krb5-config

В файле конфигурации клиента /etc/krb5.conf указать

[domain_realm] . .aktiv-test.ru = AKTIV-TEST aktiv-test.ru = AKTIV-TEST

Проверим, что пользователь может аутентифицироваться по паролю

Настройка аутентификации по Рутокену

Сервер

Создадим ключ и самоподписанный сертификат УЦ

$ openssl genrsa -out cakey.pem 2048 $ openssl req -key cakey.pem -new -x509 -out cacert.pem

Создадим файл pkinit_extensions со следующим содержимым

[ kdc_cert ] basicConstraints=CA:FALSE # Here are some examples of the usage of nsCertType. If it is omitted keyUsage = nonRepudiation, digitalSignature, keyEncipherment, keyAgreement #Pkinit EKU extendedKeyUsage = 1.3.6.1.5.2.3.5 subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer # Copy subject details issuerAltName=issuer:copy # Add id-pkinit-san (pkinit subjectAlternativeName) subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:kdc_princ_name [kdc_princ_name] realm = EXP:0, GeneralString:$ principal_name = EXP:1, SEQUENCE:kdc_principal_seq [kdc_principal_seq] name_type = EXP:0, INTEGER:1 name_string = EXP:1, SEQUENCE:kdc_principals [kdc_principals] princ1 = GeneralString:krbtgt princ2 = GeneralString:$ [ client_cert ] # These extensions are added when ‘ca’ signs a request. basicConstraints=CA:FALSE keyUsage = digitalSignature, keyEncipherment, keyAgreement extendedKeyUsage = 1.3.6.1.5.2.3.4 subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:princ_name # Copy subject details issuerAltName=issuer:copy [princ_name] realm = EXP:0, GeneralString:$ principal_name = EXP:1, SEQUENCE:principal_seq [principal_seq] name_type = EXP:0, INTEGER:1 name_string = EXP:1, SEQUENCE:principals [principals] princ1 = GeneralString:$

Создадим ключ и сертификат KDC

$ openssl genrsa -out kdckey.pem 2048 # создание запроса $ openssl req -new -out kdc.req -key kdckey.pem # подпись запроса $ REALM=; export REALM $ CLIENT=; export CLIENT # содержимое файла pkinit_extensions выше $ openssl x509 -req -in kdc.req -CAkey cakey.pem -CA cacert.pem -out kdc.pem -extfile pkinit_extensions -extensions kdc_cert -CAcreateserial

Пере местим файлы kdc.pem, kdckey.pem, cacert.pem в директорию /etc/krb5/

$ sudo mkdir /etc/krb5 $ sudo cp kdc.pem kdckey.pem cacert.pem /etc/krb5/

Источник