Ald сервер домена не обнаружен astra linux

Обновлено: 02.07.2024

Использование службы ALD ОССН Astra Linux для защиты информации.

Рисунок 1. Вариант реализации корпоративной ЗЛВС для мультисервисной системы связи на базе ОССН Astra Linux Special Edition (релизы Смоленск, Мурманск, Новороссийск).

На рис. 1 представлен вариант реализации корпоративной ЗЛВС для мультисервисной системы связи на базе ОССН. При этом рабочие станции пользователей ЗЛВС являются клиентами доменной сетевой инфраструктуры, координируемой первичным контроллером домена (Primary Domain Controller

PDC) под управлением ОССН.

Текущий релиз ОССН поддерживает доменную сетевую инфраструктуру, основанную на технологии Active Directory (AD), которая является совместимой с технологией Microsoft Directory Service и базируется на реализации следующих протоколов:

OpenLDAP — реализация протокола прикладного уровня LDAP (Lightweight Directory Access Protocol) с открытым исходным кодом, обеспечивающего механизм «I&А» (Identification and Authentication), а также поиск, добавление, изменение и удаление записей в единый каталог сетевых объектов;
Samba — реализация протокола прикладного уровня SMB/CIFS (Server Message Block/Common Internet File System) с открытым исходным кодом, обеспечивающего удалённый доступ к сетевым ресурсам (файлам, принтерам), а также реализацию механизма IPC (Inter-Process Communication) для удалённого выполнения приложений;
Kerberos — протокол взаимной аутентификации хостов перед установлением соединения между ними, реализующий механизм единого входа (Single Sign-On — SSO).

Определение из Википедии:

Kerberos /kɛərbərəs/ — сетевой протокол аутентификации, который предлагает механизм взаимной аутентификации клиента и сервера перед установлением связи между ними, причём в протоколе учтён тот факт, что начальный обмен информацией между клиентом и сервером происходит в незащищенной среде, а передаваемые пакеты могут быть перехвачены и модифицированы.

централизованного хранения данных своих учётных записей и информации о их пользовательском окружении;
монтирования для учётных записей пользователей их домашних каталогов, расположенных на PDC, в состав локальной файловой системы хоста;
сквозной аутентификации на хостах, входящих в состав доменной сетевой инфраструктуры.

Совокупность указанных возможностей обеспечивает формирование для пользователя хоста на основе ОССН, включённого в доменную сетевую инфраструктуру, его ЕПП.

В общем виде схема организации ЕПП показана на рис. 2, при этом её логическими составляющими являются:

множество клиентов домена;
контроллер (контроллеры) домена.

В рамках клиента домена ЕПП реализует:

Рисунок 2. Схема организации ЕПП домена на основе ОССН.

В рамках контроллера домена ЕПП реализует:

Реализацию политики безопасности в рамках доменной сетевой инфраструктуры выполняет LSM-модуль parsec-cifs подсистемы безопасности PARSEC, который инициализируется на контроллере и клиентах домена в процессе инсталляции на них ОССН в ролях контроллера и клиента домена соответственно. По своим функциональным возможностям модуль parsec-cifs идентичен модулю parsec, функционирующему в случае применения ОССН на компьютерах, не входящих в состав доменной сетевой инфраструктуры.

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

В ОССН локальное и глобальное пространства имён (систем учётных записей пользователей и групп пользователей) функционируют параллельно. Для их различения выполнено разграничение диапазонов UID: значения UID меньшие 2500 относятся к локальному пространству имён, а значения UID больше либо равные 2500 к глобальному пространству имён.

Механизм «I&А» (Identification and Authentication), в пределах локального пространства имён на клиенте домена под управлением ОССН реализуется с использованием архитектуры РАМ, особенности использования которой рассмотрены в предыдущей лекции. Реализация этого механизма в рамках глобального пространства имён в домене на базе ОССН основана на инфраструктуре LDAP (хранение и администрирование учётных записей пользователей домена), функционирующей совместно с протоколом Kerberos.

База данных учётных записей глобального пространства имён реализована в виде «Дерева директорий информации» (Directory Information Tree — DIT). Подобная модель хранения данных основана на записях, содержащих наборы атрибутов, различающиеся по «Отличительному имени» (Distinguished Name — DN), которые используются для реализации однозначности при обращении к записи. Каждый из атрибутов записи относится к конкретному типу и имеет одно или несколько значений. Типы обычно представлены строковыми переменными.

DIT глобального пространства имён контроллера домена на базе ОССН разделено на две DN-ветви: ou = People и ои = Group₎ которые свою очередь имеют дочерние DN-ветви, имеющие тип сп и содержащие атрибуты учётных записей самих пользователей домена, групп пользователей домена и их теневых паролей. В общем DIT ресурсе контроллера домена указанные DN-ветви включены в DN-ветви dc = engine и dс = local. В графическом виде общее DIT контроллера домена на базе ОССН показано на рис. 3.

$C:\Users\SVETLANA\AppData\Local\Temp\FineReader12.00\media\image23.jpg$

Рис. 3. Структура DIT-дерева, реализующего глобальное пространство пользователей домена на базе ОССН

Таблица. Расшифровка названий атрибутов ГПП ОССН.

Атрибут	Англоязычное название	Русскоязычное название	Value\Значение
DN	Distinguished Name	Отличительное (уникальное) имя	CN=Сергей Петрович Иванов,OU=Компания,DC=domain,DC=com
DC	Domain Component	Компонент(класс) доменного имени.	DC=domain,DC=com
OU	Organizational Unit	Подразделение	Компания
CN	Common Name	Общее имя	Сергей Петрович Иванов

