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

1

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

« Последний ответ от egor 21 Февраль 2024, 09:14:41 »

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

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

2

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

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

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

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

3

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

« Последний ответ от egor 01 Февраль 2024, 09:45:32 »

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

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

4

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

« Последний ответ от Obmorcheg 01 Февраль 2024, 07:51:39 »

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

5

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

« Последний ответ от egor 29 Январь 2024, 16:17:25 »

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

Егор

6

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

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

7

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

« Последний ответ от Денис 05 Июль 2023, 19:41:28 »

короче я дебил, все эти приседания с DIGEST-MD5 не нужны, аутентификация работает simple просто неправильно писал binddn

да, в keycloak может биндиться к OpenLDAP с учеткой из AD и в текущей конфигурации видит весь AD

но с фильтрацией пока не получается. ночью еще попробую поиграться

8

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

« Последний ответ от egor 05 Июль 2023, 17:38:36 »

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

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

9

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

« Последний ответ от Денис 05 Июль 2023, 17:14:02 »

Добрый день, Егор

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

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

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

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

olcSuffix: OU=OTF-IS-Testit,OU=OTF-IS-Groups,OU=OTF,OU=BLAHBLAH,DC=corp,DC=blahblah,DC=com

Нужно именно несколько веток AD, кроме того надо не все атрибуты пользователя показывать, так что этот вариант скорее всего не подойдет

Наконец, какие-то настройки фильтрации наверняка можно указать в самом приложении (keycloak). Никогда с ним не сталкивался, но по аналогии с другими LDAP-клиентами, практически всегда можно указать настройку типа filter. К тому же, раз там есть привязка к LDAP (LDAP-клиент), то можно привязать его напрямую к AD и настроить потоньше через параметры конфигурации LDAP-клиента.

В том то и дело, что напрямую к AD - не хочется, т.к. некоторые интерфейсы keycloak торчат в инет, и если поломают keycloak - нарушителю становится доступна вся структура AD. А в случае с OpenLDAP - нарушителю придется поломать еще и OpenLDAP, чтобы добраться до AD.

P.S. Да я и не сужу Ваши советы реально помогают

10

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

« Последний ответ от egor 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. Я сам уже много лет как отошёл от администрирования. Раньше под рукой всегда была куча инструментов и стендов, сейчас же мои советы больше похожи на гадание на кофейной гуще =) . Так что не судите строго.

Егор