Модуль 11. Подсистемы ALD Pro и интеграция со сторонними приложениями
Введение
Из этого модуля вы узнаете о том, как устроены подсистемы, обеспечивающие управление локальными репозиториями, общий доступ к принтерам, мониторинг и аудит. Мы также рассмотрим вопросы интеграции службы каталога со сторонними клиент-серверными приложениями.
Подсистема «Репозиторий программного обеспечения»
Система Astra Linux является деривативом Debian, поэтому приложения устанавливаются из deb-пакетов, которые распространяются через специальные APT-совместимые репозитории. В свое время идея Debian поставлять систему с набором заранее скомпилированных и четко согласованных пакетов стала настоящей революцией в мире Linux.
До этого для установки дополнительного программного обеспечения пользователям нужно было обладать квалификацией на уровне системного программиста. Требовалось разобраться, из каких компонентов состоит приложение, каких версий должны быть эти компоненты, в каком порядке их нужно компилировать и устанавливать в системе. А теперь apt install
, и можно пользоваться.
Как вы уже знаете, официальные интернет-репозитории операционной системы Astra Linux доступны по адресу https://download.astralinux.ru и включают в себя четыре основных раздела: main, update, base, extended. Репозитории main и update попадают под сертификацию, репозиторий base включает пакеты main и update, а также содержит некоторые дополнительные средства разработки. Репозиторий extended содержит дополнительное программное обеспечение, которое может функционировать в среде Astra Linux, но не дорабатывается для реализации функций безопасности.
В официальных репозиториях находятся тысячи пакетов, готовых к установке, но вам все равно могут потребоваться собственные корпоративные репозитории, например, для установки приложений сторонних разработчиков или эксплуатации системы в закрытом периметре. Для решения этой задачи в продукте ALD Pro есть специальная подсистема на базе Reprepro и Apache.
Репозитории пакетного менеджера APT
Мы уже рассматривали подробно устройство deb-пакетов и работу пакетного менеджера APT (см. Модуль 15. Управление ПО в Astra Linux), поэтому напомним только основные моменты.
Менеджер APT может извлекать пакеты по протоколу HTTP(S), для чего в файле sources.list
требуется задать источник в определенном формате, см. рис. 330.
Назначение элементов синтаксиса:
deb — указывает на то, что репозиторий соответствует репозиторию бинарных файлов с предварительно скомпилированными пакетами. Для репозиториев с исходными кодами используют «deb-src».
https://download.astralinux.ru/astra/stable/1.7_x86-64/repository-main/ — задает адрес репозитория. У интернет-репозиториев адрес начинается с
http(s)://
, адреса локальных репозиториев начинаются сfile:/
. При добавлении репозитория с диска командойsudo apt-cdrom add
в файле появится строкаdeb cdrom:[]
.1.7_x86-64 — кодовое имя дистрибутива. В одном репозитории могут находиться пакеты сразу для нескольких релизов.
main contrib non-free — это группы пакетов, которые объединяются по условиям использования:
non-free ― группа содержит пакеты, которые не соответствуют принципам свободного ПО, имеют патенты или другие юридические ограничения;
contrib ― группа содержит пакеты, которые сами по себе соответствуют принципам свободного ПО, но зависят от пакетов из группы non-free (т. е. не могут без них работать);
main ― группа содержит пакеты свободного ПО, которые не зависят от пакетов из групп contrib и non-free.
Репозиторий представляет собой просто папку с файлами на веб-сервере, но пакеты свалены не в одну кучу, а распределены по каталогам и дополняются файлами с метаинформацией, что позволяет ускорить индексацию репозиториев на клиентских машинах. Для индексации пакетов менеджер загружает в первую очередь файл Release или InRelease по следующему URL-адресу: <полный_путь>/dists/код_дистрибутива/
(от англ. dists — это сокращение от distributions, т.е. дистрибутивы).
Исследовать содержимое репозиториев Astra затруднительно, т. к. на серверах отключен просмотр содержимого папок, но вы можете обратиться к официальному репозиторию Debian. Например, файл InRelease для Debian 10 Buster находится по адресу: https://deb.debian.org/debian/dists/buster/InRelease
.
Вот пример содержимого InRelease файла:
admin@dc-1:~$ curl https://deb.debian.org/debian/dists/buster/InRelease
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Origin: Debian
Label: Debian
Suite: oldoldstable
Version: 10.13
Codename: buster
Changelogs: http://metadata.ftp-master.debian.org/changelogs/@CHANGEPATH@_changelog
Date: Sat, 10 Jun 2023 08:53:33 UTC
Acquire-By-Hash: yes
Architectures: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x
Components: main contrib non-free
Description: Debian 10.13 Released 10 September 2022
MD5Sum:
...
bb284daaa0f0afdb56e4e95bd16e8bdc 10688592 main/binary-i386/Packages.gz
f3d4bcfbd689fef5c5ffb9f8a9148eb0 7865552 main/binary-i386/Packages.xz
588bad28a94db77998ce094cb82f2728 122 main/binary-i386/Release
...
В файле InRelease перечислены индексные файлы дистрибутива, которые пакетный менеджер выкачивает по указанным ссылкам. Например, для обработки ссылки main/binary-i386/Packages.gz
менеджер apt загрузит файл https://deb.debian.org/debian/dists/buster/main/binary-i386/Packages.gz.
Индексные файлы пакетов содержат метаинформацию по каждому из пакетов. Например, пакет freeipa-client относится как раз к main, и мы найдем информацию о нем в файле Packages.gz
:
...
Package: freeipa-client
Source: freeipa
Version: 4.7.2-3
Installed-Size: 298
Maintainer: Debian FreeIPA Team <pkg-freeipa-devel@alioth-lists.debian.net>
Architecture: i386
Replaces: freeipa-admintools (<< 4.6.3-2~)
Provides: freeipa-admintools
Depends: bind9utils, certmonger (>= 0.79.5-2), curl, dnsutils, freeipa-common (= 4.7.2-3), krb5-user, libnss3-tools, libnss-sss, libpam-sss, libsasl2-modules-gssapi-mit, libsss-sudo, libxmlrpc-core-c3
(>= 1.16.33-3.1ubuntu5), oddjob-mkhomedir, python-dnspython, python-ipaclient (= 4.7.2-3), python-gssapi, python-ldap, python-sss, sssd (>= 1.14.0), python:any, libbasicobjects0 (>= 0.4.0), libc6 (>=
2.4), libcollection4 (>= 0.4.0), libcom-err2 (>= 1.43.9), libini-config5 (>= 0.4.0), libk5crypto3 (>= 1.9+dfsg~beta1), libkrb5-3 (>= 1.13~alpha1+dfsg), libldap-2.4-2 (>= 2.4.7), libnspr4 (>= 2:4.9-2~),
libnss3 (>= 2:3.13.4-2~), libpopt0 (>= 1.14), libref-array1 (>= 0.4.0), libsasl2-2 (>= 2.1.27+dfsg), libssl1.1 (>= 1.1.0)
Recommends: chrony
Suggests: libpam-krb5
Breaks: freeipa-admintools (<< 4.6.3-2~)
Description: FreeIPA centralized identity framework -- client
Homepage: http://www.freeipa.org
Description-md5: 1aa0c0a3f974364e79585d72db619762
Section: net
Priority: optional
Filename: pool/main/f/freeipa/freeipa-client_4.7.2-3_i386.deb
Size: 111540
MD5sum: 6052e1e0e87c8f938b9a2795b5410cb0
SHA256: a1a75a1d0c1e653ae782348e0d61dc05c9117bc77e8651af4c491a94d7d7a877
...
Путь к deb-пакету относительно корня репозитория задается в параметре Filename, например, freeipa-client можно загрузить по ссылке https://deb.debian.org/debian/pool/main/f/freeipa/freeipa-client_4.7.2-3_i386.deb.
Вы можете создать все необходимые файлы и папки вручную, но это требует много времени и большой внимательности, поэтому для упрощения работы с репозиториями были разработаны вспомогательные инструменты, такие как reprepro
.
Архитектура подсистемы репозиториев
Для управления корпоративными репозиториями в продукте ALD Pro используется приложение reprepro
, которое ранее называлось mirrorer. Этот инструмент позволяет управлять базой данных пакетов и файловой структурой apt-репозиториев.
Для каждого репозитория создается каталог /opt/rbta/aldpro/repo/storage/<repository_id>
, внутри которого находятся следующие подкаталоги:
conf — содержит конфигурационные файлы reprepro. Приложение может использовать следующие три конфигурационных файла:
distributions — определяет список дистрибутивов репозитория и является обязательным.
options — определяет параметры репозитория и является опциональным, в ALD Pro не используется.
updates — определяет настройки для синхронизации с внешними репозиториями и является опциональным, в ALD Pro не используется.
db — содержит базы данных приложения
reprepro
в формате Berkeley DB, которые значительно ускоряют работу с метаинформацией.При желании вы можете посмотреть содержимое файлов
*.db
с помощью утилитыdb_dump
из пакета db-util. Например, ключ-p
(printing) выведет все содержимое:
root@repo-1:~# db_dump -p
/opt/rbta/aldpro/repo/storage/68518a45-d915-499d-9b61-884df60fd316/70606a6d-2947-4eb1-8959-c9e4bb01366a/db/packages.db
VERSION=3
format=print
database=latest|main|amd64
...
dists — папка дистрибутивов репозитория. Тут вы найдете метафайлы Release и Packages, которые обновляются автоматически при добавлении/удалении пакетов.
pool — в эту папку загружаются непосредственно файлы *.deb.
Управление репозиторием осуществляется через портал управления, который взаимодействует с сервером репозиториев через API по протоколу HTTPS. Например, для получения списка всех репозиториев фронтенд обращается к API бэкенда портала управления по адресу https://dc-1.ald.company.lan/ad/api/repo/repositories?limit=25&sortby=
, а бэкенд пересылает запрос на адрес https://repo-1.ald.company.lan/repo/api/repositories?limit=25&offset=0&sortby
.
За работу API на стороне репозитория отвечает wsgi-приложение, файл которого расположен по адресу /opt/rbta/aldpro/repo/core/wsgi.py
. Настройки Apache для этого приложения находятся в файле /etc/apache2/conf-enabled/rbta-ad-repo.conf
. Программный код для добавления и удаления репозиториев вы найдете в файле /opt/rbta/aldpro/repo/repository/tasks.py
.
Для ускорения работы подсистемы репозиториев бэкенд API сохраняет всю необходимую информацию в базе PostgreSQL, поэтому управлять репозиториями напрямую через утилиту reprepro
недопустимо. Вы можете заглянуть в эту SQL базу, используя утилиту pg_dump
:
admin@repo-1:~$ sudo -u postgres pg_dump repo | less
...
COPY public.repository_repositoryversiondeb (id,
repositoryversion_deb_description, repositoryversion_deb_origin,
repositoryversion_deb_label, repositoryversion_deb_version,
repositoryversion_deb_suite, repositoryversion_deb_codename,
repositoryversion_deb_components, repositoryversion_deb_architectures,
repositoryversion_deb_repository_version_id_id) FROM stdin;
1 yandex browser 1 latest main amd64 70606a6d-2947-4eb1-8959-c9e4bb01366a
...
Веб-сервер Apache используется не только для API, но и как сервер доставки файлов репозитория до рабочих станций. Дело в том, что утилита reprepro
решает только узкоспециализированную задачу по управлению apt-совместимыми репозиториями, а для предоставления доступа к этим репозиториям по протоколам HTTP(S) и FTP нужно использовать дополнительно Apache, Nginx или любой другой сервер доставки контента.
После публикации репозитория бэкенд на стороне подсистемы обновляет ссылки в каталоге /opt/rbta/aldpro/repo/storage/link_root_folder/
, который доступен через HTTP(S), что определено в ранее упомянутом конфигурационном файле веб-сервера /etc/apache2/conf-enabled/rbta-ad-repo.conf
. Кстати, каталоги conf
и db
можно было бы и не показывать по сети, т.к. они не нужны пакетному менеджеру.
admin@repo-1:~$ sudo ls -l /opt/rbta/aldpro/repo/storage/link_root_folder/customdeb/
итого 16
lrwxrwxrwx 1 root www-data 108 июл 16 06:37 conf -> /opt/rbta/aldpro/repo/storage/68518a45-d915-499d-9b61-884df60fd316/70606a6d-2947-4eb1-8959-c9e4bb01366a/conf
lrwxrwxrwx 1 root www-data 106 июл 16 06:37 db -> /opt/rbta/aldpro/repo/storage/68518a45-d915-499d-9b61-884df60fd316/70606a6d-2947-4eb1-8959-c9e4bb01366a/db
lrwxrwxrwx 1 root www-data 109 июл 16 06:37 dists -> /opt/rbta/aldpro/repo/storage/68518a45-d915-499d-9b61-884df60fd316/70606a6d-2947-4eb1-8959-c9e4bb01366a/dists
lrwxrwxrwx 1 root www-data 108 июл 16 06:37 pool -> /opt/rbta/aldpro/repo/storage/68518a45-d915-499d-9b61-884df60fd316/70606a6d-2947-4eb1-8959-c9e4bb01366a/pool
admin@repo-1:~$ cat /etc/apache2/conf-enabled/rbta-ad-repo.conf
...
Alias /repos /opt/rbta/aldpro/repo/storage/link_root_folder/
<Directory /opt/rbta/aldpro/repo/storage/link_root_folder/ >
SetHandler none
AllowOverride None
Satisfy Any
Require all granted
Options +Indexes
IndexIgnore tmp
</Directory>
...
Обратите внимание, что при загрузке пакетов в новую версию репозитория предыдущая версия автоматически снимается с публикации, и ее папка удаляется из каталога link_root_folder
.
Повышение роли сервера до подсистемы репозитория
Повысить роль сервера до подсистемы репозиториев программного обеспечения можно с портала управления ALD Pro на странице рис. 331. Сайт является обязательным полем, но пока еще не используется в системе. В будущем эта привязка позволит делегировать права доступа на управление подсистемами.
, см.Задание на установку подсистемы отправляется по цепочке Фронтенд --> Бэкенд --> RabbitMQ --> Salt Master --> Salt Minion
. За установку подсистемы отвечает скрипт install.sls
из каталога /srv/salt/states/aldpro/subsystems/repo/
.
Первый сервер устанавливается как основной, а второй сервер репозиториев считается репликой, и его DNS-имя вносится в файл /etc/lsyncd/lsyncd.conf.lua
в секцию replicas.
replicas = {
{% if pillar.get('replica_host', False) %}
"repo@{{ pillar['replica_host'] }}",
{% endif %}
}
Примечание
Если при перезапуске службы lsyncd одна из реплик недоступна, основной процесс lsyncd завершается с ошибкой, что приводит к отсутствию синхронизации репозиториев. Чтобы процесс не завершался, в конфигурационный файл в секции settings можно добавить параметр insist=true. Если вам требуется создать более одной реплики, то после повышения роли сервера нужно вручную добавить имена хостов в файл конфигурации lsyncd и перезапустить службу.
Служба lsyncd подключается к репликам по протоколу ssh и использует утилиту rsync
для копирования файлов и папок. Ключ для подключения по ssh находится в /var/lib/repo/.ssh/id_rsa
на основном сервере, соединение происходит под локальной учетной записью repo. Информация о загружаемых пакетах вносится в SQL базу основного сервера, с которого передается на реплики. Изменить данные на репликах невозможно, так как их базы работают только на чтение.
Создание репозитория из ISO-файла
Вы можете создать корпоративный репозиторий из ISO-файла. Для этого вам сначала нужно на странице рис. 332.
создать новый репозиторий, см.Где:
Имя репозитория = alse-174 — текстовая строка, которая будет использоваться в качестве имени каталога на сервере.
Тип репозитория = deb — поле не редактируется, в настоящий момент поддерживаются только APT-совместимые репозитории.
Описание — вспомогательная информация для сопровождения репозиториев.
Абсолютный путь публикации = /alse174 — абсолютный путь к папке на веб-сервере, в которой будут находиться файлы репозитория после публикации.
После сохранения нового репозитория станут доступны дополнительные вкладки для его настройки. Перейдите на вкладку рис. 333.
и создайте новую версию из ISO-образа, см.Если у вас вместо ISO-файла будет установочный компакт-диск, то вы можете создать из него необходимый файл с помощью утилиты dd следующей командой:
admin@dc-1:~$ dd if=/dev/sr0 of=al174main.iso bs=100M status=progress
При загрузке ISO-файла фронтенд портала управления передает данные на бэкенд, а тот в свою очередь пересылает данные сразу программному интерфейсу основного сервера репозиториев. Передача осуществляется по протоколу HTTPS, а после загрузки файла служба celery на основном сервере репозиториев выполняет в фоне следующие задачи:
распаковывает файл в каталог storage;
вносит информацию в базу PostgreSQL, чтобы она была доступна на портале управления на вкладке
;автоматически публикует версию репозитория, после чего она переходит из состояния «Обработка» в «Опубликована».
Чтобы добавить корпоративный репозиторий, создайте файл /etc/apt/sources.list.d/alse174.list
следующей командой:
admin@pc-1:~$ echo "deb [trusted=yes] http://repo-1.ald.company.lan/repos/alse174/ 1.7_x86-64 main contrib non-free" | sudo tee /etc/apt/sources.list.d/alse174.list
Где:
[trusted=yes] — указывает, что источник является доверенным и можно устанавливать пакеты без проверки цифровых подписей;
http://repo-1.ald.company.lan/repos/alse174/ — задает путь к папке репозитория на веб-сервере, который мы указали ранее. Можно посмотреть во вкладке
выбранного репозитория.1.7_x86-64 — кодовое имя дистрибутива, которое можно посмотреть в описании версии после загрузки ISO-образа.
main, contrib и non-free — компоненты дистрибутива, которые можно посмотреть в описании версии после загрузки ISO-образа.
После добавления ссылки на корпоративный репозиторий обновите индекс пакетов и результат выполнения обновления кэша:
admin@pc-1:~$ sudo apt update
Игн:1 http://repo-1.ald.company.lan/repos/alse174 1.7_x86-64 InRelease
Пол:2 http://repo-1.ald.company.lan/repos/alse174 1.7_x86-64 Release [5 766 B]
Пол:3 http://repo-1.ald.company.lan/repos/alse174 1.7_x86-64 Release.gpg [833B]
Сущ:4 http://dl.astralinux.ru/astra/frozen/1.7_x86-64/1.7.4/repository-base 1.7_x86-64 InRelease
Пол:5 http://repo-1.ald.company.lan/repos/alse174 1.7_x86-64/main amd64 Packages [1 310 kB]
Сущ:6 http://dl.astralinux.ru/astra/frozen/1.7_x86-64/1.7.4/repository-extended 1.7_x86-64 InRelease
Пол:7 http://repo-1.ald.company.lan/repos/alse174 1.7_x86-64/contrib amd64 Packages [2 155 B]
Пол:8 http://repo-1.ald.company.lan/repos/alse174 1.7_x86-64/non-free amd64 Packages [55,8 kB]
Сущ:9 https://dl.astralinux.ru/aldpro/frozen/01/2.2.0 1.7_x86-64 InRelease
Получено 1 374 kB за 0с (3 309 kB/s)
Чтение списков пакетов… Готово
Построение дерева зависимостей
Чтение информации о состоянии… Готово
Для дополнительной проверки вы можете отключить все публичные интернет-репозитории в файле /etc/apt/sources.list
, обновить индекс пакетов еще раз, после чего убедиться в том, что установка утилиты htop
проходит из корпоративного репозитория.
admin@pc-1:~$ sudo vi /etc/apt/sources.list
admin@pc-1:~$ sudo apt update
Игн:1 http://repo-1.ald.company.lan/repos/alse174 1.7_x86-64 InRelease
Сущ:2 http://repo-1.ald.company.lan/repos/alse174 1.7_x86-64 Release
Сущ:4 https://dl.astralinux.ru/aldpro/frozen/01/2.2.0 1.7_x86-64 InRelease
...
Чтение списков пакетов… Готово
Построение дерева зависимостей
Чтение информации о состоянии… Готово
Все пакеты имеют последние версии.
admin@pc-1:~$ sudo apt install htop
Чтение списков пакетов… Готово
Построение дерева зависимостей
Пол:1 http://repo-1.ald.company.lan/repos/alse174 1.7_x86-64/main amd64 htop amd64 2.2.0-1 [89,9 kB]
Получено 89,9 kB за 0с (0 B/s)
…
Распаковывается htop (2.2.0-1) …
Настраивается пакет htop (2.2.0-1) …
...
Создание репозитория вручную
Вы можете загружать вручную отдельные deb-пакеты сторонних разработчиков. Для примера создадим репозиторий с названием yandex-browser, в который загрузим последнюю версию браузера от компании Яндекс. На портале управления ALD Pro создайте новый репозиторий с названием «yandex-browser» и укажите абсолютный путь «/yandexbrowser», см. рис. 334
Создайте новую версию репозитория, см. рис. 335
Где:
Источник = yandex — Справочное поле для описания источника пакета.
Метка = browser — Справочное поле для описания вида программного пакета.
Номер версии = 1 — Целое число для версионирования репозитория. При обновлении версии репозитория нужно использовать следующий порядковый номер.
Кодовое имя дистрибутива = latest — Используется для возможности размещения в одном репозитории нескольких дистрибутивов, но подсистема ALD Pro позволяет работать только с одним дистрибутивом, поэтому не имеет практического значения, рекомендуется использовать значение latest.
Архитектура дистрибутива = amd64 - Используется для возможности размещения в одном репозитории пакетов для разных архитектур. Подсистема ALD Pro позволяет разместить только одну версию пакетов, поэтому не имеет практического значения, и можно использовать значение all.
Компоненты дистрибутива = main — Используется для возможности распределения пакетов по категориям. В репозитории ALD Pro можно разместить пакеты только одной категории main, поле не редактируется.
Теперь вам станет доступна загрузка пакетов на вкладке
. Скачайте наиболее свежую версию браузера следующими командами:admin@dc-1:~$ cd ~/Загрузки
admin@dc-1:~/Загрузки$ wget https://download.yandex.ru/browser/astra-os/yandex-browser.deb
admin@dc-1:~/Загрузки$ mv yandex-browser.deb "yandex-browser-$(dpkg -f yandex-browser.deb Version).deb"
Загрузите пакет в репозиторий и обновите страницу, чтобы увидеть изменения, см. рис. 336. Пакет может не появиться в списке, если файл не будет принят утилитой reprepro.
Для того чтобы репозиторий стал доступен пользователям, его нужно опубликовать. Ссылку для подключения репозитория можно добавить командой:
echo "deb [trusted=yes] http://repo-1.ald.company.lan/repos/yandexbrowser/ latest main" | sudo tee /etc/apt/sources.list.d/yandexbrowser.list
Если вы теперь выполните обновление индекса пакетов, то с помощью команды policy
утилиты apt-cache
сможете увидеть, что Яндекс браузер будет устанавливаться из yandexbrowser дистрибутива latest.
admin@pc-1:~$ sudo apt update
Игн:1 http://repo-1.ald.company.lan/repos/alse174 1.7_x86-64 InRelease
Игн:2 http://repo-1.ald.company.lan/repos/yandexbrowser latest InRelease
Сущ:3 http://repo-1.ald.company.lan/repos/alse174 1.7_x86-64 Release
Пол:4 http://repo-1.ald.company.lan/repos/yandexbrowser latest Release [865 B]
Игн:5 http://repo-1.ald.company.lan/repos/yandexbrowser latest Release.gpg
Пол:6 http://repo-1.ald.company.lan/repos/yandexbrowser latest/main amd64 Packages [881 B]
Сущ:8 https://dl.astralinux.ru/aldpro/frozen/01/2.2.0 1.7_x86-64 InRelease
Получено 1 746 B за 0с (6 089 B/s)
Чтение списков пакетов… Готово
Построение дерева зависимостей
Чтение информации о состоянии… Готово
Все пакеты имеют последние версии.
admin@pc-1:~$ sudo apt-cache policy yandex-browser-stable
yandex-browser-stable:
Установлен: (отсутствует)
Кандидат: 24.4.3.1115-1
Таблица версий:
24.4.3.1115-1 500
500 http://repo-1.ald.company.lan/repos/yandexbrowser latest/main amd64 Packages
Изменение опубликованной версии репозитория
После публикации репозитория вы не сможете внести никаких изменений в текущую версию, что довольно неудобно, т.к. при создании новой версии все пакеты придется загружать повторно. В будущих релизах продукта эта особенность будет изменена, но если вам прямо сейчас нужно сопровождать довольно большой корпоративный репозиторий, то можно воспользоваться следующим обходным решением.
Статус репозитория определяется значением столбца repositoryversion_status в таблице repository_repositoryversion базы repo. Если версия репозитория будет опубликована, то в этом столбце вы увидите значение published, а, чтобы снять репозиторий с публикации, вам достаточно вручную установить значение на edit и удалить ссылки из каталога link_root_folder
. При повторной публикации версии репозитория ссылки будут созданы автоматически.
Следующей командой вы сможете изменить состояние версии репозитория «yandex-browser» с значения «published» на «edit»:
admin@repo-1:~$ sudo -i -u postgres psql -d repo -c \
"UPDATE repository_repositoryversion \
SET repositoryversion_status='edit' \
WHERE repositoryversion_status='published' AND \
repositoryversion_repository_id = \
(SELECT repository_id FROM repository_repository WHERE \
repository_name='yandex-browser');"
Результат выполнения команды:
UPDATE 1
Строка «UPDATE 1» свидетельствует о том, что изменение записи прошло успешно. Текущее состояние репозиториев вы можете получить следующей командой:
admin@repo-1:~$ sudo -i -u postgres psql -x -d repo -c \
"SELECT * FROM repository_repositoryversion \
JOIN repository_repository ON \
repositoryversion_repository_id = repository_id;"
Результат выполнения команды:
-[ RECORD 1 ]-------------------+-------------------------------------
repositoryversion_id | 46304e0e-33c0-42c1-ba51-13f0445440fd
repositoryversion_version | 1
repositoryversion_status | published
repositoryversion_created_at | 2024-07-17 05:33:04.868885+03
repositoryversion_source_type | iso
repositoryversion_repository_id | 5e9c1aca-6655-4396-aea8-8baaeef1564c
repository_id | 5e9c1aca-6655-4396-aea8-8baaeef1564c
repository_name | alse-174
repository_type | deb
repository_source_type | local
repository_created_at | 2024-07-17 05:31:41.284323+03
repository_updated_at | 2024-07-17 05:31:41.284342+03
repository_version | 1
repository_description | Пакеты операционной системы
repository_uri_relative_path | /alse174
repository_status | ok
-[ RECORD 2 ]-------------------+-------------------------------------
repositoryversion_id | 0bab4493-1beb-4a96-87bc-43b713b5e9a2
repositoryversion_version | 1
repositoryversion_status | edit
repositoryversion_created_at | 2024-07-17 06:03:41.917093+03
repositoryversion_source_type | file
repositoryversion_repository_id | 3db1adef-b447-49d7-a1e9-158f29730b98
repository_id | 3db1adef-b447-49d7-a1e9-158f29730b98
repository_name | yandex-browser
repository_type | deb
repository_source_type | local
repository_created_at | 2024-07-17 05:57:09.822516+03
repository_updated_at | 2024-07-17 05:57:09.822532+03
repository_version | 1
repository_description |
repository_uri_relative_path | /yandexbrowser
repository_status | ok
...
После отмены публикации репозитория вам нужно также удалить ссылку в каталоге веб-сервера:
admin@repo-1:~$ sudo rm -rf /opt/rbta/aldpro/repo/storage/link_root_folder/yandexbrowser
После выполнения указанных команд вы сможете продолжить редактирование репозитория через портал управления ALD Pro. По окончанию редактирования не забудьте снова опубликовать репозиторий, чтобы он стал доступен по протоколу HTTP(S) для рабочих станций.
Политики установки программного обеспечения
После публикации корпоративного репозитория вам становятся доступны политики установки программного обеспечения, которые работают через Salt. Давайте установим браузер Яндекс через групповые политики.
Для этого нам сначала нужно на странице рис. 337
создать раздел «Корпоративные приложения» и в нем новый набор программного обеспечения «Браузер Яндекс», см.Откройте созданный набор и на вкладке рис. 338.
загрузите пакет браузера Яндекс. В списке будет ограниченное количество записей, поэтому вам нужно будет начать вводить название пакета «yandex…», чтобы сработала функция поиска и показала доступные значения, см.Групповые политики установки программного обеспечения позволяют автоматически настраивать конфигурационные файлы этих приложений. Для этого в настройках набора программного обеспечения на вкладке {{ homepage_url }}
через политику HomepageLocation, см. рис. 339.
Примечание
Для русскоязычных доменов потребуется написать адрес закодированный в punycode, например: моя-фирма.рф — xn----8sbxocjq4a1h.xn--p1ai
Давайте создадим шаблон файла /etc/opt/yandex/browser/policies/managed/managed_policies.json
.
На странице «Шаблоны конфигурации» нужно будет задать следующий salt-скрипт:
{%- set homepage_url = parameters.get('homepage_url', none) -%}
{
"HomepageLocation": "{{ homepage_url }}"
}
Примечание
Обратите внимание, что при редактировании объекта групповой политики установки программного обеспечения вы сможете задать несколько наборов атрибутов, как будто эти параметры являются составными. В версии 2.0.0 так и было, поэтому для получения значения атрибута функцию нужно было вызывать так: parameters[0].get(…)
. Начиная с версии 2.2.0, переменная parameters содержит один последний набор атрибутов, поэтому вы можете использовать метод parameters.get
без уточнения индекса элемента.
Теперь вы сможете создать новый объект групповой политики на странице рис. 341
, см.Чтобы добавить набор программного обеспечения в объект групповой политики, вам нужно на вкладке
выбрать его в дереве и нажать кнопку . Удалить ранее добавленный набор вы сможете на вкладке .Назначить объект групповой политики на компьютеры можно на вкладке
. Вы можете выбрать подразделение в целом или уточнить список компьютеров и групп компьютеров, которые будут попадать в область действия этого объекта групповой политики.Осталось только обновить кэш и форсировать применение групповой политики установки ПО:
admin@pc-1:~$ sudo salt-call state.apply gpupdate.build -c /srv/salt/standalone/config/ pillar='{"force": True}'
admin@pc-1:~$ sudo salt-call state.apply gpupdate.swp -c /srv/salt/standalone/config/
Не забудьте, что для установки свежей версии браузера вам нужно переключить систему на корпоративные репозитории alse174 и yandexbrowser. Ранее в модуле про групповые политики мы уже приводили пример дополнительного параметра групповой политики «Источники программного обеспечения», с помощью которого вы можете централизованно настраивать источники программного обеспечения в домене.
Подсистема «Служба печати»
В ходе реализации проектов импортозамещения на предприятиях крайне важно сохранить привычный уровень удобства в работе с наиболее востребованными сервисами, в том числе и такими как печать. Для этого в продукте ALD Pro реализована подсистема службы печати на базе программного обеспечения CUPS, которая позволяет обеспечить централизованный доступ к принтерам по протоколу IPP, что устраняет необходимость установки специализированных драйверов на рабочие станции.
Повышение роли сервера до подсистемы службы печати
Повысить роль сервера до подсистемы службы печати можно с портала управления ALD Pro на странице рис. 342. Сайт является обязательным полем, но пока еще не используется в системе. В будущем эта привязка позволит делегировать права доступа на управление подсистемами.
, см.Задание на установку подсистемы отправляется по цепочке Фронтенд --> Бэкенд --> RabbitMQ --> Salt Master --> Salt Minion
, а за установку подсистемы отвечает скрипт install.sls
из каталога /srv/salt/states/aldpro/subsystems/cups/
.
Архитектура подсистемы службы печати
Мы уже рассматривали подробно устройство службы CUPS, см. Модуль 16. Работа с подсистемой печати, поэтому отметим только, что в случае подсистемы ALD Pro доступ к службе с рабочих мест сотрудников осуществляется по протоколу IPP, порт 631/TCP или 443/TCP (в случае SSL), см. рис. 343. Чисто технически CUPS поддерживает также подключение по протоколам LPD, Samba и NetTalk, но в ALD Pro мы используем только неавторизованный доступ через IPP.
Администрировать службу CUPS в операционной системе Astra Linux могут участники локальной группы lpadmin с идентификатором 113, что задается параметром «Require user @SYSTEM» в разделе <Location /admin>
конфигурационного файла /etc/cups/cupsd.conf
.
admin@print-1:~$ cat /etc/cups/cupsd.conf
. . .
<Location /admin>
AuthType Default
Order allow,deny
Allow all
Require user @SYSTEM
</Location>
. . .
Значение @SYSTEM говорит, что необходимо смотреть значение параметра «SystemGroup» в файле /etc/cups/cups-files.conf
, где мы как раз и увидим нашу группу lpadmin.
cat /etc/cups/cups-files.conf
. . .
# Administrator user group, used to match @SYSTEM in cupsd.conf policy rules...
# This cannot contain the Group value for security reasons...
SystemGroup lpadmin
. .
Для того чтобы назначать доступ доменным пользователям, в службе каталога создана одноименная группа lpadmin с тем же идентификатором 113, см. рис. 344.
Добавление нового принтера
Чтобы добавить новый принтер вы должны подключить его USB-кабелем к серверу, на котором установлена подсистема службы печати, и установить необходимые драйверы. Вам в первую очередь нужно добиться возможности печати пробной страницы с этого сервера.
Большинство современных принтеров и МФУ имеют сетевой порт или позволяют подключить принтер к компьютерной сети через Wi-Fi. В случае сетевого доступа в настройках принтера рекомендуется установить ограничение по IP-адресу, чтобы сотрудники не пытались подключать принтер напрямую.
Добавить новый принтер можно через портал управления в разделе рис. 345.
. Для этого откройте страницу соответствующего сервера и на вкладке нажмите кнопку , см.В карточке нового принтера следует заполнить следующие поля, см. рис. 346.
Подключение — укажите адрес физического принтера, например:
для PDF принтера:
cups-pdf:/
;для USB принтера:
usb://<производитель>/<имя_устройства>
, например для Samsung ML-2850:usb://Samsung/ML-2850%20Series
;для сетевого принтера:
ipp://<ip_адрес>
.
В нашем случае в качестве примера это PDF принтер, поэтому в поле подключение напишите: cups-pdf:/.
Наименование принтера — задайте имя принтера, под которым он также будет отображаться на пользовательском компьютере (на латинице и без пробелов), например: PDF.
Расположение — укажите физическое месторасположение принтера, например, кабинет 101, этаж 1.
Драйвер — укажите путь к файлу
*.ppd
на вашем компьютере с драйвером устройства печати, например, файл драйвера PDF принтера/usr/share/ppd/cups-pdf/CUPS-PDF_noopt.ppd
. Драйвер будет передан на сервер службы печати для возможности работы сервера с устройством. А также драйвера принтеров можно поискать на сайте OpenPrinting .Описание — в этом поле вы можете указать дополнительную информацию об устройстве, например, модель принтера.
Примечание
Если в системе настроена миграция из домена MS Active Directory, то система позволит вам перенести основную информацию о принтере, но лучше сделать все вручную, чтобы сразу настроить драйвер принтера.
На вкладке Список заданий
вы сможете увидеть только активные задания на печать, а успешно завершенные задания отображаться не будут. По наличию записей в этом журнале можно понять, что с принтером что-то не так, например, он неисправен или недоступен.
Для проверки системы мы воспользуемся виртуальным принтером «PDF», который был создан автоматически после установки службы печати на сервере cups-1.ald.company.lan. По умолчанию принтер PDF не виден на вкладке Список принтеров
, так как у этого принтера не установлен флажок . Исправить это можно тремя способами:
Откройте «Менеджер печати Fly» и установите флажок «Разрешить общий доступ» для принтера «PDF».
В конфигурационном файле
/etc/cups/printers.conf
в секции принтера PDF установите параметр «Shared Yes» и перезапустите службу cups.
admin@cups-1:~$ sudo nano /etc/cups/printers.conf
<DefaultPrinter PDF>
...
Shared Yes
...
</DefaultPrinter>
admin@cups-1:~$ sudo systemctl restart cups
В веб-интерфейсе службы CUPS http://localhost:631 откройте страницу . Портал попросит вас пройти аутентификацию, для этого введите учетные данные доменного администратора (admin) либо другого пользователя, который является участником локальной группы «lpadmin».
Далее вы попадете на страницу настроек принтера, где нужно будет нажать несколько раз кнопку
, пока вы не увидите опцию «Совместный доступ». Включите этот параметр и завершите настройку принтера.После выполнения указанных действий вы сможете увидеть принтер PDF в списке принтеров подсистемы службы печати на портале управления ALD Pro.
Установка принтера с помощью групповой политики
Чтобы централизованно добавить принтер на рабочие станции сотрудников, воспользуйтесь параметром групповой политики рис. 347.
из раздела «Оборудование». Для этого создайте объект групповой политики «Принтеры ИТ» на странице и включите в нем требуемый параметр, см.Не забудьте назначить объект групповой политики на требуемое подразделение. Чтобы форсировать применение политики, выполните команды:
admin@pc-1:~$ sudo salt-call state.apply gpupdate.build -c /srv/salt/standalone/config/ \
pillar='{"force": True}'
...
[INFO ] Loading fresh modules for state activity
[INFO ] Fetching file from saltenv 'base', ** done ** 'gpupdate/build.sls'
[INFO ] Running state [/opt/rbta/aldpro/standalone] at time 11:28:58.422786
[INFO ] Executing state file.tidied for [/opt/rbta/aldpro/standalone]
[INFO ] {'removed': ['/opt/rbta/aldpro/standalone/gp-user_pillar.json']}
[INFO ] Completed state [/opt/rbta/aldpro/standalone] at time 11:28:58.431765 (duration_in_ms=8.978)
...
Summary for local
------------
Succeeded: 5 (changed=5)
Failed: 0
------------
Total states run: 5
Total run time: 2.942 s
admin@pc-1:~$ sudo salt-call state.apply gpupdate.gp -c /srv/salt/standalone/config/
. . .
[INFO ] Completed state [cups] at time 11:29:31.663988 (duration_in_ms=76.284)
[INFO ] Running state [lpadmin -p PDF -E -v ipp://cups-1.ald.company.lan/printers/PDF -m raw] at time 11:29:31.666116
[INFO ] Executing state cmd.run for [lpadmin -p PDF -E -v ipp://cups-1.ald.company.lan/printers/PDF -m raw]
[INFO ] Executing command 'lpadmin' in directory '/root'
[INFO ] {'pid': 16283, 'retcode': 0, 'stdout': '', 'stderr': "lpadmin: Raw queues are deprecated and will stop working in a future version of CUPS.\nlpadmin: Use the 'everywhere' model for shared printers."}
[INFO ] Completed state [lpadmin -p PDF -E -v ipp://cups-1.ald.company.lan/printers/PDF -m raw] at time 11:29:31.690802 (duration_in_ms=24.685)
[INFO ] Running state [assigned_printers] at time 11:29:31.693402
[INFO ] Executing state grains.present for [assigned_printers]
[INFO ] {'assigned_printers': [OrderedDict([('rbta_ldap_printers__name', 'PDF'), ('rbta_ldap_printers__server', 'cups-1.ald.company.lan')])]}
[INFO ] Completed state [assigned_printers] at time 11:29:31.702586 (duration_in_ms=9.183)
[INFO ] {'ret': True}
[INFO ] Completed state [gp_sum.build_and_run_gp] at time 11:29:31.703918 (duration_in_ms=14796.1)
. . .
После применения групповой политики в Менеджере печати на pc-1 вы увидите, что появился общий принтер PDF (ipp://cups-1.ald.company.lan/printers/PDF), см. рис. 348.
В окне «Печать» текстовых редакторов, например, LibreOffice, кроме принтера PDF вам будет доступен также принтер «PDF_cups_1», и это тот же самый принтер, но его настройки система получила автоматически через широковещательный запрос к серверу CUPS-1, так как по умолчанию включена служба avahi, а в параметрах сервера включена опция «Browsing».
По умолчанию печать на автоматически найденный принтер работать не будет, поэтому в конфигурационном файле /etc/cups/printers.conf рекомендуется установить опцию «Browsing No» и перезапустить службу:
admin@cups-1:~$ cat /etc/cups/printers.conf
...
<DefaultPrinter PDF>
Browsing No
. . .
</DefaultPrinter>
...
Примечание
Если вам потребуется задействовать автоматическое обнаружение принтеров, то вместо того, чтобы отключить Browsing, установите параметр «DNSSDHostName cups-1.ald.company.lan», и тогда клиенты начнут обращаться к принтеру по правильному имени вместо cups-1.local. Только не забывайте, что широковещательные запросы не смогут выйти за пределы L2 сети.
Подсистема «Мониторинг»
Для отслеживания состояния серверной группировки в продукте ALD Pro предназначена отдельная подсистема мониторинга на базе Zabbix с использованием инструментов построения графического представления данных Grafana.
Повышение роли сервера до подсистемы мониторинга выполняется на вкладке рис. 349. В настоящий момент сервер мониторинга должен быть в домене только в единственном экземпляре.
страницы . Нажмите кнопку , см.Подсистема мониторинга состоит из двух основных компонентов, см. рис. 350:
Zabbix — свободная система мониторинга статусов разнообразных сервисов компьютерной сети, серверов и сетевого оборудования, написанная Алексеем Владышевым. Для хранения данных используется MySQL, PostgreSQL, SQLite или Oracle Database, веб-интерфейс написан на PHP.
Grafana — свободная программная система визуализации данных, ориентированная на данные систем ИТ-мониторинга. Реализована как веб-приложение в стиле «приборных панелей» с диаграммами, графиками, таблицами, предупреждениями. Часто используется совместно с СУБД или системами мониторинга.
Система подключается к многообразным источникам данных, поддерживает расширение с помощью системы плагинов. Позволяет конечным пользователям строить сложные панели мониторинга с помощью интерактивных запросов.
В таблице ниже достаточно подробно объясняется, по каким протоколам взаимодействуют компоненты системы между собой.
Номер |
Инициатор |
Адресат |
Протокол |
Передаваемая информация |
---|---|---|---|---|
13.11.1. |
Агент домена Модуль автообнаружения |
Агент домена - Клиент мониторинга |
CLI |
Модуль автообнаружения настраивает клиент мониторинга на адреса серверов мониторинга |
13.11.2. |
Агент домена - Модуль автообнаружения |
Портал управления |
HTTPS |
Получает список серверов мониторинга |
13.11.3. |
Агент домена - Модуль автообнаружения |
Разрешение имен |
DNS |
Чтение DNS записей с DNS сервера |
13.6.1. |
Агент домена - Клиент мониторинга |
Мониторинг - Сервер мониторинга |
Zabbix |
Клиент мониторинга передает метрики рабочей станции на сервера мониторинга |
10.1.1. |
Мониторинг - Сервер мониторинга |
Мониторинг - Хранилище данных мониторинга |
TCP SQL |
Запись информации о собранных метриках |
10.1.2. |
Мониторинг - Сервер мониторинга |
Служба каталогов - LDAP сервер |
LDAP |
Получает список машин и развернутых на них подсистем |
10.3.1. |
Мониторинг - Визуализация витрин мониторинга |
Мониторинг - Сервер мониторинга |
HTTP |
Получает метрики для отображения на витринах мониторинга |
10.4.1. |
Мониторинг - zbx_discovering |
Портал управления |
HTTPS |
Получает список машин и развернутых на них подсистем |
10.4.2. |
Мониторинг - zbx_discovering |
Портал управления |
HTTPS |
Передает список машин и развернутых на них подсистем |
1.1 |
Портал управления |
Мониторинг - Визуализация витрин мониторинга |
HTTPS |
Чтение дашбордов витрин мониторинга для визуализации собранных метрик в интерфейсе портала управления |
1.2. |
Портал управления |
Служба каталогов - LDAP-сервер |
LDAP |
Происходит авторизация портала управления на сервере мониторинга через LDAP-сервер |
После установки подсистемы информация о состоянии серверной группировки начинает отображаться на странице рис. 351.
. Дополнительную информацию о состоянии системы вы сможете найти, например, на витринах мониторинга, см.Подключаясь к административным порталам Zabbix и Grafana, вы можете, например, добавлять новые параметры и изменять существующие витрины.
Подсистема «Аудит»
Подсистема аудита (журнала событий) предназначена для сбора событий с серверов и рабочих станций. Начиная с версии 2.0.0, подсистема реализована на базе продукта Syslog-ng.
Серверов аудита в домене может быть несколько. Повышение роли сервера до подсистемы аудита выполняется на странице рис. 352.
, см.Для сбора событий с серверов и рабочих станций требуется настроить правила аудита на странице рис. 353.
, см.В карточке нового правила нужно настроить следующие поля, см. рис. 354:
Имя правила – введите любое значение для идентификации правила.
Тип логов – выберите один из трех доступных типов событий:
Логи авторизации Fly — информация о входе в графический интерфейс системы.
Логи удаленного подключения — информация о подключениях по SSH.
Логи состояния подключения к сети — информация о подключениях к сети из журналов NetworkManager.
Сервер сбора логов – укажите один из доступных серверов аудита, на который нужно отправлять события.
Описание – дополнительная информация о правиле для удобства администрирования.
Статус – позволяет отключить правило без его удаления.
Для принудительного обновления правил аудита на pc-1 используйте команды:
admin@pc-1:~$ sudo salt-call state.apply gpupdate.build -c /srv/salt/standalone/config/ \
pillar='{"force": True}'
admin@pc-1:~$ sudo salt-call state.apply gpupdate.audit -c /srv/salt/standalone/config/
Как вы можете заметить, перечень событий крайне небольшой, поэтому для интеграции с SIEM-системой MaxPatrol был разработан дополнительный параметр групповой политики, с помощью которого можно кастомизировать настройки syslog-ng на клиентах.
Интеграция с приложениями сторонних разработчиков
Для того чтобы извлечь максимальную выгоду от внедрения службы каталога, вам нужно интегрировать с ней как можно больше корпоративных приложений. Это позволит сократить количество паролей, которые нужно запоминать пользователям, а, может быть, даже упростит администрирование прав доступа.
Разработчики приложений должны позаботиться о возможности интеграции своих продуктов со службой каталога заранее, а в идеале предоставить подробные инструкции о том, как выполнить эту настройку. Однако иногда вы будете сталкиваться с тем, что не будет ни инструкций, ни достоверных фактов о возможности такой интеграции, поэтому крайне полезно понимать общие принципы:
Во-первых, интеграция со службой каталога нужна как минимум на уровне аутентификации. Служба каталога поддерживает Kerberos, LDAP и NTLM, а если ее интегрировать с Keycloak, то станут доступны также протоколы OAuth2, OpenID и SAML.
Многие приложения поддерживают аутентификацию через LDAP, но, как мы уже знаем, это не самый удачный способ, т.к. в этом случае через информационную систему будут проходить учетные данные пользователей в открытом виде, и администрировать ее должны администраторы домена.
Наиболее удачным видится использование Kerberos-аутентификации, т.к. в этом случае серверное приложение получает только билет, зашифрованный ее собственным паролем. Это позволяет делегировать администрирование системы независимой команде системных администраторов, исключая возможность разглашения учетных данных сотрудников.
Некоторые устаревшие приложения будут поддерживать NTLM-аутентификацию. В этом случае через систему пароли не будут проходить в открытом виде, но данный протокол все-таки уже устарел и существенно уступает по безопасности даже LDAP, т.к. более подвержен MITM-атакам.
Протоколы OAuth2, OpenID и SAML сопоставимы по уровню безопасности Kerberos, но предназначены в первую очередь для аутентификации web-приложений.
Во-вторых, приложения могут быть интегрированы на уровне авторизации, т.е. использовать информацию об участии пользователей в группах.
Данная информация обычно извлекается из каталога по протоколу LDAP и опирается на значение атрибутов memberof. Наиболее сложный аспект этой интеграции заключается в сопоставлении субъектов безопасности. Приложения могут использовать полное отличительное имя (DN), логин (uid, sAMAccountName, kerberos principal name), идентификатор безопасности (SID, uidNumber, gidNumber).
Служба каталога FreeIPA использует схему данных, которая отличается от схемы Active Directory, но для совместимости у пользователей и групп есть идентификаторы SID в стиле Windows, которые вы можете использовать в целях интеграции.
Приложения, которые максимально интегрированы с Windows, извлекают авторизационную информацию об участии пользователя в группах в виде набора идентификаторов безопасности SID непосредственно из сертификата атрибута привилегий (PAC), который находится внутри Kerberos-билета.
В службе каталога FreeIPA билеты пользователей содержат MS-PAC, и файловый сервер Samba, например, может получать авторизационную информацию из билетов. Такой способ позволяет немного снизить нагрузку на контроллеры домена, но в части безопасности он ничем не лучше LDAP.
Протокол OAuth2 предоставляет механизм для делегирования доступа, позволяя приложениям действовать от имени пользователя без получения его учетных данных (обеспечивает получение согласия пользователя, выдачу токенов доступа, определение области доступа и обновление токенов). Однако OAuth2 сам по себе не выполняет проверку логина/пароля (аутентификацию) и не определяет права доступа на основе участия в группах (авторизацию).
Протокол SAML позволяет передавать информацию как для проверки логина/пароля (аутентификация), так и для проверки ACL на основе групп (авторизация).
Протокол OpenID предназначен для аутентификации, то есть проверки логина и пароля. LDAP может использоваться как хранилище информации о пользователях, включая их учетные данные и принадлежность к группам. В сочетании с OpenID протокол LDAP может участвовать в процессах аутентификации (предоставляя данные для проверки логина/пароля) и авторизации (предоставляя информацию о членстве в группах для проверки ACL). Логика авторизации реализуется на уровне приложения.
Большинство клиент-серверных приложений ограничиваются только функциями аутентификации и авторизации, но есть и более сложные приложения. Например, IDM-системы, которые взаимодействуют с каталогом через активные коннекторы и могут создавать, изменять и блокировать учетные записи пользователей, реализуя сложный жизненный цикл с элементами документооборота. Для получения информации о возможностях интеграции обращайтесь в первую очередь к рабочей документации по соответствующему продукту.
Практика и тестирование
Заключение
Как вы могли заметить, служба каталога — это крайне непростая система, состоящая из множества компонентов, использующих разные технологии и протоколы, но мы постарались охватить все основные моменты, чтобы вы чувствовали себя уверенно при администрировании домена на предприятиях малого и среднего бизнеса.
Мы уверены, что информация, представленная в этих учебных модулях, заложит надежный фундамент для вашего дальнейшего саморазвития. Но если вы столкнетесь с какой-то непонятной проблемой, обязательно обращайтесь в нашу техническую поддержку и сообщество ALD Proфессионалов.