С учётом МРОСЛ ДП-модели атрибуты DIT-дерева дополняются DN-ветвями, определяющими информационные сервисы для мандатных уровней конфиденциальности и целостности. Эти дополнительные атрибуты находятся в файле /etc/parsec/mldap.conf (рис. 4).

Рисунок 4. Дополнительные атрибуты DIT-дерева, определяющие информационные сервисы для реализации МРОСЛ ДП-модели

$C:\Users\SVETLANA\AppData\Local\Temp\FineReader12.00\media\image24.jpg$

В зависимости от необходимости использования локальной или глобальной реализации механизма «I&А» на клиенте домена производится их динамическое переключение, основанное на технологии NSS (Name Service Switch). Эта технология создаёт модульное окружение для управления пользовательскими учётными записями, реализованное в виде набора загружаемых библиотек (backends). При этом базовые системные вызовы при применении технологии NSS реализованы в библиотеке glibc, которая в зависимости от конфигурации NSS вызывает те или иные backend (рис. 5).

Рисунок. 5. Схема реализации технологии NSS на клиенте домена под управлением ОССН.

Функции библиотеки glibc, реализующие технологию NSS на клиенте домена под управлением ОССН, вызывают два backend:

• libnss_file — модуль, обеспечивающий идентификацию локальных учётных записей пользователей и групп пользователей с использованием конфигурационных файлов /etc/passwd, /etc/group, /etc/shadow, /etc/gshadow (авторизация при этом выполняется соответствующим РАМ-модулем);

• libnss_ldap — модуль, обеспечивающий идентификацию учётных записей пользователей и групп пользователей домена с использованием соответствующих DN-ветвей DIT-дерева на контроллере домена (авторизация при этом может выполняться как с использованием РАМ-модуля libpam_ldap — связка NSS/PAM, так и с использованием сквозной аутентификации по протоколу Kerberos — метод аутентификации по умолчанию). Конфигурация NSS задаётся в файле /etc/nsswitch.conf. Таким образом, при выполнении процессов, требующих обращения к именованным сущностям, соответствующие вызовы функций библиотеки glibc будут обращаться к функциям backend, указанных в файле /etc/nsswitch.conf. Пример файла /etc/nsswitch.conf клиента домена на базе ОССН приведён на рис. 6.

Рисунок 6. Пример конфигурационного файла NSS на клиенте домена

Кроме имён и идентификаторов учётных записей пользователей и групп пользователей технология NSS позволяет определять имена и идентификаторы протоколов, номера портов сервисов, IP-адреса и имена хостов, а также другие данные. В частности, применительно к МРОСЛ ДП-модели технология NSS позволяет определять источники данных для задания мандатных уровней конфиденциальности и целостности, для этого используется конфигурационный файл /etc/parsec/mswitch.conf подсистемы безопасности PARSEC (рис. 7).

Для сквозной аутентификации пользователей домена на базе ОССН применяется протокол Kerberos. В рамках доменной инфраструктуры, основанной на применении OpenLDAP (представлена демоном slapd) и протокола Kerberos, механизм единого входа реализуется с использованием технологии SASL (Simple Authentication and Security Layer). В частности, для версии MIT Kerberos 5, используемой в ОССН, в рамках технологии SASL применён механизм GSSAPI (The Kerberos Version 5 Generic Security Service Application Program Interface Mechanism). Таким образом, модель механизма единого входа в ОССН именуется LDAP based on Kerberos (SASL/GSSAPI).

Рисунок 7. Конфигурационный файл для определения источников данных на клиенте домена.

Рис. 8. Конфигурационный файл механизма Kerberos 5 GSSAPI.

Конфигурационным файлом механизма GSSAPI является файл
/etc/gssapi-mech.conf, с котором определяется функция инициализации механизма при вызове библиотеки Kerberos 5 GSSAPI (рис. 8). При этом общим конфигурационным файлом реализации протокола MIT Kerberos 5 является файл /etc/krd5.conf, конфигурация KDC задаётся в файле /etc/krb5kdc/kdc.conf.

Организация механизма «I&А» в пределах глобального пространства имён ЕПП, реализуемого в ОССН, обеспечивает возможность пользователям доменной сетевой инфраструктуры на базе ОССН получать доступ к глобальному пространству ресурсов, поддержка которого возложена на модифицированную реализацию пакета программ Samba, именуемую сетевая защищённая файловая система (СЗФС). СЗФС может функционировать как в составе контроллера домена (выполняющего при этом дополнительные функции файл-сервера), так и в составе клиентов домена, реализующих функции файл-сервера для предоставления доступа к собственным разделяемым ресурсам. Поскольку СЗФС является модификацией пакета программ Samba, она состоит из следующих компонент:

серверного набора программ: демоны smbd и nmbd;
клиентского приложения: smbclient;
набора утилит администрирования: testparam и smbstatus;
конфигурационных файлов: /etc/smbnetfs.conf и /etc/samba/smb.conf.

Дополнительно для администрирования СЗФС имеется графическая утилита «Общие папки (Samba)» (fly-admin-samba), расположенная в меню «Настройки» главного пользовательского меню.

Базовыми компонентами СЗФС являются демоны smbd и nmbd, а также клиентское приложение smbclient. Демон smbd реализует функции сервиса сетевой печати и разделения файлов для клиентских приложений smbclient, функционирующих в рамках доменной сетевой инфраструктуры на базе ОССН, а также клиентских приложений, функционирующих под управлением ОС семейства Microsoft Windows. Конфигурация демона smbd в ОССН задаётся в файле /etc/samba/smb.conf. Демон nmbd по умолчанию реализует функции сервиса имён протокола NetBIOS, а также может использоваться для запроса других сервисных служб имён.

