Сообщения

1

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

« : 21 Февраль 2024, 09:14:41 »

То, что на всех серверах и клиентах прописан один и тот же сертификат УЦ -- это правильно. Смысл в том, что УЦ выдаёт сертификат, например, серверу, этот сертификат подписан закрытым ключом УЦ. В сертификате УЦ есть открытый ключ УЦ. Клиент, получив сертификат сервера, проверяет его электронную подпись с помощью открытого ключа УЦ из сертификата УЦ. Если подпись корректна и клиент доверяет УЦ, значит он может доверять серверу -- это так называемая цепочка доверия (в ней могут быть разные промежуточные УЦ, тогда на клиенте должны быть сертификаты каждого из них).

То, что сертификат УЦ просрочился -- это тоже нормально. Правда, теперь на всех клиентах и на сервере придется менять сертификат УЦ (на непросроченный), а на сервере также прописывать новый сертификат сервера, подписанный закрытым ключом, парный к которому открытый ключ будет в непросроченном сертификате УЦ.

2

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

« : 01 Февраль 2024, 09:45:32 »

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

Если сертификат LDAP-сервера самоподписанный (то есть одновременно является и сертификатом сервера и сертификатом центра сертификации), то придётся его менять и на всех клиентах. Если сертификат центра сертификации (CA) отдельный и он прописан на клиентах для проверки сертификата сервера, то тогда можно сгенерировать только новый сертификат сервера и поменять его только на сервере.

3

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

« : 29 Январь 2024, 16:17:25 »

Здравствуйте! Это ошибка относится к сертификату LDAP-сервера (не Apache и не LAM). Если он просрочен, нужно его заменить по тому пути, который прописан в настройках LDAP-сервера (ваш кэп =) ).

Егор

4

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

« : 05 Июль 2023, 17:38:36 »

Simple аутентификация для Openldap точно работает

в keycloak пользователь с учёткой из AD может пройти аутентификацию с паролем из AD?

5

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

« : 05 Июль 2023, 16:06:03 »

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

Давайте начнём с самого актуального: Ваше приложение (keycloak) выполняет свои функции с Вашими нынешними настройками OpenLDAP, если не принимать в расчёт ACL? Как я понял после беглого поиска, keycloak предназначено нужно для аутентификации/авторизации пользователей, эта функция работает? Если нет, может и не стоит мучиться с ограничением доступа.

Если Вас интересуют только учётки из определённой ветки AD, то можно указать её в качестве suffix в настройках olcDatabase: ldap:

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

olcSuffix: OU=OTF-IS-Testit,OU=OTF-IS-Groups,OU=OTF,OU=BLAHBLAH,DC=corp,DC=blahblah,DC=com
Наконец, какие-то настройки фильтрации наверняка можно указать в самом приложении (keycloak). Никогда с ним не сталкивался, но по аналогии с другими LDAP-клиентами, практически всегда можно указать настройку типа filter. К тому же, раз там есть привязка к LDAP (LDAP-клиент), то можно привязать его напрямую к AD и настроить потоньше через параметры конфигурации LDAP-клиента.

P.S. Я сам уже много лет как отошёл от администрирования. Раньше под рукой всегда была куча инструментов и стендов, сейчас же мои советы больше похожи на гадание на кофейной гуще =) . Так что не судите строго.

Егор

6

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

« : 04 Июль 2023, 21:33:25 »

Как мне кажется, тут сразу несколько факторов.

Во-первых, да, на rootdn действие ACL не распространяется.

Во-вторых, директива replace при changetype: modify заменяет все значения атрибута, так что у вас в итоге должен остаться последний olcAccess  (проверьте в итоговой конфигурации). Тут, скорее всего, подойдёт replace + add.

В-третьих, в man-странице slapd-ldap в разделе "Контроль доступа" честно написано, что контроль доступа у данного backend фиктивный, и нормальный контроль доступа нужно настраивать в целевом каталоге, в Вашем случае, в AD.

Егор

7

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

« : 03 Июль 2023, 17:05:37 »

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

ldapsearch -H ldap://dc01.corp.blahblah.com/ -Y DIGEST-MD5 -U "denis.sutyagin" -b "dc=corp,dc=blahblah,dc=com" "(objectClass=*)"


Вы какие-нибудь аутентификационные данные вводите, или "оно само" откуда-то берёт? Из какой-нибудь базы sasl привязывает идентификатор пользователя с аутентификационными данными? Если да, можно попробовать извлечь хэш из этой базы.

Что касается back_ldap, я бы попробовал так:

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

olcDbIDAssertBind: bindmethod="sasl" authcId="denis.sutyagin" mode="self" saslmech="DIGEST-MD5" credentials="{MD5}HMqjnyedjgJLkUuv1kqAGQ=="

Но, опять же, построение хэша я не могу прокомментировать, просто не знаю, как его правильно собрать.

Егор

8

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

« : 03 Июль 2023, 14:23:19 »

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

Вероятно. Что получается на выходе команды?

9

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

« : 03 Июль 2023, 14:21:25 »

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

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

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

saslmech=DIGEST-MD5

В поле credentials у Вас пароль в открытом виде. Думаю, так его back_ldap в AD и передаёт. Для механизма DIGEST-MD5 нужен, скорее всего, хэш пароля.

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

Егор

10

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

« : 03 Июль 2023, 14:06:07 »

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

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

Егор

11

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

« : 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 не приходилось, готового примера у меня нет.

Егор

12

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

« : 03 Март 2023, 12:26:11 »

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

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

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

Егор

13

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

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

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

Егор

14

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

« : 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, лимиты и прочее, игнорируются.

Егор

15

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

« : 07 Ноябрь 2022, 11:00:04 »

Да, поскольку slapd я запускаю в режиме дебага (-d 256), то использую 3 терминала: в одном крутится slapd эмуляции AD, во втором slapd-shell-proxy, а в третьем, собственно, выполняются пользовательские команды ldapadd, ldapsearch. Надеюсь, понятно.

Егор