Пересечения GID Unix групп в разных дистрибутивах

[Obmorcheg]

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

Есть сеть в которой АРМы на 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ом

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

[egor]

Здравствуйте!

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

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

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

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

Егор

[Obmorcheg]

Добрый день!

Вообще в 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 (пока не знаю даже как подступиться)

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

[egor]

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

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

Из всех перечисленных сервисов настраивал на аутентификацию/авторизацию в LDAP только Postfix и Dovecot, так что существенно помочь вряд ли смогу. Но желаю удачи!

Егор