Рассмотренные компоненты доменной сетевой инфраструктуры ОССН требуют конфигурирования в процессе её установки на хосты, реализующие контроллеры и клиенты домена, а также администрирования в процессе эксплуатации домена. Для этого в ОССН имеется служба ALD, схема которой показана на рис. 9.

Таким образом, служба ALD состоит из следующих компонент.

Базовые компоненты, представленные пакетами программ конфигурирования:

Администрирование домена ALD выполняется пользователями, обладающими соответствующими полномочиями. В зависимости от назначенных привилегий администраторов домена ALD можно разделить на следующие группы:

корневой администратор (имя admin/admin) — основной администратор домена ALD, обладающий всеми полномочиями по управлению доменом;
администраторы — пользователи с привилегией admin, обладающие полномочиями по управлению конфигурацией домена и учётными записями пользователей домена;
ограниченные администраторы — пользователи с привилегиями hosts-add или all-hosts-add, обладающие полномочиями по добавлению хостов в состав домена;
пользователи утилит администрирования — пользователи с привилегией a dm-user, обладающие полномочиями по запуску утилит администрирования.

Базовый администратор домена ALD, используя набор программ базовых компонентов службы ALD, а также их расширений и графическую утилиту «Управление политикой безопасности» (.fly-admin-smc) рабочего стола Fly, может выполнять следующие операции:

создание нового домена;
резервирование/восстановление конфигурации домена;
контроль целостности конфигурации домена;
добавление/удаление хостов в состав хостов домена;
управление учётными записями пользователей домена;
управление учётными записями сетевых служб домена;
управление параметрами ОССН, в первую очередь соответствующих МРОСЛ ДП-модели.

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

Настройка сетевого соединения на контроллере домена и хостах рабочих станций пользователей.
Настройка именования сервера и клиентов ALD.
Конфигурирование и запуск сервера ALD на хосте, реализующем функции контроллера домена.
Запуск клиентов ALD на хостах рабочих станций.

На первом этапе учитывается, что способ сетевого соединения контроллера и клиентов домена ALD зависит от типа адресации, используемой в сетевом сегменте. Статическая адресация целесообразна при небольшом числе хостов, входящих в состав домена ALD. При этом сетевой интерфейс каждого хоста, входящего в домен ALD, конфигурируется индивидуально. Динамическая адресация целесообразна при значительном числе хостов, входящих в состав домена ALD или их большой территориальной удалённости. В этом случае на контроллере ALD (или на другом специально выделенном хосте) конфигурируется и запускается сервер динамической сетевой адресации DHCP (Dynamic Host Configuration Protocol).

При небольшом количестве хостов, входящих в домен ALD, такую настройку, как правило, выполняют вручную, конфигурируя файл /etc/hosts (рис. 10). В случае большого количества хостов в составе домена ALD на контроллере домена (или на специально выделенном хосте) конфигурируют службу доменных имён DNS (Domain Name Service).

На третьем этапе конфигурируют серверную и клиентскую части домена ALD, реализованные в виде одного демона aldd:

редактируя файл конфигурации /etc/aid/aid.conf (рис. 11);
запуская или повторно инициализируя демон a ldd с помощью команд ald-init (на контроллере ALD) и aid-client (на клиенте ALD) (рис. 3.46);
конфигурирования параметры пароля базового администратора ALD для реализации сквозной аутентификации на контроллере ALD (рис. 3.47).
Рис. 10. Пример конфигурирования файла /etc/hosts на хосте, реализующем функции контроллера домена.

Рис. 11. Пример конфигурирования файла /etc/ald/ald.conf на хосте, реализующем функции контроллера домена

$C:\Users\SVETLANA\AppData\Local\Temp\FineReader12.00\media\image32.jpg$

Рис. 12. Пример выполнения команды ald-init с параметром commit-config на хосте, реализующем функции контроллера домена

$C:\Users\SVETLANA\AppData\Local\Temp\FineReader12.00\media\image33.jpg$

Рис. 13. Пример выполнения команды ald-init с параметром init на хосте, реализующем функции контроллера домена

На четвёртом этапе базовый администратор домена с использование команды
ald-admin или графическую утилиты «Управление политикой безопасности» (рис. 14, 15) создаёт или редактирует учётные записи пользователей домена, управляет компьютерами домена, а также политиками безопасности на активном сервере ALD.

После настройки и запуска сервера ALD и клиентов домена администратор ALD может выполнять следующие функции:

Astra Linux Directory не сконфигурирована.

Не заполнен /etc/ald/ald.conf

Некорректно настроены имя и ip адрес, например в /etc/hosts отсутствует длинное имя машин:

Ошибка инициализации интерфейса администрирования kadm5. в ALDKadm5Connection.cpp:345(ConnectPassword)

В /etc/ald/ald.conf не указаны длинное имя машины и домен:

Недостаточно энтропии во время инициализации домена.

Утилита hostname должна выдавать короткое имя. После внесения изменений в файл /etc/hostname необходимо перезагрузить машину.

Проверка конфигурации домена. ok

Проверка индексов LDAP. ok

Проверка ограничений уникальности LDAP. ok

Ошибка RPC: Ошибка MIT Kerberos V5: Не удалось получить список принципалов Kerberos. в ALDKadm5Connection.cpp:924(Principals)

При выполнении: ald-client commit-config

ald-init
init
gssapi
error
734
248
345
ошибка
ald
openldap
kerberos

17 Комментариев

Дмитрий Анохов

ald-init init возникает ошибка:

Ошибка при установке ALD соединения.

Дмитрий Анохов

домен astra.da.nu не обнаружен.

компьютер будет подключен к домену astra.da.nu .

Дмитрий Анохов

Нет записи в hosts на обоих машинах. ald-client join по ip.

Дмитрий Анохов

Неверная запись имени сервера в hosts клиента

Константин Ковалевский

