Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Денис

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

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

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

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

Давайте начнём с самого актуального: Ваше приложение (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. Да я и не сужу :) Ваши советы реально помогают :)

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

Понял, спасибо.
Тогда еще несколько вопросов - вот получается у меня теперь 2 базы в OpenLDAP - {1}mdb - созданная при установке OpenLDAP, и {2}ldap, созданная при настройке back_ldap.
В какой из них создать пользователей, которые могут видеть только то, что акузапо в ACL базы {2}ldap?
С одной стороны - логично выглядит - что их надо создавать в базе {2}ldap, но не будут ли эти пользователи пересекаться с пользователями AD?
А могут ли пользователи AD ходить в OpenLDAP со своими учетками? Попробовал - не выходит. Это может быть из-за того, что я запускаю ldapsearch к OpenLDAP с учеткой AD но с simple binding, а в AD - digest-md5? 

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

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

Это понятно, читал, спасибо. Мне в общем и не нужно, чтобы OpenLDAP решал несвойственные ему задачи. Нужно только чтобы keycloak, некоторые интерфейсы которого торчат в инет, видел не весь AD а его часть, необходимую для работы приложения. Соответственно, в качестве сервера LDAP (провайдера аутентификации и ролей/групп пользователей) для keycloak будет выступать не весь AD, а только его часть, которая экспозится OpenLDAPом через ACL. Но с AD/LDAP я лет 15 не работал, поэтому вот прорываюсь с боем :)

4
Продолжение истории с проксированием AD через OpenLDAP,

Попытался теперь настроить ACL, чтобы в OpenLDAP попадала только одна OU, а все остальные объекты AD были не видны:
dn: olcDatabase={2}ldap,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to dn.children="OU=OTF-IS-Groups,OU=OTF,OU=BLAHBLAH,DC=corp,DC=blahblah,DC=com"
    filter="(&(objectClass=organizationalUnit)(!(objectClass=computer))(distinguishedName=OU=OTF-IS-Testit,OU=OTF-IS-Groups,OU=OTF,OU=BLAHBLAH,DC=corp,DC=blahblah,DC=com))"
    attrs=distinguishedName,ou
    by users read
    by * none
-
replace: olcAccess
olcAccess: {1}to * by * none


но после запроса
ldapsearch -H ldap://someldap.blahblah.com/ -x -D "cn=openldap,dc=corp,dc=blahblah,dc=com" -W "(objectClass=*)"

все равно вижу весь AD

это может быть из-за того, что я выполняю ldapserch от сервисного DN cn=openldap,dc=corp,dc=blahblah,dc=com - olcRootDN, RootPW которого прописаны в конфиге olcDatabase={2}ldap?
или я где-то в конфиге ACL ошибся?

5

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


А вот так - заработало - только с паролем в открытом виде

Огромное спасибо, Егор!

6

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

Ввожу руками пароль, из базы sasl не привязывал

Могу попробовать отловить хеш через tcpdump

7

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

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

вот работающий запрос к AD

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

вот результат

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

# corp.blahblah.com
dn: DC=corp,DC=blahblah,DC=com
objectClass: top
objectClass: domain
objectClass: domainDNS
distinguishedName: DC=corp,DC=blahblah,DC=com
instanceType: 5
whenCreated: 20151216133710.0Z
whenChanged: 20230514124954.0Z
subRefs: DC=ForestDnsZones,DC=corp,DC=blahblah,DC=com


8
ldappasswd - ему нужен валидный пользователь

собрал хеш по схеме
hash='{MD5}' + base64(md5(username+realm+password))

получилось такое
{MD5}HMqjnyedjgJLkUuv4kq7GQ==

попробовал
ldapmodify -Y EXTERNAL -H ldapi:/// -f ./modify-olcDBIDAssert.ldif -V
dn: olcDatabase={2}ldap,cn=admin,cn=config
changetype: modify
delete: olcDbIDAssertBind
-
add: olcDbIDAssertBind
olcDbIDAssertBind: bindmethod="sasl" binddn="cn=denis.sutyagin,dc=corp,dc=blahblah,dc=com" mode="self" saslmech="DIGEST-MD5" credentials="{MD5}HMqjnyedjgJLkUuv4kq7GQ=="

изменить не получается - говорит
No such object (32)
matched DN: cn=config

возможно тут надо ACL настраивать? я до этого не добрался еще

PS:
с этим все получилось - после того как переинициализировал OpnLDAP
но результат - тот же - не видит AD

9
я вроде там такое вставил.. или неправильно?
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 ?

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

11
Конфигурация через 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 только начал разбираться....

Страницы: [1]
Эта страница

Содержание

Новости:
Форум проекта Pro-LDAP.ru
OpenLDAP 2.4 Руководство

Содержание

Введение в службы каталогов OpenLDAPБыстрое развёртывание и начало работыОбщая картина - варианты конфигурацииСборка и установка OpenLDAPНастройка slapd

 

Конфигурационный файл slapdЗапуск slapdКонтроль доступаОграниченияИнструментыМеханизмы манипуляции даннымиНаложенияСпецификация схемы

 

БезопасностьSASLTLSРаспределённая служба каталоговРепликацияОбслуживаниеМониторингПроизводительностьУстранение неполадок
Перевод официального руководства OpenLDAP 2.4 Admin Guide
Полное содержание здесь
LDAP для учёных-ракетчиков

Содержание

О книгеКонцепции LDAPОбъекты LDAPУстановка LDAPПримерыНастройкаРепликация и отсылкиLDIF и DSMLПротоколLDAP API

 

HOWTOНеполадкиПроизводительностьИнструменты LDAPБезопасностьЗаметкиРесурсы LDAPRFC и X.500ГлоссарийОбъекты
Перевод "LDAP for Rocket Scientists"
Полное содержание здесь
Ресурсы

Книги

Руководство OpenLDAP 2.4LDAP для учёных-ракетчиков

Другие

СтатьиТермины LDAPman-страницы OpenLDAP 2.4Список RFCКлиенты LDAPФайлы наборов схемы
Полезные ресурсы
Форум

 

Разделы форумаНепрочитанные сообщенияПоследние сообщения
Форум проекта
Главная

Pro-LDAP.ru

О проектеНовости проектаУчастникиСтаньте участником!Сообщите об ошибке!Об авторских правахСоглашения проекта
Присоединяйсь!