Комментарии 7
Классный разбор! Всё по делу доп. атрибуты в JSON, уникальные OU, политики HBAC/SUDO для гибкого управления, SSH‑ключи в LDAP и 2FA через OTP. Очень практично для админов, сразу видно, как реально эксплуатировать ALD Pro.
Годный общедоступный ресурс: Справочный центр ALD Pro 3.2.0 26-03-26 опубликовали в репах ALD Pro 3.2.0
Спасибо вам за комментарий! Согласен, Группа Астра предоставляет подробную документацию к продукту, и это здорово! Дополнительно продублирую ссылку на бесплатный курс - https://www.aldpro.ru/professional/, в котором разобраны все ключевые темы по работе с ПК ALD Pro
https://dev.astra.ru/ Зарегистрироваться на портале можно как физ. лицо, только E-mail и получить доступ(есть ораничения, но дистр-iso доступны) к https://lk.astra.ru/
В MS AD есть расширенные атрибуты (Extension Attributes 1-15), которые предназначены для хранения пользовательских данных, не входящих в стандартную схему.
В MS AD (базовой, идущей с Windows Server) их нет. Эти атрибуты - часть расширения схемы каталога (т.е. добавления новых типов объектов и новых атрибутов для существующих типов объектов)при установке MS Exchange (но, в принципе, ничто не мешает расширить схему и без установки сервера MS Exchange - расширение схемы делается отдельным шагом). А что есть именно в MS AD - так это сама возможность расширения схемы каталога.
А разве в ALD Pro такой возможности нет? Если нет - зря IMHO.
PS Извините, что так поздно комментирую, но эту статью я увидел только из другой вашей статьи, про BlackBerry.
Спасибо вам за комментарий! Есть возможность управления из интерфейса "Дополнительными сведениями" - которые хранятся в формате JSON (как описано в статье).
Сама служба каталогов 389Directory позволяет расширять схему, но управление ей будет возможно только через LDAP-браузер или через CLI FreeIPA.
Ну да, дополнительные атрибуты требуют дополнительного интерфейса пользователя. И пользователю откуда-нибудь из кадровой службы лучше давать свой, для него предназначенный интерфейс, а не интерфейсы общего назначения для администраторов каталога. И этот интерфейс приходится делать. В Windows с этим несколько проще - есть удобные COM-надстройки над LDAP: ADSI и OLEDB/ADO для AD, для работы с которыми совсем несложно написать программу на Delphi. Некогда, давным-давно, мне даже пришлось такую писать: на предприятии планировалось внедрение кадрового ПО как части решения ERP (сильно кастомизированный Navision/MS Dynamics Attain) с интеграцией с AD и далее с корпоративным документоооборотом на базе MS Sharepoint. Но кадровая программа вовремя не взлетела, и пришлось мне, как админу и бывшему программисту, сделать затычку для кадровиков, чтобы они всё-таки вводили нужную информацию в MS AD (и далее она шла в Sharepoint). Сама приблуда была где-то о трех формах на Delphi (список пользователей с поиском и форма ввода/редактирования пользователя), была сляпана за полдня (Delphi, как средство RAD, позволяло делать такие приблуды очень быстро), красотой не отличалась, но работать кадровикам в ней было всё проще, чем в AD Users & Computers (шатной консоли управления пользователемя в AD, к которой для управления атрибутами MS Exchange прилагалось расширение). Короче, где-то полгода оно так жило, а потом ERP-шники свою часть таки допилили и всё стало красиво.
А вот идея хранить сведения в JSON мне не нравится. Значение JSON - это ведь объект, так почему бы не хранить объект прямо в каталоге - он под это заточен и для ииспользующих каталог таким образом у него есть плюшки: схемы всех хранимых объектов (что облегчает поддержание порядка), возможность реплицировать эти объекты по отдельным атрибутам и значениям многозначных атрибутов (не знаю за ALD Pro, но AD это умеет) и править, соответственно эти атрибуты независимо, при необходимости нужные атрибуты можно проиндексировать и т.д. Так что, я бы предпочел не колхозить что-то свое на JSON, а использовать возможности каталога. Но выбор, конечно - за вами, разработчиками.
Что учесть при эксплуатации ALD Pro: подводные камни, лайфхаки и неочевидные особенности