На клиенте в файле /etc/hosts не внесены данные о резервном сервере.

Дмитрий Андреев

При попадании табов и пробелов в конце имени домена в параметре DOMAIN=.domain.ald файла /etc/ald/ald.conf

Дмитрий Андреев

В /etc/hosts указано не длинное имя клиента.

Дмитрий Анохов

Не указано длинное имя клиента* ?

Дмитрий Андреев

Константин Ковалевский

Ошибка может быть вызвана применением антивируса или изменением правил iptables.

Проблема оказалась в Dr. Web ESS 10. Spider Gate блокирует порты RPC, его необходимо отключать. При чём, настройки Spider Gate для Linux недоступны, необходимо отключать Spider Gate в ЦУ Dr. Web для группы Everyone для Windows. Ну, или использовать на клиентах не Dr. Web for Workstations а Dr.Web for Fileservers, где этой проблемы не наблюдается.

Егор Сураев

Ошибка при установке ALD соединения.

Ошибка может быть вызвана вводом неправильного пароля при ald-init promote резервного сервера.

Константин Ковалевский

Если при перезапуске ALD выходит ошибка:

Необходимо выполнить команды:

systemctl unmask nmbd
systemctl enable nmbd
systemctl restart nmbd

Егор Сураев

Далее получить новый уже из графики.

Дмитрий Анохов

Марина Яловега

При возникновении ошибки 111 ( Смоленск 1.5):

Добавить в конфигурационный файл /etc/ald/ald.conf параметр USE_RPC, равный нулю

2. Выполнить ald-init restart

Константин Ковалевский

В этом руководстве в роли сервера Kerberos будем использовать ldap-srv. Но ничто не мешает Вам использовать для этого отдельную машину.

9.1 Настройка сервера

Где работаем: ldap-srv

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

В разделе 2.5 мы уже установили схему Kerberos для OpenLDAP сервера, но давайте лишний раз убедимся, что она на месте:

Схема на месте. В ней содержится достаточно много объектов. Чтобы посмотреть их все, используйте следующий запрос:

Эта команда должна вернуть список объектов. Это важно, потому что если новых атрибутов Kerberos LDAP нет, то kdb5_ldap_util(8) выдаст следующую ошибку:

Итак, у нас есть набор схемы данных и объекты. Но есть ли у нас контейнер для принципалов Kerberos?

Нет, нету. Создадим его, а заодно — пользователя и группу, которые будут использоваться Kerberos для взаимодействия с сервером OpenLDAP. Используем для этой цели вот такой LDIF-файл 9.1-kerberos.ldif:

Загрузим этот файл в базу данных нашего сервера каталогов:

Зададим пароль для пользователя krbadmin. Сохраните пароль в надежном месте (например, используя keepass или gpg).

Создадим конфигурационный файл Kerberos /etc/krb5.conf:

Теперь создадим список контроля доступа (ACL) администратора Kerberos. Не путайте этот ACL с ACL OpenLDAP. Это не одно и то же. Чуть ниже мы поработаем с ACL для OpenLDAP. Создадим файл /etc/krb5kdc/kadm5.acl с таким содержимым:

Отредактируем /etc/krb5kdc/kdc.conf, конфигурационный файл службы аутентификации (AS, Authentication Service) и центра распределения ключей (KDC):

Создайте каталог-тайник для пароля. В файле /etc/krb5.conf он указан в переменной ldap_service_password_file :

Извлеките пароль пользователя cn=krbadmin,ou=users,dc=example,dc=com , используя kdb5_ldap_util(8):

Вам будет предложено ввести мастер-пароль базы данных. Очень важно, чтобы Вы НЕ ЗАБЫЛИ этот пароль!

В основном терминале выполните следующую команду для добавления записей Kerberos в базу данных OpenLDAP:

Вышеуказанная команда создаст несколько записей в cn=kerberos,ou=services,dc=example,dc=com . Чтобы увидеть их, выполните запрос:

Но может ли кто-нибудь кроме пользователя cn=admin увидеть нашу информацию Kerberos? Это было-бы не очень мудро. Поэтому давайте взглянём на ACL нашего сервера OpenLDAP:

Что нам надо сделать, так это дать права доступа на чтение/запись администратору Kerberos ( cn=krbadmin,ou=users,dc=example,dc=com ) к поддереву cn=kerberos,ou=services,dc=example,dc=com . Никакой другой пользователь не должен иметь доступа к этой информации (за исключением администратора каталога).

Для этого сформируем LDIF-файл 9.1-kerberos.acl.ldif:

Загрузим данные в сервер каталогов:

Убедитесь, что новые ACL работают. Суперпользователь и пользователь cn=admin,dc=example,dc=com должны иметь доступ к поддереву cn=kerberos,ou=services,dc=example,dc=com . Пользователь cn=nssproxy,ou=users,dc=example,dc=com не сможет обнаружить само существование контейнера Kerberos, а cn=krbadmin,ou=users,dc=example,dc=com должен не только видеть контейнер, но и иметь для него права на чтение/запись. Мы так же должны убедиться, что обычные пользователи всё ещё могут использовать сервер OpenLDAP для аутентификации и что они могут менять себе пароли.

Этот запрос возвращает поддерево cn=kerberos,ou=services,dc=example,dc=com :

Следующий запрос должен завершиться с ошибкой No such object (32) :

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

Где работаем: ldap-client

Где работаем: ldap-srv

Настало время настроить журналирование. Для начала добавим в конфигурацию rsyslog следующие строки (/etc/rsyslog.conf):

Создадим файлы журналов и зададим для них права доступа:

Настроим logrotate. Создадим два конфигурационных файла.

Файл /etc/logrotate.d/krb5kdc для демона krb5-kdc:

