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

Страницы: [1] 2 3 ... 10
1
Здравствуйте! Уже сто лет не касался сертификатов в каталогах, но с ними всегда проблемы =( . Начиная от банальной кодировки сертификата в файле .cer (PEM/DER), не помню точно, в какой он должен быть при загрузке в каталог, но  файл легко переконвертировать туда-сюда с помощью команды openssl, что-то вроде:
openssl x509 -in cert.pem -out cert.der -outform DER
Реже бывает, что в файле находится не "чистый" сертификат, а обёрнутый в какой-нибудь контейнер. Тогда сертификат перед загрузкой в каталог нужно извлечь из этого контейнера.

Наконец, часто сертификаты, сгенерированные, например, CryptoPro, содержат поля, о которых не знает библиотека openssl (или другая), с которой скомпилирован OpenLDAP. Соответственно, такой сертификат не проходит валидацию на уровне криптобиблиотеки и не загружается =( .

Чтобы не заморачиваться с проверкой синтаксиса сертификатов, производители других каталогов подменяют синтаксис атрибута userCertificate на 1.3.6.1.4.1.1466.115.121.1.40 (Octet String) вместо 1.3.6.1.4.1.1466.115.121.1.8 (X.509 Certificate), обычно никаких проблем при этом не возникает. Во внутреннем каталоге вы можете сделать то же самое.

Егор

2
Добрый день.
У меня аналогичная проблема - не получается записать сертификат в userCertificate на OpenLDAP.

Записываю через ldapmodify.

Если делать так:

dn: cn=07781012064,ou=users,dc=iis,dc=loc
changetype: modify
add: userCertificate
userCertificate:< file:///root/3.cer

то получаю в ответ:

ldap_modify: Undefined attribute type (17)
        additional info: userCertificate: requires ;binary transfer

Если делать так:

dn: cn=07781012064,ou=users,dc=iis,dc=loc
changetype: modify
add: userCertificate
userCertificate;binary:< file:///root/3.cer

то получаю в ответ:

wrong attributeType at line 4, entry "cn=07781012064,ou=users,dc=iis,dc=loc"

Если делать так:

dn: cn=07781012064,ou=users,dc=iis,dc=loc
changetype: modify
add: userCertificate;binary
userCertificate;binary:< file:///root/3.cer

то получаю в ответ:

ldap_modify: Invalid syntax (21)
        additional info: userCertificate;binary: value #0 normalization failed


Подскажите, пожалуйста, в чём может быть причина? Что я делаю не так?
3
Общий раздел / Re: Вопросы про настройку БД meta
« Последний ответ от VlgSlv 05 Февраль 2021, 13:06:00 »
Спасибо огромное!
Ваш совет очень помог!
4
Общий раздел / Re: Вопросы про настройку БД meta
« Последний ответ от egor 04 Февраль 2021, 19:21:35 »
Здравствуйте!

Суть механизма meta в "склейке" двух и более разных каталогов (то есть каталогов с разными суффиксами) под одним общим корнем. То есть мы объединяем каталоги dc=first,dc=com и dc=second,dc=com под общим корнем dc=union,dc=com , тогда к содержимому первого каталога можно обратиться, например, как к dc=f,dc=union,dc=com , а к содержимому второго как к dc=s,dc=union,dc=com . Надеюсь, более-менее понятно объяснил. Метакаталог работает как прокси: получает запрос от клиента, смотрит из какого исходного каталога требуются данные и перенаправляет запрос туда, подставив нужный суффикс; получив ответ от источника данных, он выполняет обратное преобразование суффикса и отправляет полученные и преобразованные данные клиенту.

Вот хороший пример настройки (как раз про AD): http://sdn.tovy.ru/openldap-meta-backend-active-directory/. Или вот ещё: https://gist.github.com/pbruna/7229c3e99dd4bf57b73c.

Обратите внимание на директиву suffixmassage (olcDbRewrite: suffixmassage "dc=f,dc=union,dc=com" "dc=first,dc=com"), именно она отвечает за преобразование суффиксов в описанном выше процессе. Также обратите внимание, что в LDAP-URI в директиве uri (olcDbURI) должен быть указан локальный суффикс как он будет представлен в метакаталоге, а не реальный суффикс каталога. Внимательней посмотрите в примерах и поймёте, что я имею ввиду.

Кроме того, для AD в дополнение к idassert-bind требуется указать директиву idassert-authzFrom (olcDbIDAssertAuthzFrom) с тем же значением, что и в первом примере выше ("dn:*"). Без неё, насколько я помню, AD не возвращает ответа.

Это была попытка ответа на второй вопрос =) . С первым же всё просто: значение атрибута slapd преобразовал в кодировку base64, о чём свидетельствуют два двоеточия после имени атрибута. Это делается во избежание потери данных в сложном значении атрибута.

Егор
5
Access Control List (ACL) / Re: Общие ACL для двух серверов
« Последний ответ от ferta 04 Февраль 2021, 15:03:54 »
Спасибо
6
Общий раздел / Вопросы про настройку БД meta
« Последний ответ от VlgSlv 04 Февраль 2021, 12:56:41 »
Доброго всем!
Возможно вопросы ламерские  - недавно только занялся openldap.
Погуглил + поискал по форуму, ответов на них не нашел (может плохо искал)
Есть локальный ЛДАП и АД настраиваю БД meta следующим образом
# {3}meta, config
dn: olcDatabase={3}meta,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMetaConfig
olcDatabase: {3}meta
olcSuffix: dc=AA,dc=BB,dc=CC
olcDbOnErr: continue

далее uri
#локальный ЛДАП
dn: olcMetaSub={0}uri,olcDatabase={3}meta,cn=config
objectClass: olcMetaTargetConfig
olcMetaSub: uri
olcDbURI:"ldap://192.16.20.20/dc=ldap,dc=AA,dc=BB,dc=CC"
olcDbIDAssertBind: bindmethod=simple binddn="CN=admin,DC=AA,DC=BB,DC=CC" credentials=ping mode=none
olcDbProtocolVersion: 3
olcDbRebindAsUser: FALSE

# Active Directory
dn: olcMetaSub={1}uri,olcDatabase={3}meta,cn=config
objectClass: olcMetaTargetConfig
olcMetaSub: uri
olcDbURI:"ldap://10.14.20.6/ou=uf,dc=AA,dc=BB,dc=CC"
olcDbIDAssertBind: bindmethod=simple binddn="CN=user,OU=Service Accounts,OU=DR,OU=UF,DC=UF,DC=RT,DC=RU" credentials= pong  mode=none
olcDbProtocolVersion: 3
olcDbRebindAsUser: FALSE

Вопросы следующие:
1.  olcMetaSub и {3}meta добавлялись через ldapadd  ... -f add.ldif , но после
ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config
обноружил , что  olcDbIDAssertBind: представлено ввиде
olcDbIDAssertBind:: YmluZG1ldGh  .... =


2. если я ищу пользователя из локального ЛДАП, что из АД
ldapsearch -vvv  -x -b "dc=AA,dc=BB,dc=CC"  -H "ldap://192.16.20.20"   "(uid=userLDAP)"
ldapsearch -vvv   -x -b "dc=AA,dc=BB,dc=CC"  -H "ldap://192.16.20.20"   "(sAMAccountName=userAD)"
то в ответ получаю
# search result
search: 2
result: 1 Operations error
Но в логах сервера  в первом случае имею найденного пользователя в "локальном ЛДАП", но ошибку при обращении к АД
Feb  4 12:19:03 ubuntuLDAP slapd[30519]: [rw] searchBase: "ou=uf,dc=AA,dc=BB,dc=CC" -> "ou=uf,dc=AA,dc=BB,dc=CC"
Feb  4 12:19:03 ubuntuLDAP slapd[30519]: [rw] searchFilter: "(uid=userLDAP)" -> "(uid=userLDAP)"
Feb  4 12:19:03 ubuntuLDAP slapd[30519]: [rw] searchResult: "cn=Fname Lname ,ou=users,dc=ldap,dc=AA,dc=BB,dc=CC" -> "cn=Fname Lname,ou=users,dc=ldap,dc=AA,dc=BB,dc=CC"
Feb  4 12:19:03 ubuntuLDAP slapd[30519]: [rw] searchAttrDN: "cn=admin,dc=ldap,dc=AA,dc=BB,dc=CC" -> "cn=admin,dc=ldap,dc=AA,dc=BB,dc=CC"
Feb  4 12:19:03 ubuntuLDAP slapd[30519]: conn=1010 op=1 meta_back_search[1] match="" err=1 (Operations error) text="000004DC: LdapErr: DSID-0C090A7D, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v3839".
Feb  4 12:19:03 ubuntuLDAP slapd[30519]: send_ldap_result: err=1 matched="" text=""

А во втором случае
Feb  4 12:22:46 ubuntuLDAP slapd[30519]: [rw] searchBase: "ou=uf,dc=AA,dc=BB,dc=CC" -> "ou=uf,dc=AA,dc=BB,dc=CC"
Feb  4 12:22:46 ubuntuLDAP slapd[30519]: [rw] searchFilter: "(SAMACCOUNTNAME=userAD)" -> "(SAMACCOUNTNAME=userAD)"
Feb  4 12:22:46 ubuntuLDAP slapd[30519]: conn=1011 op=1 meta_back_search[1] match="" err=1 (Operations error) text="000004DC: LdapErr: DSID-0C090A7D, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v3839".
Feb  4 12:22:46 ubuntuLDAP slapd[30519]: send_ldap_result: err=1 matched="" text=""

Выглядит как если не правильно указаны binddn= ... и credentials в  olcDbIDAssertBind для АД, но с теми же параметрами с того же ресурса
ldapsearch -v -x -D "CN=user,OU=Service Accounts,OU=DR,OU=UF,DC=UF,DC=RT,DC=RU" -w "pong" -b "OU=UF,DC=AA,DC=BB,DC=CC" -H "ldap://10.14.20.6"  "(&(sAMAccountType=805306368)(sAMAccountName=userAD))"
имеем нормальный результат
...
# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Подскажите, где собака зарыта?



7
Access Control List (ACL) / Re: Общие ACL для двух серверов
« Последний ответ от egor 04 Февраль 2021, 11:52:16 »
Здравствуйте!

Если у вас динамическая конфигурация slapd (cn=config), то можно параллельно с репликацией рабочего каталога частично реплицировать каталог динамической конфигурации с помощью того же механизма syncprov/syncrepl для базы данных olcDatabase={0}config.

Если у вас статическая конфигурация (файл slapd.conf), можно вынести директивы ACL в отдельный файл, в slapd.conf подключить его в нужное место директивой include, а сам файл с ACL расшарить/синхронизировать между серверами (nfs, rsync или что-то ещё). После внесения изменений и синхронизации нужно будет перезапускать slapd на всех серверах.

Егор
8
Access Control List (ACL) / Общие ACL для двух серверов
« Последний ответ от ferta 04 Февраль 2021, 08:55:58 »
Здравствуйте!
Имею два сервера с настроенной репликацией между ними, на каждом сервере настроены свои ACL.
Не удобно вести параллельно два списка ACL. Поэтому вопрос, имеется ли возможность при данной схеме иметь одни общие ACL для 2-х серверов?
Спасибо.
9
Очень интересные решения с нестандартными правилами соответствия от Microsoft. Спасибо, что поделились.

Егор
10
Решено:

cat /etc/postfix/main.cf
...
virtual_alias_maps = pipemap:{ldap:/etc/postfix/ldap/ad_virtual_group.cf, ldap:/etc/postfix/ldap/ad_virtual_group_members.cf}
...

cat /etc/postfix/ldap/ad_virtual_group.cf
...
query_filter     = (&(mail=%s)(objectClass=group)(member=*))
result_attribute = distinguishedName
...

cat /etc/postfix/ldap/ad_virtual_group_members.cf
...
query_filter     = (&(userPrincipalName=*)(mail=*)(memberOf:1.2.840.113556.1.4.1941:=%s)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))
result_attribute = mail
...

Проверка:
postmap -vfq "group@doma.in" "pipemap:{ldap:/etc/postfix/ldap/ad_virtual_group.cf, ldap:/etc/postfix/ldap/ad_virtual_group_members.cf}"
Применить:
posfix reload
Страницы: [1] 2 3 ... 10