Программный комплекс ALD Pro – это служба каталога для Linux. Он позволяет управлять парком компьютеров организации с помощью групповых политик через интуитивно понятный интерфейс. Дополнительно в системе реализованы функции автоматизированной установки ОС и ПО по сети на компьютеры в домене, удаленный доступ к рабочим столам пользователей и мониторинг состояния сервисов службы каталога.
Рекомендации по именованию домена ALD Pro и компьютеров в нем:
- Используйте свой домен третьего уровня, например, ald.mycompany.ru.
- Если вы не хотите использовать публичный домен, то можно задействовать зоны «.lan» или «.internal», например, ald.company.lan. Зоны «.lan» и «.internal» не зарегистрированы в глобальном списке Top-Level Domains, но всегда будет оставаться вероятность, что их ведут в эксплуатацию в будущем и они будут также с проблемой разрешения имен.
- Не используйте зону «.local» (например ald.mycompany.local) в качестве частного домена верхнего уровня для внутренних нужд предприятия, в этом случае вы столкнетесь с конфликтами Multicast DNS (RFC6762) и невозможностью использования протокола zeroconf, который реализован в Linux службой Avahi. Если в Вашей сети будет работать устройство (например маршрутизатор), на котором Avahi есть, но не настроен, то на все имена *.local он будет отвечать одинаковым IP адресом.
- В стандарте доменных имен (RFC1034) разрешается использовать заглавные буквы латинского алфавита A-Z, но служба каталога FreeIPA налагает дополнительные требования и обязует использовать только нижний регистр символов. Если вы в команде ввода в домен укажите имя хоста большими буквами, то процедура завершиться ошибкой. Если поменять имя хоста на заглавные (например, REPO.ald.local) после ввода в домен, то вы столкнетесь с ошибками при установке подсистем на такие хосты.
- Выберите префикс, который вряд ли устареет и не изменится в будущем, содержащий только стандартные символы Интернета a–z, 0–9 и (-), но не полностью числовые. Он должен быть длинной не более 15 символов, потому что первый компонент доменного имени будет использован в качестве NetBIOS-имени. Учитывайте, что два домена не смогут работать в доверительных отношениях, если у них будут совпадать NetBIOS-имена, например, если у вас текущий домен AD DS имеет имя corp.mycompany.com, то не стоит для домена «ALD Pro» использовать имя corp.mycompany.ru. Иначе вы не сможете создать между этими доменами доверительные отношения. Замена имени домена это очень сложная процедура, это связано с хешированием паролей. В Kerberos-ключах используется производная от Principal Name в качестве соли. Поэтому смена имени приведет к смене всех паролей в домене.
Рекомендации по планированию ресурсов службы каталога
- HDD. В работе службы каталога преобладают операции чтения, поэтому в производительности контроллера решающую роль играет достаточный объем оперативной памяти, чтобы контроллер мог обрабатывать запросы без обращения к медленным дискам. Файлы каталога расположены в папке /var/lib/dirsrv, после развертывания первого контроллера размер базы составляет порядка 45 Мб и увеличивается по мере создания объектов, в среднем по 30 КБ на каждую дополнительную учетную запись пользователя. Таким образом размер файлов на диске можно рассчитать математически: для нужд самой операционной системы контроллеру следует выделить порядка 30 ГБ, а под хранение каталога для упрощения расчетов возьмем по 1ГБ на каждые 35 тысяч объектов. Расчетное значение должно составлять не более 40% от доступного пространства.
HDD, ГБ = 30 + N объектов / 35000
- ОЗУ. Для загрузки каталога требуется больше оперативной памяти, чем на диске, т. к. для ускорения операций поиска служба ns-slapd индексирует данные каталога. Пустая база данных занимает в памяти порядка 65 Мб и это значение растет по мере увеличения числа объектов, в среднем по 50 КБ на каждую дополнительную учетную запись. По ходу работы службы каталога для ускорения операций чтения происходит кеширование запросов, и потребление оперативной памяти возрастает до 100 КБ на каждую учетную запись каталога. Таким образом минимально необходимый объем оперативной памяти можно рассчитать математически: для нужд самой операционной системы контроллеру следует выделить порядка 2-3 ГБ, а для работы с каталогом в целях упрощения расчетов возьмем по 1ГБ на каждые 10 тысяч объектов:
ОЗУ, ГБ = 3 + N объектов / 10 000
Для работы с каталогом, в котором содержится 10 000 пользователей и 100 групп, контроллеру нужно выделить порядка 4ГБ ОЗУ:
ОЗУ, ГБ = 3 + 10 100 объектов / 10 000 ≈ 4 Гб ОЗУ
- CPU. Если требуемый объем оперативной памяти зависит от размера базы данных, то количество ресурсов центрального процессора определяется тем, сколько активных пользователей должен обслуживать конкретный контроллер.
ЦПУ потоков = (1 + N обслуживаемых пользователей / 1000) * 2
- Пропускная способность сети. В процессе обслуживания клиентов контроллеры домена, как правило, получают небольшие входящие запросы на предоставление относительно больших объемов данных, поэтому на контроллерах обычно преобладает исходящий трафик. При количестве пользователей до 5 000 будет достаточно интерфейса с пропускной способностью в 100 Мбит/с, а если предполагается обслуживать больше пользователей, то установите на контроллере интерфейс с пропускной способностью в 1 Гбит/с.
Эти требования по производительности относятся к LDAP + Kerberos, в реальности ресурсов нужно больше.
В следующих версиях ALD Pro ожидается снижение требований к ресурсам.
Минимально для развертывания на стенде контроллера домена ALD Pro 2.2.1 требуется CPU -2 ядра, RAM - 4 Гб, SSD - 30 ГБ. На моем стенде контроллеру выделено CPU - 8 ядер, RAM - 8 Гб, SSD - 100 ГБ.
Требования к ОС Astra Linux
Контроллер домена ALD Pro можно устанавливать на Astra Linux 1.7.2, Astra Linux 1.7.3, Astra Linux 1.7.4, максимальный уровень защищенности (Смоленск). Если планируете использовать поддержку глобального каталога, то нужно использовать Astra Linux 1.7.4.
Предварительные настройки ОС
- Нужно убедиться в правильности версии Astra Linux и в том что система работает в максимальном уровне защищенности (Смоленск):
sudo cat /etc/astra/build_version
sudo astra-modeswitch getname
- Установку контроллера домена необходимо производить под высоким уровнем целостности (63) учетной записи администратора. Убедитесь, что Вы работаете под высоким уровнем целостности (63-й уровень МКЦ):
sudo pdp-id - смотрим по каким уровнем МКЦ работаем
sudo id - смотрим под каким пользователем работаем
- Отключите службу NetworkManager. Если Вы установили Astra Linux с графикой, то по умолчанию у Вас работает демон NetworkManager - менеджер сетевых подключений. NetworkManager может динамически менять настройки, что крайне полезно для рабочих станций, но может быть неудобно на серверах. NetworkManager рекомендуется использовать на рабочих станциях, однако на серверах рекомендуется использовать службу Networking (команды ifup/ifdown) как более легковесную. Нужно остановить службу NetworkManager, затем выключить и накинуть на нее маску, чтобы ее нельзя было случайно запустить.
sudo systemctl stop NetworkManager
sudo systemctl disable NetworkManager
sudo systemctl mask NetworkManager
sudo systemctl status NetworkManager
В AstraLinux Special Edition до версии 1.7.4 служба называлась network-manager, поэтому нужно было выполнять следующие команды:
sudo systemctl stop network-manager
sudo systemctl disable network-manager
sudo systemctl mask network-manager
sudo systemctl status network-manager
- Подключение репозиториев. Файлы программ Linux объединяются в пакеты и распространяются через специальные хранилища, называемые репозиториями. Основным файлом для хранения списка доступных репозиториев является /etc/apt/sources.list, дополнительные списки могут храниться в файлах *.list в директории /etc/apt/sources.list.d/. По умолчанию Astra Linux предлагает использовать репозитории stable, которые соответствуют последней версии операционной системы, но для работы с ALD Pro требуется переключить репозитории на frozen, чтобы гарантировать полную совместимость пакетов. Обязательными для версии ALD Pro 2.2.1 являются репозитории base и aldpro. В репозитории base продублированы репозитории main и update, поэтому можно указывать base вместо main и update. Пакеты из репозитория extended продублированы в репозитории aldpro, поэтому в данном случае репозиторий extended можно не указывать. Т.е. нужно указать репозитории или main + update + aldpro или base + aldpro.
sudo vim /etc/apt/sources.list - добавляем репозитории main и update или base.
Необходимо так же создать отдельный список для ALD Pro в файле /etc/apt/sources.list.d/aldpro.list командой:
sudo vim /etc/apt/sources.list.d/aldpro.list - добавляем репозиторий для установки пакетов самого ALD Pro.
После изменения состава репозиториев следует обновить индекс доступных пакетов с помощью команды:
sudo apt update - обновляем индексы пакетов
Обновление правильно делать в два шага. Сначала менять репозитории операционной системы и вызвать astra-update. Затем менять репозитории продукта и делать dist-upgrade. Операционная система и продукт используют разные стратегии обновления.
apt list --upgradable - посмотреть какие пакеты мы можем обновить
sudo apt dist-upgrade -y -o Dpkg::Options::=--force-confnew - обновить пакеты
- Настройка сетевого интерфейса. После отключения NetworkManager сетевые настройки нужно задавать в файлах interfaces и resolv.conf. Файл /etc/network/interfaces используется командами ifup/ifdown для конфигурирования сетевых интерфейсов. Служба каталога тесно интегрирована со службой разрешения имен, поэтому контроллер домена выступает еще и в качестве DNS-сервера. Адреса DNS-серверов через DHCP или вручную распространяются по хостам всей сети, поэтому на контроллере домена настоятельно рекомендуют устанавливать статический адрес. Командой ip a, смотрим какие есть сетевые интерфейсы на компьютере и настраиваем один из них в файле /etc/network/interfaces.
ip a
sudo nano /etc/network/interfaces
После настройки сетевого интерфейса выполняем следующие команды:
sudo ip addr flush dev eth0 - очищаем старое соединение
sudo systemctl restart networking - перезапускаем службу networking
sudo systemctl status networking - проверяем, что служба запустилась без ошибок
ping -c 4 10.0.2.1 - проверим что сеть работает пингом по IP адресу, например, маршрутизатора или любого доступного узла.
- Настройка имени хоста. Имя хоста должно быть задано в формате полного имени FQDN. При данном подходе вызов команды hostname без параметров будет выдавать FQDN хоста.
Если устанавливать имя хоста напрямую в файле /etc/hostname, то изменения вступят в силу только после перезагрузки, поэтому в Astra Linux рекомендуется это делать с помощью утилиты hostnamectl:
sudo hostnamectl set-hostname dc1.ald.local - присвоить хосту полное доменное имя FQDN
- Настройка файла /etc/resolv.conf. Для возможности обращения к публичным репозиториям следует настроить функцию разрешения имен. Файл /etc/resolv.conf определяет настройки для процедур разрешения имен из библиотеки glibc, которая используется в сетевых утилитах ping, dig и т. д. В этом файле следует указать бесплатный сервер разрешения имен от Яндекс.
sudo vim /etc/resolv.conf
можно проверить доступность репозитория Astra Linux в интернет
ping dl.astralinux.ru
- Настройка файла /etc/hosts. Для того чтобы имя контроллера всегда могло быть преобразовано в IP адрес, даже при недоступности DNS сервиса, в файл /etc/hosts требуется добавить строку, соответствующую его FQDN. В эту строку рекомендуется вписать не только полное, но короткое имя хоста, только первым по списку обязательно должно идти полное имя хоста, т. к. первое имя считается каноническим и будет возвращаться командой hostname -f, что требуется для корректной работы скриптов автоматизации. Писать имена необходимо в нижнем регистре. Еще крайне важно удалить строку (или закоментировать), связывающую имя хоста с адресом localhost, т. к. эти адреса имеют выше приоритет, а нам крайне важно, чтобы имя хоста разрешалось в локальный адрес, потому что некоторые службы могут прослушивать порты только на этом адресе.
sudo vim /etc/hosts
Устанавливаем пакеты ALD Pro.
Первым шагом необходимо установить соответствующие пакеты, для этого выполните команду:
sudo DEBIAN_FRONTEND=noninteractive apt-get install -q -y aldpro-mp aldpro-gc aldpro-syncer
Обязательно нужно установить пакет aldpro-mp - это пакет портала управления, остальные два пакета нужны только в случае интеграции с Microsoft AD. Если планируется использовать расширенные функции интеграции с доменом Microsoft Active Directory, то нужно выполнить установку модуля синхронизации aldpro-syncer, который обеспечивает поддержание целостности в двух доменах ald и adds. В этом случае в двух доменах будет один и тот же состав пользователей и групп, синхронизироваться будет необходимый список атрибутов, включая пароли. Это позволит пользователям получать доступ к любым информационным системам по логину и паролю вне зависимости от того, через контроллер какого домена информационная система проверяет аутентичность пользователей. Если планируется использовать двусторонние доверительные отношения с лесом доменов Microsoft Active Directory, то нужно дополнительно установить модуль глобального каталога aldpro-gc. В этом случае будет работать поиск объектов из домена «ALD Pro» в стандартных приложениях MS Windows. Модуль глобального каталога устанавливается на стороне ALD Pro, он берет данные из LDAP каталога ALD Pro и кладет их копию в базу данных, которая доступна на порту 3268 в той схеме данных, которую ожидает увидеть MS Active Directory. И когда мы в доверенном домене MS AD назначая права доступа выполняем поиск по объектам леса ALD Pro, то в этот момент запрос идет к глобальному каталогу доверенного леса ALD Pro, и чтобы на этот запрос был предоставлен ответ в том виде, в каком ожидает его приложение MS Windows, для этого на стороне ALD Pro и нужен модуль глобального каталога aldpro-gc. Например, когда администратор, открыв свойства сетевой папки, выбирает добавление объекта (например пользователя), затем найти его в доверенном лесу ALD Pro и добавить его в ACL (назначить ему права на эту папку).
Запуск скрипта продвижения домена
Пароль в команде запуска скрипта указывается в открытом виде. Поэтому нужно отключить историю команд, чтобы пароль не был в нее записан, можно использовать пробел перед вводом команды с паролем.
set +o history
Запускаем команду продвижения контроллера домена:
sudo aldpro-server-install -d ald.local -n dc1 -p 'P@ssw0rd' --ip 10.0.2.7 --no-reboot
- -d - указываем имя домена (ald.local)
- -n - указываем имя хоста (dc1). Если Вы не поменяли имя хоста или оно просто на данный момент другое, то скрипты автоматически поменяют существующее имя хоста на то, которое указано в команде
- -p - указываем пароль, который будет у доменного администратора admin
- --ip - указываем IP адрес хоста. Если он в данный момент другой, то скрипты его поменяют на тот, который указан в команде
- --no-reboot - дает возможность посмотреть на лог, до перезагрузки
При необходимости установки модуля синхронизации и/или
глобального каталога добавляются ключи --setup_syncer и/или --setup_gc
соответственно.
После того как скрипт отработал можно включить ведение истории команд:
set-o history
Проверьте настройки cat /etc/resolv.conf. В обновленном скрипте установки этот файл настраивается на службу bind и поиск имен в домене ald.local. Если файл resolv.conf по прежнему обращается на 77.88.8.8, то замените его содержимым:
Контроллер домена установлен, для применения изменений выполните перезагрузку сервера:
sudo reboot
После загрузки сервера войдите в систему, под высоким уровнем целостности, используя доменную учетную запись администратора:
Окно для входа может отобразиться раньше, чем станут доступны доменные службы, поэтому вход доменной учетной записью может стать доступен не сразу. Пока не станет доступна LDAP-служба, в списке источников учетных данных вместо имени домена будет отображаться "Ожидание ответа домена...". Пока не станет доступна KDC-служба, вы не сможете успешно пройти аутентификацию на сервере новым пользователем, у которого еще не сохранены учетные данные в кэше SSSD службы.
Поэтому, если у вас не получилось войти на сервер под доменной учетной записью сразу, подождите пару минут и попробуйте еще раз. Если доступ так и не появился, подключитесь к серверу локальной учетной записью и проверьте журналы /var/log/auth.log и /var/log/messages.
Чтобы проверить доступность доменных служб вы всегда можете войти локальным пользователем и воспользоваться утилитой ipactl:
sudo ipactl status
Проверка работы и настройка нового контроллера домена
Проверка выдачи Kerberos TGT-билета
При успешном входе под доменной учетной записью, TGT-билет должен был появиться в хранилище билетов.
Проверка работы портала управления на контроллере домена
Для доступа на портал управления откройте на контроллере домена браузер Mozilla Firefox, адрес портала будет установлен страницей по умолчанию: https://dc1, и вы увидите предупреждение в связи с невозможностью проверки сертификата. Начальную страницу контроллере домена для браузера Firefox задана политикой, которую можно посмотреть в файле /usr/lib/firefox/distribution/policies.json
Заменим «плоский» адрес портала https://dc1 на FQDN https://dc1.ald.local
Перезапустим веб-сервер Apache
sudo systemctl restart apache2.service
Откроем браузер заново и убедимся, что мы попали на страницу с порталом ALD Pro по его полному имени и кликнем на ссылку «Вход с Kerberos».
При этом будет предпринята попытка прозрачной аутентификации по Kerberos, но для этого в связке ключей пользователя уже должен быть TGT-билет. В случае успешной аутентификации, вы увидите соответствующее уведомление в нижней левой части экрана и портал управления ALD Pro.
Если же билета нет, то будет высвечено сообщение о провале аутентификации с Kerberos.
Для того что бы получить билет Kerberos, в консоли необходимо выполнить команду kinit admin.
С помощью утилиты klist можно удостовериться, что аутентификация на портале прошла именно по Кerberos - в связке ключей появится сервисный билет на доступ к службе HTTP/dc1.ald.local@ALD.LOCAL
Отключение DNSSEC
Служба bind9 по умолчанию использует механизм DNSSEC для проверки ответов, но его лучше отключить, т. к. технология все еще не получила широкого распространения, и ошибки в настройках зон могут приводить к невозможности разрешения имен. Для этого в файле /etc/bind/ipa-options-ext.conf для параметра «dnssec-validation» рекомендуется задать значение «no». Сделать это можно командой:
sudo sed -i 's/dnssec-validation yes/dnssec-validation no/g' /etc/bind/ipa-options-ext.conf
Проверим, что настройки применились командой:
sudo grep "dnssec-validation" /etc/bind/ipa-options-ext.conf
Разрешение рекурсивных запросов и кеширования
Еще одной особенностью настроек bind9 по умолчанию является запрет на обработку рекурсивных DNS запросов от клиентов, находящихся за пределами той же подсети, в которой находится сам DNS-сервер. Сделано это для предотвращения DDoS-атак с DNS-усилением, но эта защита не актуальна для контроллеров домена, которые работают в закрытом периметре, поэтому в файле ipa-options-ext.conf рекомендуется задать также значение «any» для параметров «allow-recursion» и «allow-query-cache» или определить в файле /etc/bind/ipa-ext.conf список доверенных сетей.
Изменим настройки bind командой:
sudo tee -a /etc/bind/ipa-options-ext.conf> /dev/null<<EOT
allow-recursion { any; };
allow-query-cache { any; };
EOT
Проверим, что настройки применились командой:
sudo grep "allow" /etc/bind/ipa-options-ext.conf
Для применения изменений, необходимо перезапустить DNS службу на контроллере домена:
sudo systemctl restart bind9-pkcs11.service
Настройка глобального перенаправления DNS запросов
Если до установки пакетов «ALD Pro» перенаправление DNS-запросов на localhost (127.0.0.1) привело бы к отказу в работе механизма разрешения имен, то сейчас этого не произойдет, т. к. в системе работает сервис bind9, который выполняет функцию рекурсивного разрешителя имен. Bind9 сам находит запрашиваемые DNS-записи, последовательно обращаясь ко всем DNS серверам, обслуживающим зону, начиная с корневой (см. файлы /etc/bind/named.conf.default-zones и /usr/share/dns/root.hints).
Настройка глобального перенаправления осуществляется на портале управления ALD Proна вкладке «Глобальная конфигурация DNS» ( Роли и службы сайта - Служба разрешения имен - Глобальная конфигурация DNS ).
Добавим глобальный пененаправитель. Нажмем на кнопку «добавить» и введем адрес DNS сервера. Рекомендуется установить адрес публичного DNS, например, от Яндекс 77.88.8.8. Политику перенаправления рекомендуется выбрать «Только перенаправлять» или «Сначала перенаправлять»:
- Только перенаправлять — сервер запрашивает ответ только у серверов пересылки.
- Сначала перенаправлять — сервер запрашивает ответ у серверов пересылки. Если ответ не найден, сервер пытается разрешить запрос самостоятельно.
Для сохранения и применения изменений, нажмем кнопку «Сохранить» в правом верхнем углу.
Проверить настройки DNS службы можно из командной строки от root пользователя:
sudo ipa dnsconfig-show
На этом развертывание первого контроллера ALD Pro 2.2.1 окончено. Дополнительно можно посмотреть видео о развертывании первого контроллера.
Список (пополняемый) других вышедших материалов об ALD Pro:
1. Установка первого контроллера домена ALD Pro 2.2.1:
2. Ввод клиента в домен ALD Pro
3. Установка резервного контроллера домена ALD PRO 2.2.1:
4. Механизм репликации в ALD Pro 2.2.1