Файл /etc/logrotate.d/kadmind для демона krb5-admin-server:

Перезапустим демон rsyslog, чтобы конфигурация вступила в силу. Добавим демоны krb5-kdc и krb5-admin-server в автоматический запуск, затем запустим их:

Загляните в журнал /var/log/krb5kdc.log. Вы должны увидеть там подобную строку:

Проверим, что наши демоны слушают необходимые порты. Порт 88 (krb5kdc), порты 464 и 749 (kadmind):

Поздравляю, теперь у Вас есть рабочий сервер аутентификации (AS) и сервер распределения ключей (KDC) MIT Kerberos 5!

Здесь мы создаём принципал машины для текущего сервера (на котором залогинены). Далее жирный шрифт — вводимый нами текст:

После создания принципала сервера мы можем добавить его в набор ключей Kerberos (/etc/krb5.keytab):

Следующим шагом создадим принципал для моего пользователя pablo и зададим для него пароль:

Теперь создадим принципал пользователя с правами администратора. Помните файл /etc/krb5kdc/kadm5.acl? Вот где он вступает в игру. С помощью этого файла пользователи с префиксом /admin имеют права администратора на доступ к области Kerberos. Это значит, что они могут создавать и удалять записи пользователей и политики доступа. Поэтому убедитесь, что Вы знаете этих пользователей и доверяете им!

Посмотрим список текущих принципалов в области:

Обратите внимание, что был создан новый файл /etc/krb5.keytab. Вот почему мы запустили бинарник kadmin.local от имени суперпользователя. Иначе мы получили бы следующую ошибку:

Только суперпользователь имеет доступ на чтение к файлу-тайнику (/etc/krb5.d/stash.keyfile).

Давайте посмотрим, что записано в /etc/krb5.keytab:

Как мы можем видеть, это список ключей шифрования машины ldap-srv. Неудивительно, что доступ предоставлен только суперпользователю!

Добавим эти индексы в сервер каталогов:

Отлично! Теперь у нас есть настроенный KDC!

9.2 Настройка клиента

С действующим KDC мы можем заставить клиентские машины и сервисы использовать его. Обозначим основные цели по настройке клиентов, чтобы интегрировать их в инфраструктуру Kerberos:

1. Аутентификация Kerberos для sshd.
2. Аутентификация OpenLDAP с помощью SASL GSSAPI.
3. Применение аутентификации SASL GSSAPI для AutoFS.

9.2.1 Аутентификация Kerberos для sshd

Где работаем: ldap-client

ВНИМАНИЕ! Клиенты Kerberos должны иметь возможность подключения к TCP портам KDC с номерами 88 и 749!

Установим необходимые пакеты:

Отредактируйте конфигурацию клиента в файле /etc/krb5.conf следующим образом:

Эта команда создала файл /etc/krb5.keytab.

Теперь мы можем отредактировать /etc/ssh/sshd_config и включить аутентификацию Kerberos. Не забудьте добавить test.group в директиву AllowGroups . Иначе мы не сможем протестировать конфигурацию и увидим ошибку в файле /var/log/auth.log.

Запустите на клиентской рабочей станции отображение файла журнала:

А пока вернёмся на сервер.

Где работаем: ldap-srv

Теперь попробуем авторизоваться на клиенте без пароля, используя этот билет:

Где работаем: ldap-client

В открытом нами журнале на клиенте /var/log/auth.log мы должны увидеть что-то подобное:

Успех! Переходим к следующей цели.

9.2.2 Аутентификация OpenLDAP с помощью SASL GSSAPI

Где работаем: ldap-srv

Для настройки аутентификаци SASL GSSAPI мы должны изменить конфигурацию сервера OpenLDAP таким образом, чтобы он знал о существовании нашей области Kerberos. После этого мы можем настроить клиентов.

Подключимся к KDC и создадим новый принципал. Мы по-прежнему запускаем kadmin от имени суперпользователя, потому что хотим создать новый набор ключей в файле /etc/ldap/krb5.keytab, чтобы наш демон slapd имел свой набор.

Поменяем права доступа на этот файл, чтобы демон slapd смог его читать:

Создадим LDIF-файл 9.2.2-sasl.ldif с директивами SASL:

И загрузим его в базу данных службы каталогов:

На самом деле нам не нужно играться с olcSaslSecProps , но я оставил его, потому что пытался добавить ключевое слово noactive . Если при этом попытаться выполнить поиск, то получим следующую ошибку:

В данный момент такое поведение — не совсем то, что нам нужно. Может быть позже. Сейчас проверим, загрузил ли демон slapd нашу конфигурацию SASL:

Хорошо! Теперь нам нужно добавить параметр KRB5_KTNAME в файл /etc/default/slapd:

Для того, чтобы изменения вступили в силу, нам нужно перезапустить демон slapd:

Демон slapd снова запущен — мы можем переходить к настройке клиента.

Где работаем: ldap-client

Зайдём на клиентскую рабочую станцию по ssh от имени пользователя pablo:

Все настройки для доступа на сервер у нас уже внесены в файл /etc/ldap/ldap.conf. Проверим, можем ли мы сделать запрос к LDAP-серверу:

Такая ошибка может показаться странной. Нужно указать механизм GSSAPI для доступа с помощью SASL. Такой вариант должен сработать:

Супер! Добавленный модификатор мы тоже можем внести в /etc/ldap/ldap.conf, чтобы его не приходилось вбивать вручную каждый раз:

Вы заметили, что OpenLDAP преобразовал имя принципала Kerberos в формат DN (Distinguished Name)? У нас был принципал с таким именем:

… который был преобразован slapd в это:

Это значит нам нужно вернуться на сервер и задать новые правила доступа (ACL), если мы хотим, чтобы наш Kerberos-принципал AutoFS мог читать информацию для автоматического монтирования.

