Последние сообщения

21

Конфигурация через cn=config / Re: прокси в AD

« Последний ответ от Денис 03 Июль 2023, 14:18:41 »

я вроде там такое вставил.. или неправильно?

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

olcDbIDAssertBind: bindmethod="sasl" binddn="cn=denis.sutyagin,dc=corp,dc=blahblah,dc=com" mode="self" saslmech="DIGEST-MD5" credentials="somecomplexpassword"

saslmech=DIGEST-MD5

ааа, хеш! его делать saslpasswd -s ?

22

Конфигурация через cn=config / Re: прокси в AD

« Последний ответ от egor 03 Июль 2023, 14:06:07 »

Если так, то, как минимум, в credentials в olcDbIDAssertBind нужно указывать что-то, что ожидает механизм digest-md5. Подозреваю, что это не пароль в открытом виде, скорее всего какой-нибудь хэш.

Покажите полностью строку запроса ldapsearch к AD, которая у Вас успешно выполняется.

Егор

23

Конфигурация через cn=config / Re: прокси в AD

« Последний ответ от Денис 03 Июль 2023, 13:50:46 »

Спасибо, Егор,
в нашем AD - sasl digest-md5, simple аутентификацией туда не получается попасть
когда делаю ldapsearch -x непосредственно в AD - аутентификация не проходит, а если пишу mech=DIGEST-MD5 - все ок

24

Конфигурация через cn=config / Re: прокси в AD

« Последний ответ от egor 03 Июль 2023, 12:48:19 »

Здравствуйте! Я не уверен, что AD поодерживает SASL-аутентификцию DIGEST-MD5. SIMPLE-аутентификацию он точно поддерживает, попробуйте изменить olcDbIDAssertBind:

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

olcDbIDAssertBind: bindmethod="simple" binddn="cn=denis.sutyagin,dc=corp,dc=blahblah,dc=com" mode="none" credentials="somecomplexpassword"

Осторожно: при SIMPLE-аутентификации пароль по сети будет передаваться в открытом виде, возможен его перехват.

AD также поддерживает KERBEROS-аутентификацию, она безопасная. Но у меня под рукой нет AD, чтобы протестировать вариант настройки с принципалом KERBEROS. К тому же самому раньше настраивать KERBEROS-аутентификацию для OpenLDAP не приходилось, готового примера у меня нет.

Егор

25

Конфигурация через cn=config / прокси в AD

« Последний ответ от Денис 03 Июль 2023, 11:36:46 »

Всем привет
Попробовал настроить проксирование из LDAP в AD - добавил модуль back_ldap, добавил базу ldap, настроил аутентификацию в AD
но при попытке посмотреть что-нибудь из AD - возникает ошибка

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

ldapsearch -H ldap://someldap.blahblah.com/ -x -D "cn=openldap,dc=corp,dc=blahblah,dc=com" -W -b "dc=corp,dc=blahblah,dc=com" "(objectClass=*)" -V


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

# extended LDIF
#
# LDAPv3
# base <dc=corp,dc=blahblah,dc=com> with scope subtree
# filter: (objectClass=*)
# requesting: ALL
#

# search result
search: 2
result: 80 Other (e.g., implementation specific) error



LDIF и логи в прицепе

помогите плиз, я с LDAP только начал разбираться....

26

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

« Последний ответ от egor 03 Март 2023, 12:26:11 »

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

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

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

Егор

27

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

« Последний ответ от Obmorcheg 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 (пока не знаю даже как подступиться)

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

28

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

« Последний ответ от egor 23 Февраль 2023, 15:02:03 »

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

Вообще в 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. Надеюсь, принцип понятен.

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

Егор

29

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

« Последний ответ от Obmorcheg 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ом

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

30

Общий раздел / Re: OpenLDAP - Второй фактор

« Последний ответ от egor 15 Ноябрь 2022, 10:11:26 »

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

Наличие вопросительных знаков в фильтрах -- признак того, что OpenLDAP не может найти что-то (атрибут, объектный класс) в своей схеме данных. Нужно прописать в схему данных все недостающие атрибуты и объектные классы, тогда не нужно будет городить костыли с sed.

Наличие в логах кучи мусорных строк типа

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

UNKNOWN attributeDescription "PRIMARYGROUPID" inserted.говорит о том же. Если Вам для аутентификации не нужны все эти атрибуты (подозреваю, что это так), то нужно перестроить LDAP-запрос, чтобы он их не просил у LDAP-сервера.

Я никак не могу взять в толк, зачем Вы упорно используете прокси на slapd-ldap? У Вас же и так есть AD. Получается, что между клиентом (Bitrix) и источником данных (AD) у Вас две прослойки, и обе -- сплошные костыли, а значит в два раза больше источников потенциальных ошибок. Предлагаю совсем отказать от прокси на slapd-ldap, отладить аутентификацию Bitrix сначала без второго фактора непосредственно в AD, а потом уже цеплять к AD прокси на slapd-shell для реализации второго фактора.

Настраивать Bitrix на LDAP-аутентификацию мне не приходилось. Если пришлёте настройки Bitrix в части, касающейся LDAP, посмотрю, постараюсь что-то подсказать.

По поводу rootDN и rootPw -- это учётка с правами суперпользователя на уровне каталога (то есть того фрагмента настроек, которые следуют за директивой database и корень которого определяется директивой suffix). В этом каталоге у суперпользователя полные права, все накладываемые ограничения (явные и дефолтные), в том числе ACL, лимиты и прочее, игнорируются.

Егор