Сообщения

1

Работа с LDAP-клиентами / Re: Неверный сертификат LAM

« : 19 Февраль 2024, 14:19:07 »

sssd.conf (клиенты)

Код: [Выделить]

ldap_tls_reqcert = allow
ldap_tls_cacert = /etc/ssl/ldap/ca_cert.pem
ldap_tls_cacertdir = /etc/ssl/ldapЯ так понимаю, что на клиенте прописан сертификат УЦ. В админке LAM прописан он же: ca_cert.pem. Срок его действия истек.

slapd.conf (сервер)

Код: [Выделить]

TLS_CACERT /etc/ldap/ca_cert.pem

cn=config.ldif (сервер)

Код: [Выделить]

olcTLSCACertificateFile: /etc/ssl/certs/ca_server.pem
olcTLSCertificateKeyFile: /etc/ssl/private/ldap_server.key
olcTLSCertificateFile: /etc/ssl/certs/ldap_server.pem
ldap_server.pem выдан УЦ действителен до 2032 года

Я запутался .. получается что на сервере, что на клиентах один и тот же сертификат УЦ

Фигня какая то получается

2

Работа с LDAP-клиентами / Re: Неверный сертификат LAM

« : 01 Февраль 2024, 07:51:39 »

Кэп ), соответственно на всех клиентах его тоже нужно будет поменять?

3

Работа с LDAP-клиентами / Неверный сертификат LAM

« : 23 Январь 2024, 09:16:34 »

Добрый день, коллеги. Не могу подрубиться к LDAP серверу через вебморду LDAP Account Manager
В syslog следующие записи:

Код: [Выделить]

Jan 23 09:29:24 ldap php: LDAP Account Manager (ххх) - DEBUG: Display login page
Jan 23 09:29:29 ldap php: LDAP Account Manager (ххх) - ERROR: Unable to start TLS encryption. Please check if your server certificate is valid and if the LDAP server supports TLS at all.
У Апача, да, сертификат хоста просрочен его сгенерировать нужно? У LDAP сертификат тоже просрочен, но вроде все работает. Клиенты (sssd) базу читают.
Не подскажете правильный путь замены сертификатов, я то то в мануале у LAM не нашел..

4

Схема данных, наборы Schema, объектные классы, атрибуты и другое / Re: Пересечения GID Unix групп в разных дистрибутивах

« : 03 Март 2023, 08:00:57 »

Добрый день!

Вообще в LDAP и в OpenLDAP в частности ограничений на совпадение GID не предусмотрено (можно специально заморочится с настройкой уникальных значений, но обычно этим никто не занимается). Так что ограничения, вероятнее всего, исходят со стороны LAM. Поскольку LAM написан на php, то можно найти и "отменить" это ограничение. И при обновлении LAM не забывать этот момент. Но, честно говоря, это решение мне не очень нравится.

честно говоря мне тоже  как впрочем и сам LAM

Если у Вас авторизация пользователей завязанна на системных группах, можно попытаться "унифицировать" номера системных групп для разных ОС. То есть настроить NSS и PAM так, чтобы они не получали информацию из /etc/group вообще, а всё брали из каталога. Но тогда все-все системные группы из разных ОС нужно завести в каталоге и при установке новых сервисов не забывать прописывать в каталог новые системные группы....

Наконец, можно авторизацию пользователей организовать не на системных группах, а на "пользовательских". То есть выделить для авторизации в приложениях какой-нибудь диапазон GID, например, от 20000 до 29999, и заводить группы в этом диапазоне, например, CanSudo c gid 20001, соответственно в /etc/sudoers задавать права для группы CanSudo. Таких групп может быть несколько с разными правами на выполенние разных задач (CanSudoReloadNginx, CanSudoReloadSamba и т.п.). Разумеется, это касается не только sudo, практически в любых приложениях можно настроить авторизацию по группам. Тогда системные группы останутся для сугубо систеных нужд, и не надо сильно заморачиваться с NSS и PAM. Надеюсь, принцип понятен.

Вообще, всё (многое) зависит от конкретных задач по авторизации, которые Вы решаете. Если нужен более конкретный совет, то опишите задачу более подробно (можно в личку).

Егор

Большое спасибо за помощь! Теперь я знаю, что делать ... меняю LAM на FusionDirectory. Изначально отказался от его использования в силу замороченности интерфейса и избытка возможностей.

П.С. А задача стоит следующая. Сделать сквозную авторизацию в разнородных системах (так уж вышло, что в организации зоопарк с ОС) -> пользователи Postfix и Dovecot и RoundCube + adressbook (это уже сделал, но не знаю как сделать автоподпись в письме из каталога) -> пользователи NFS сервера (это уже сделал) -> пользователи RunaWFE (готово) -> пользователи X2Go сервер (сделал) -> авторизация pfSense (не делал еще) -> 1C (пока не знаю даже как подступиться)

Вот такие планы

5

Схема данных, наборы Schema, объектные классы, атрибуты и другое / Пересечения GID Unix групп в разных дистрибутивах

« : 22 Февраль 2023, 13:43:52 »

Добрый день ) Помогите разобраться пожалуйста ..

Есть сеть в которой АРМы на Debian, Gentoo, CentOS. Пользователи могут работать на разных АРМах но профиль один на NFS сервере, и он подгружается автоматом.

Решил сделать единую авторизацию через LDAP. Настроил сервер, прикрутил LAM, залил базу пользователей с паролями, залил системные группы Debian (7 lp, 27 sudo, 44 video ну и далее по списку). Настроил на Debian машинах sssd, pam. В общем все живет работает, супер удобно.
Пользователи в ou=people,dc=ppp,dc=ru
Группы в ou=group,dc=ppp,dc=ru

Мне бы догадаться, что группы системные разные могут быть в дистрибутивах, а так же пересекаться... но нет. Погнал настраивать дальше АРМы с Calculate Linux. sssd и pam настроил, все работает, пользователь авторизуется ... а вот с правами что то не ладное. Оказалось, что пересекаются системные группы, например: 27 в Дебиан это SUDO, а в Кальке это Video. Или 10 в Дебиан это LPADMIN, а в Кальке это WHEEL.

тогда я догадался разбить группы по операционкам типа:
Дебиан ou=deb,ou=group,dc=ppp,dc=ru
Калька ou=calc,ou=group,dc=ppp,dc=ru

и думал, что смогу сделать так:
cn=sudo,ou=deb,ou=group,dc=ppp,dc=ru где GID 27
и
cn=video,ou=calc,ou=group,dc=ppp,dc=ru где GID 27

соответственно на АРМах в sssd.conf я вместо ldap_search_base = dc=porttlt,dc=ru
явно указываю на Дебиан машинах:
ldap_group_search_base = ou=deb,ou=group,dc=porttlt,dc=ru

на Кальке соответственно:
ldap_group_search_base = ou=calc,ou=group,dc=porttlt,dc=ru

и каждой системе будет прилетать нужный набор групп,

я ошибался. LAM не дает создать в разных суффиксах группы с одним GIDом

Как мне быть? подскажите пожалуйста )