9.2.3 Применение аутентификации SASL GSSAPI для autoFS

Вздохните поглубже, далее от Вас потребуется внимательность и терпение. 😉

Где работаем: ldap-srv

Вернёмся на наш сервер OpenLDAP и отредактируем правила доступа ACL. Но прежде чем мы продолжим, всегда неплохо проверить текущую конфигурацию. Теперь мы можем формировать запросы с использованием GSSAPI (без модификатора -x ):

Запрос вернёт нам четыре DN с атрибутами olcAccess :

Мы должны изменить ACL для olcDatabase= config и olcDatabase= mdb . Приготовьтесь, ACL станут немного сложней. Создадим LDIF-файл 9.2.3-gssapi.acl.ldif и запишем в него:

Ух! Вы поняли все производимые изменения? Напоминаю, что cn=admin,dc=example,dc=com ( RootDN ) всегда имеет полный доступ к olcDatabase= mdb,cn=config . То же касается и olcDatabase= config . Поэтому cn=admin явно не упомянут в ACL. Не волнуйтесь и внимательно прочитайте правила, одно за другим. У Вас всё получится 😉

Изменения масштабные, поэтому сделаем резервную копию на случай, если всё пойдёт наперекосяк:

Загрузим новые ACL в конфигурацию OpenLDAP:

Проверим, что cn=admin,dc=example,dc=com имеет права доступа к базе данных сервера OpenLDAP. Следующий запрос должен вернуть dn: cn=config :

Суперпользователь с UID и GID равными нулю имеет аналогичный уровень доступа:

Такой же уровень доступа имеют принципалы с префиксом /admin. Получим билет принципала и выполним запрос от его имени с помощью SASL:

Проверьте, работают ли права для пользователя cn=nssproxy . Следующая команда должна вернуть все DN из DIT кроме записей, в которых присутствует cn=kerberos :

А могут ли обычные пользователи менять свой пароль? Проверим это с клиентской рабочей станции.

Где работаем: ldap-client

Процесс обновления пароля изменился. Если мы попытаемся запустить команду passwd от имени пользователя, которого нет в локальном файле /etc/passwd, пароль будет изменен с использованием механизмов Kerberos:

Время изменения пароля записывается в принципалах в атрибуте krbLastPwdChange . Запись содержит время по Гринвичу (GMT). Поэтому для начала посмотрим текущее время GMT на клиентской машине:

И наконец, отправим вот такой длиннющий запрос (ответ сервера — только последняя строчка) к серверу каталогов по атрибуту krbLastPwdChange :

Теперь мы можем настроить клиентскую машину для использования механизма GSSAPI в работе с картами автомонтирования AutoFS. На этом этапе Вы должны быть авторизованы на клиентской машине от имени пользователя, домашний каталог которого не лежит на сервере NFS! Если это не так, авторизуйтесь повторно.

Перед тем как продолжить, проверьте, отмонтированы ли все каталоги NFS:

Проверьте общесистемную конфигурацию AutoFS в файле /etc/defaults/autofs:

Заметьте, что атрибут LOGGING установлен в значение debug , а OPTIONS — в -d -v . Это для того, чтобы помочь нам с поиском проблем, если они возникнут. В рабочей конфигурации этот параметр должен быть изменён. Мы вернёмся к этому через пару минут.

Далее нам нужно создать принципал Kerberos для демона autofs. Мы так же должны добавить ключи этого нового принципала в набор ключей нашего клиента.

Как мы можем видеть, ключи autofsclient теперь являются частью набора ключей клиента:

Теперь мы можем изменить порядок аутентификации autofs в файле /etc/autofs_ldap_auth.conf, используя механизм GSSAPI и новый принципал:

Перезапустим демон autofs:

Проверим журнал /var/log/syslog, всё ли работает?

Отлично! Попробуем перейти в каталог /nfs/home:

Супер! Изменим атрибуты LOGGING и OPTIONS в файле /etc/defaults/autofs на повседневные:

И перезапустим демон autofs:

Вот и всё! На этом фокусы с Kerberos закончились. 🙂

В следующем разделе мы опишем, как создавать резервную копию сервера OpenLDAP и восстанавливаться из неё. Затем мы настроим репликацию. Принимая во внимание зависимость наших клиентов от сервера OpenLDAP, нам надо обеспечить некоторый уровень отказоустойчивости.

OpenLDAP и Ubuntu на практике > Kerberos KDC с использованием OpenLDAP в качестве бэкэнда и аутентификацией SASL GSSAPI

Делюсь опытом в описанных технологиях. Блог в первую очередь выполняет роль памяток для меня самого.

12.16.2016

Настройка сети в Astra Linux

Все выполняемые операции требуют привилегий пользователя root.

Astra Linux использует для конфигурирования сетей собственную утилиту wicd. В общем, она довольно удобна, но у неё есть фатальный недостаток - ~~её писали не мы~~ сеть не будет работать до авторизации пользователя в системе. Для обычных компьютеров в этом нет ничего страшного, однако, для сервера это большая проблема, так как иногда его приходится перезагружать по SSH.

Пусть компьютеры будут находиться в сети с адресами 192.168.0.XXX , где вместо XXX - число от 1 до 254.

Настройка осуществляется путем правки файла /etc/network/interfaces . Каждый сетевой интерфейс (сетевая карта, хотя это не совсем точное название) настраивается отдельно. Настройки для сервера выглядят так:

Первая строчка auto lo eth0 указывает, какие интерфейсы должны быть запущены при загрузке ОС. Отмечу, что локальная петля lo должна присутствовать там в любом случае.

Пропустим описание локальной петли и сразу перейдем к сетевому интерфейсу.

