Назад | Перейти на главную страницу

Невозможно аутентифицировать пользователей OpenLDAP на клиентах macOS «пользователь не найден: секрет в базе данных отсутствует»

У меня есть сервер Ubuntu 16.04, на котором запущен сервер OpenLDAP. Я все прекрасно вижу:

serveradmin@Magic:~$ ldapsearch -x -H ldap://localhost -D cn=admin,dc=example,dc=com -W
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# example.com
dn: dc=example,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: work
dc: example

# admin, example.com
dn: cn=admin,dc=example,dc=com
objectClass: simpleSecurityObject
...

# Groups, example.com
dn: ou=Groups,dc=example,dc=com
objectClass: organizationalUnit
ou: Groups

...

# Policies, example.com
dn: ou=Policies,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Policies
description: Password policy for users

# foo, People, example.com
dn: uid=foo,ou=People,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
sn: foo
...

На любом моем клиенте macOS по моему выбору из ОС High Sierra вплоть до El Capitan Я могу бегать:

a0216:data admin$ dscl localhost -list /LDAPv3/example.com/Users
foo
bar
...

Будет получен список всех моих пользователей.


Я использую MacBook Pro 2016 года выпуска. High Sierra. Когда я пытался пройти аутентификацию в качестве пользователя с помощью утилиты каталогов, она успешно позволяет мне аутентифицироваться:

Jun 14 16:36:23 magic slapd[344850]: conn=1276 op=1 SRCH attr=uidNumber uid userPassword
Jun 14 16:36:23 magic slapd[344850]: conn=1276 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 14 16:36:24 magic slapd[344850]: conn=1277 fd=19 ACCEPT from IP=10.0.1.20:65410 (IP=0.0.0.0:389)
Jun 14 16:36:24 magic slapd[344850]: conn=1277 fd=19 closed (connection lost)
Jun 14 16:36:24 magic slapd[344850]: conn=1278 fd=19 ACCEPT from IP=10.0.1.20:65411 (IP=0.0.0.0:389)
Jun 14 16:36:24 magic slapd[344850]: conn=1278 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
Jun 14 16:36:24 magic slapd[344850]: conn=1278 op=0 SRCH attr=supportedSASLMechanisms defaultNamingContext namingContexts schemaNamingContext saslRealm
Jun 14 16:36:24 magic slapd[344850]: conn=1278 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 14 16:36:24 magic slapd[344850]: conn=1278 op=1 BIND dn="uid=foo,ou=People,dc=example,dc=com" method=128
Jun 14 16:36:24 magic slapd[344850]: conn=1278 op=1 BIND dn="uid=foo,ou=People,dc=example,dc=com" mech=SIMPLE ssf=0
Jun 14 16:36:24 magic slapd[344850]: conn=1278 op=1 RESULT tag=97 err=0 text=

Однако, если я попытаюсь сделать то же самое на iMac, работающем либо High Sierra, или El Capitan Получаю следующее:

Jun 14 16:40:04 magic slapd[344850]: conn=1345 op=3 SRCH attr=uidNumber uid userPassword
Jun 14 16:40:04 magic slapd[344850]: conn=1345 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 14 16:40:04 magic slapd[344850]: conn=1358 fd=19 ACCEPT from IP=10.0.1.67:49545 (IP=0.0.0.0:389)
Jun 14 16:40:04 magic slapd[344850]: conn=1358 fd=19 closed (connection lost)
Jun 14 16:40:04 magic slapd[344850]: conn=1359 fd=19 ACCEPT from IP=10.0.1.67:49546 (IP=0.0.0.0:389)
Jun 14 16:40:04 magic slapd[344850]: conn=1359 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
Jun 14 16:40:04 magic slapd[344850]: conn=1359 op=0 SRCH attr=supportedSASLMechanisms defaultNamingContext namingContexts schemaNamingContext saslRealm
Jun 14 16:40:04 magic slapd[344850]: conn=1359 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 14 16:40:04 magic slapd[344850]: conn=1359 op=1 BIND dn="" method=163
Jun 14 16:40:04 magic slapd[344850]: conn=1359 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: security flags do not match required
Jun 14 16:40:04 magic slapd[344850]: conn=1359 op=2 BIND dn="" method=163
Jun 14 16:40:04 magic slapd[344850]: SASL [conn=1359] Failure: no secret in database
Jun 14 16:40:04 magic slapd[344850]: conn=1359 op=2 RESULT tag=97 err=49 text=SASL(-13): user not found: no secret in database
Jun 14 16:40:04 magic slapd[344850]: conn=1359 op=3 UNBIND
Jun 14 16:40:04 magic slapd[344850]: conn=1359 fd=19 close

Я перепробовала все, что только могла придумать, и чувствую, что ответ смотрит прямо мне в лицо. Кто-нибудь знает, почему я продолжаю получать No secret in database при попытке войти в систему с iMac, и есть ли простое решение этой проблемы?

Я провел небольшое исследование и обнаружил несколько вещей (IE этот) однако, какие направления и идеи я обнаружил, неясно, и кажется, что это работает для всех по-разному. Любая помощь или указание в правильном направлении будут очень благодарны. Спасибо

Я ПОНЯЛ!

Итак, проблема в том, что macOS пытается аутентифицироваться с помощью CRAM-MD5. По умолчанию OpenLDAP - DIGEST-MD5. Чтобы это работало, вы должны добавить алгоритм хеширования в список на случай сбоя аутентификации SASL. Для этого:

sudo su 
/usr/libexec/PlistBuddy -c "add ':module options:ldap:Denied SASL Methods:' string DIGEST-MD5" /Library/Preferences/OpenDirectory/Configurations/LDAPv3/yourldapserver.plist 
/usr/libexec/PlistBuddy -c "add ':module options:ldap:Denied SASL Methods:' string CRAM-MD5" /Library/Preferences/OpenDirectory/Configurations/LDAPv3/yourldapserver.plist
/usr/libexec/PlistBuddy -c "add ':module options:ldap:Denied SASL Methods:' string NTLM" /Library/Preferences/OpenDirectory/Configurations/LDAPv3/yourldapserver.plist
/usr/libexec/PlistBuddy -c "add ':module options:ldap:Denied SASL Methods:' string GSSAPI" /Library/Preferences/OpenDirectory/Configurations/LDAPv3/yourldapserver.plist 

Перезагрузите Mac, и он будет работать успешно. Кроме того, убедитесь, что вы скопировали файл plist, чтобы вам больше не пришлось с ним связываться!

Я также столкнулся с этим при интеграции MacOS с моим IAM-решением на основе OpenLDAP, которое имеет хешированные пароли и, следовательно, не поддерживает механизмы запроса-ответа, такие как CRAM-MD5 или DIGEST-MD5:

MacOS пробует механизмы SASL, найденные в атрибуте rootDSE сервера LDAP. поддерживаетсяSASLМеханизмы. Поэтому вместо настройки механизмов SASL в каждом клиенте MacOS LDAP я сделал нежелательные механизмы SASL невидимыми для ACL в конфигурации OpenLDAP (статической).

Следующие два ACL делают невидимыми все механизмы SASL, кроме EXTERNAL (используются для LDAPI и с сертификатами клиентов TLS):

# allow anonymous access to supportedSASLMechanisms: EXTERNAL
access to
  dn.base=""
  attrs=supportedSASLMechanisms
  val.regex="^EXTERNAL$"
    by * read
# deny access to all other SASL mech values
access to
  dn.base=""
  attrs=supportedSASLMechanisms
    by * none