iface	Ключевое слово, говорящее о том, что дальше будет описание сетевого интерфейса
eth0	Указываем, что данный сетевой интерфейс должен быть привязан к сетевой карте eth0. Посмотреть список карт можно командой: lshw -class network
inet	Указываем, что это будет настройка сети.
static	При этом все настройки будут указаны вручную.
address	IPv4-адрес компьютера
netmask	Маска подсети.
gateway	Шлюз, т. е. IP-адрес, через который идёт подключение к интернету. Обычно на сервере указывают адрес, выданный провайдером, но в нашем случае (закрытый от мира сегмент) пусть будет 192.168.150.1, т. е. компьютер обращается сам к себе.
dns-nameservers	Список разделенных пробелами IP-адресов DNS-серверов. Полезно при разворачивании ЕПП под управлением Astra Linux и настройке приложения bind.

На клиентских компьютерах настройки следует выполнить аналогичным образом, меняя только четвёртый октет в поле address .

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

Если на одной сетевой карте по каким-то причинам нужно иметь 2 или более IP-адресов, настройки делаются следующим образом:

Посмотреть настройку сети в Debian более подробно можно на официальной Wiki-странице или её несколько устаревшей русской версии

В этом посте мы решили рассказать о доменной аутентификации в Linux, с использованием смарт-карт и USB-токенов JaCarta PKI в качестве второго фактора аутентификации. Если о локальной аутентификации через PAM-модуль информации существует довольно много, то вопрос доменной инфраструктуры и аутентификация по Kerberos-билетам в Linux рассмотрен слабо, особенно на русском языке. В качестве операционной системы возьмем Astra Linux и на примере Astra Linux Directory (ALD) это и покажем.

Выгода такого решения очевидна – оно позволяет отказаться от парольной аутентификации пользователя, что поможет кардинально снизить влияние «человеческого фактора» на безопасность системы. Плюс это даст ряд преимуществ от использования электронных ключей внутри операционной системы, после аутентификации в домене.

Немного вводных об Astra Linux Directory (ALD) и JaCarta PKI

Домен Astra Linux Directory (ALD) предназначен для организации единого пространства пользователей (домена локальной вычислительной сети) в автоматизированных системах.

ALD использует технологии LDAP, Kerberos5, Samba/CIFS и обеспечивает:

централизованное хранение и управление учетными записями пользователей и групп;
сквозную аутентификацию пользователей в домене с использованием протокола Kerberos5;
функционирование глобального хранилища домашних директорий, доступных по Samba/CIFS;
автоматическую настройку файлов конфигурации UNIX, LDAP, Kerberos, Samba, PAM;
поддержку соответствия БД LDAP и Kerberos;
создание резервных копий БД LDAP и Kerberos с возможностью восстановления;
интеграцию в домен входящих в дистрибутив СУБД, серверов электронной почты, Web-серверов, серверов печати и другие возможности.

В среде Astra Linux Directory (ALD) электронные ключи JaCarta PKI могут использоваться для двухфакторной аутентификации пользователя в домене ALD и отказа от паролей. Кроме того, с этими же электронными ключами можно выполнять различные сценарии внутри ОС, после аутентификации, такие, как: электронная подпись, хранение ключевых контейнеров, доступ к Web-ресурсам, проброс ключа в сессии MS Windows. Доступ к VDI сервисам, таким, как VmWare или Citrix.

Процесс настройки

Пример демо-зоны

Сервер — Astra Linux Smolensk SE 1.5 4.2.0-23-generic, x86_64, с установленными пакетами:
- JaCarta IDProtect 6.37;
- libccid;
- pcscd;
- libpcsclite1;
- krb5-pkinit;
- libengine-pkcs11-openssl;
- opensc.
- JaCarta IDProtect 6.37;
- libccid;
- pcscd;
- libpcsclite1;
- krb5-pkinit.
Установка драйверов на сервер и клиент

Для обеспечения работы со смарт-картой JaCarta PKI на клиенте и сервере установите следующие пакеты: libccid, pcscd, libpcsclite1. После установки этих обязательных пакетов установите пакет драйверов IDProtectClient, который можно загрузить с официального сайта «Аладдин Р.Д.».

Для обеспечения работы со смарт-картой подсистемы Kerberos добавочно к предустановленным пакетам ald/kerberos установите пакет krb5-pkinit на клиенте и сервере.

Для обеспечения возможности выпуска ключей и сертификатов на JaCarta PKI на сервере также установите пакеты libengine-pkcs11-openssl и opensc.

Установка и настройка центра сертификации на сервере

В качестве центра сертификации (CA) будет использован OpenSSL.

OpenSSL — криптографический пакет с открытым исходным кодом для работы с SSL/TLS. Позволяет создавать ключи RSA, DH, DSA и сертификаты X.509, подписывать их, формировать CSR и CRT.
Подготовка смарт-карты. Выпуск ключей и сертификата пользователя

Убедитесь в том, что установлены пакеты libengine-pkcs11-openssl и opensc. Подключите устройство, которое следует подготовить.

Проинициализируйте устройство, установите PIN-код пользователя. Помните, что инициализация устройства удалит все данные на JaCarta PKI без возможности восстановления.

Для инициализации необходимо воспользоваться утилитой pkcs11-tool.

pkcs11-tool --slot 0 --init-token --so-pin 00000000 --label 'JaCarta PKI' --module /lib64/libASEP11.so,

--slot 0 — указывает, в какой виртуальный слот подключено устройство. Как правило, это слот 0, но могут быть и другие значения – 1,2 и т.д.;

--init-token – команда инициализации токена;

--so-pin 00000000 – PIN-код администратора JaCarta PKI. По умолчанию имеет значение 00000000;

--label 'JaCarta PKI' – метка устройства;

--module /lib64/libASEP11.so — указывает путь до библиотеки libASEP11.so. Устанавливается в рамках пакета idprotectclient см. раздел «Установка драйверов на сервер и клиент».

Для задания PIN-кода пользователя используйте команду:

pkcs11-tool --slot 0 --init-pin --so-pin 00000000 --login --pin 11111111 --module /lib64/libASEP11.so,

--slot 0 — указывает, в какой виртуальный слот подключено устройство. Как правило, это слот 0, но могут быть и другие значения – 1,2 и т.д.;

--init-pin – команда установки PIN-кода пользователя;

--so-pin 00000000 – PIN-код администратора JaCarta PKI. По умолчанию имеет значение 00000000;

--login – команда логина;

--pin 11111111 – задаваемый PIN-код пользователя;

--module /lib64/libASEP11.so — указывает путь до библиотеки libASEP11.so. Устанавливается в рамках пакета idprotectclient см. раздел «Установка драйверов на сервер и клиент».

Сгенерируйте ключи на устройстве, для этого введите следующую команду:

pkcs11-tool --slot 0 --login --pin 11111111 --keypairgen --key-type rsa:2048 --id 42 --label “test1 key” --module /lib64/libASEP11.so,

--slot 0 — указывает, в какой виртуальный слот подключено устройство. Как правило, это слот 0, но могут быть и другие значения – 1,2 и т.д.;

--login --pin 11111111 — указывает, что следует произвести логин под пользователем с PIN-кодом «11111111». Если у Вашей карты другой PIN-код пользователя, укажите его;

--keypairgen --key-type rsa:2048 — указывает, что должны быть сгенерированы ключи длиной 2048 бит;

--id 42 — устанавливает атрибут CKA_ID ключа. CKA_ID может быть любым;

Запомните это значение! Оно необходимо для дальнейших шагов подготовки устройства к работе.

--label “test1 key” — устанавливает атрибут CKA_LABEL ключа. Атрибут может быть любым;

--module /lib64/libASEP11.so — указывает путь до библиотеки libASEP11.so. Устанавливается в рамках пакета idprotectclient см. раздел «Установка драйверов на сервер и клиент».

Сгенерируйте запрос на сертификат с помощью утилиты openssl. Для этого введите следующие команды:

Обратите внимание на -new -key 0:42, где 0 — номер виртуального слота с устройством, 42 — атрибут CKA_ID сгенерированных раннее ключей.

Информацию, которую необходимо указать в запросе, следует задавать в поле "/C=RU/ST=Moscow/L=Moscow/O=Aladdin/OU=dev/CN=test1 (! Ваш_Пользователь!)/emailAddress=test1@mail.com".

Необходимо установить переменные окружения

и выпустить сертификат на пользователя.

$ openssl x509 -CAkey cakey.pem -CA cacert.pem -req -in client.req -extensions client_cert -extfile pkinit_extensions -out client.pem –days 365

Далее перекодируйте полученный сертификат из PEM в DER.

Запишите полученный сертификат на токен.

pkcs11-tool --slot 0 --login --pin 11111111 --write-object client.cer --type 'cert' --label 'Certificate' --id 42 --module /lib/libASEP11.so,

--slot 0 — указывает, в какой виртуальный слот подключено устройство. Как правило, это слот 0, но могут быть и другие значения – 1,2 и т.д.;

--login --pin 11111111 — указывает, что следует произвести логин под пользователем с PIN-кодом «11111111». Если у Вашей карты другой PIN-код пользователя, укажите его;

--write-object ./client.cer — указывает, что необходимо записать объект и путь до него;

--type 'cert' — указывает, что тип записываемого объекта – сертификат;

'cert' --label 'Certificate' — устанавливает атрибут CKA_LABEL сертификата. Атрибут может быть любым;

--id 42 — устанавливает атрибут CKA_ID сертификата. Должен быть указан тот же CKA_ID, что и для ключей;

--module /lib64/libASEP11.so — указывает путь до библиотеки libASEP11.so.

Настройка клиента. Проверка работоспособности

Создайте на клиенте каталог /etc/krb5/. Скопируйте в /etc/krb5/ сертификат CA (cacert.pem) c сервера.

Настройте kerberos в /etc/krb5.conf. Секцию [libdefaults] дополните следующими строками.

kinit Когда появится строка запроса PIN-кода к карте, введите его.

Для проверки того, что kerberos-тикет был успешно получен для пользователя, введите команду klist. Для удаления тикета — kdestroy.

Для входа в домен по смарт-карте на экране входа в ОС вместо пароля введите PIN-код от смарт-карты.

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

Читайте также:

Ald сервер домена не обнаружен astra linux

17 Комментариев

Дмитрий Анохов

Дмитрий Анохов

Дмитрий Анохов

Дмитрий Анохов

Дмитрий Анохов

Константин Ковалевский

Дмитрий Андреев

Дмитрий Андреев

Дмитрий Анохов

Дмитрий Андреев

Константин Ковалевский

Егор Сураев

Константин Ковалевский

Егор Сураев

Дмитрий Анохов

Марина Яловега

Константин Ковалевский

9.1 Настройка сервера

9.2 Настройка клиента

9.2.1 Аутентификация Kerberos для sshd

9.2.2 Аутентификация OpenLDAP с помощью SASL GSSAPI

9.2.3 Применение аутентификации SASL GSSAPI для autoFS

12.16.2016

Настройка сети в Astra Linux

Немного вводных об Astra Linux Directory (ALD) и JaCarta PKI

Процесс настройки

Пример демо-зоны

Установка драйверов на сервер и клиент

Установка и настройка центра сертификации на сервере

Подготовка смарт-карты. Выпуск ключей и сертификата пользователя

Настройка клиента. Проверка работоспособности