Как заставить аутентификацию SASL работать с DIGEST-MD5 для OpenLDAP?

Я настраиваю OpenLDAP slapd на Ubuntu 14.04 Trusty Tahr. Я хочу, чтобы определенные экземпляры (репликация и т. Д.), Которые не являются пользователями, могли входить через SASL с помощью DIGEST-MD5 механизм.

В отличие от пользователей, они не должны иметь соответствующего DN (вместе с паролем) в дереве каталогов. Вместо этого их учетные данные должны храниться извне, следовательно SASL,

я использую saslauthd прямо сейчас (это не сложное требование, если его можно настроить, например, для работы с прямым доступом к sasldb), и оно отлично работает с использованием механизмов PLAIN а также LOGIN пока он не использует механизмы DIGEST-MD5 а также CRAM-MD5,

Что я пропускаю или делаю неправильно? Как я могу заставить его работать с DIGEST-MD5 ?


OpenLDAP настроен для SASL в /etc/ldap/sasl2/slapd.conf как это:

mech_list: EXTERNAL DIGEST-MD5 CRAM-MD5 PLAIN LOGIN
pwcheck_method: saslauthd
saslauthd_path: /var/run/saslauthd/mux


Интересные (измененные) варианты в /etc/default/saslauthd являются:

START=yes
MECHANISMS="sasldb"

Они приводят к saslauthd начинается так:

/usr/sbin/saslauthd -a sasldb -c -m /var/run/saslauthd -n 5


Я воспроизвожу неудачный случай с DIGEST-MD5 как это:

# ldapsearch -U replication -ZZ -Y DIGEST-MD5 -H ldap://ldap-master.example.com/ -b "dc=example,dc=com" "(objectClass=*)"
SASL/DIGEST-MD5 authentication started
Please enter your password: 
ldap_sasl_interactive_bind_s: Invalid credentials (49)
    additional info: SASL(-13): user not found: no secret in database

Часть в журнале slapd, где она, похоже, не работает (ведение журнала включено any) выглядит так:

slapd[23330]: [rw] authid: "uid=replication,cn=digest-md5,cn=auth" -> "uid=replication,cn=digest-md5,cn=auth"
slapd[23330]: slap_parseURI: parsing uid=replication,cn=digest-md5,cn=auth
slapd[23330]: >>> dnNormalize: <uid=replication,cn=digest-md5,cn=auth>
slapd[23330]: <<< dnNormalize: <uid=replication,cn=digest-md5,cn=auth>
slapd[23330]: <==slap_sasl2dn: Converted SASL name to uid=replication,cn=digest-md5,cn=auth
slapd[23330]: slap_sasl_getdn: dn:id converted to uid=replication,cn=digest-md5,cn=auth
slapd[23330]: SASL Canonicalize [conn=1002]: slapAuthcDN="uid=replication,cn=digest-md5,cn=auth"
slapd[23330]: SASL [conn=1002] Failure: no secret in database
slapd[23330]: SASL [conn=1002] Debug: DIGEST-MD5 common mech dispose
slapd[23330]: send_ldap_result: conn=1002 op=2 p=3
slapd[23330]: send_ldap_result: err=49 matched="" text="SASL(-13): user not found: no secret in database"
slapd[23330]: send_ldap_response: msgid=3 tag=97 err=49

Там нет ничего в /var/log/auth.log ни в отладочном выводе saslauthd когда я запускаю его вручную, что, вероятно, указывает на то, что slapd даже не дошел до передачи аутентификации saslauthd (в отличие от рабочего случая, см. ниже).


Я воспроизвожу рабочий случай с PLAIN или же LOGIN как это:

# ldapsearch -U replication -ZZ -Y PLAIN -H ldap://ldap-master.example.com/ -b "dc=example,dc=com" "(objectClass=*)"
SASL/PLAIN authentication started
Please enter your password: 
SASL username: replication
SASL SSF: 0
# extended LDIF
…

Соответствующая часть в slapd Журнал, в котором указан сбой для вышеприведенного случая, теперь выглядит следующим образом:

slapd[23330]: [rw] authid: "uid=replication,cn=plain,cn=auth" -> "uid=replication,cn=plain,cn=auth"
slapd[23330]: slap_parseURI: parsing uid=replication,cn=plain,cn=auth
slapd[23330]: >>> dnNormalize: <uid=replication,cn=plain,cn=auth>
slapd[23330]: <<< dnNormalize: <uid=replication,cn=plain,cn=auth>
slapd[23330]: <==slap_sasl2dn: Converted SASL name to uid=replication,cn=plain,cn=auth
slapd[23330]: slap_sasl_getdn: dn:id converted to uid=replication,cn=plain,cn=auth
slapd[23330]: SASL Canonicalize [conn=1006]: slapAuthcDN="uid=replication,cn=plain,cn=auth"
slapd[23330]: daemon: activity on 1 descriptor
slapd[23330]: daemon: activity on:
slapd[23330]: 
slapd[23330]: daemon: epoll: listen=8 active_threads=0 tvp=zero
slapd[23330]: daemon: epoll: listen=9 active_threads=0 tvp=zero
slapd[23330]: daemon: epoll: listen=10 active_threads=0 tvp=zero
slapd[23330]: SASL proxy authorize [conn=1006]: authcid="replication" authzid="replication"
slapd[23330]: conn=1006 op=1 BIND authcid="replication" authzid="replication"
slapd[23330]: SASL Authorize [conn=1006]:  proxy authorization allowed authzDN=""
slapd[23330]: send_ldap_sasl: err=0 len=-1
slapd[23330]: conn=1006 op=1 BIND dn="uid=replication,cn=plain,cn=auth" mech=PLAIN sasl_ssf=0 ssf=128
slapd[23330]: do_bind: SASL/PLAIN bind: dn="uid=replication,cn=plain,cn=auth" sasl_ssf=0
slapd[23330]: send_ldap_response: msgid=2 tag=97 err=0

И то и другое /var/log/auth.log и отладочный вывод из saslauthd теперь содержат это:

saslauthd[23354]: rel_accept_lock : released accept lock
saslauthd[23358]: get_accept_lock : acquired accept lock
saslauthd[23354]: cache_get_rlock : attempting a read lock on slot: 458
saslauthd[23354]: cache_lookup    : [login=replication] [service=] [realm=ldap]: not found, update pending
saslauthd[23354]: cache_un_lock   : attempting to release lock on slot: 458
saslauthd[23354]: cache_get_wlock : attempting a write lock on slot: 458
saslauthd[23354]: cache_commit    : lookup committed
saslauthd[23354]: cache_un_lock   : attempting to release lock on slot: 458
saslauthd[23354]: do_auth         : auth success: [user=replication] [service=ldap] [realm=] [mech=sasldb]
saslauthd[23354]: do_request      : response: OK


Видимо, должна быть какая-то разница в том, как это работает с PLAIN а также LOGIN против DIGEST-MD5 а также CRAM-MD5,


Обновление и уточнение:

DN, используемые для авторизации доступа к дереву, uid=replication,cn=digest-md5,cn=auth а также uid=replication,cn=plain,cn=auth соответственно, и в соответствии с разделом 15.2.5 http://www.openldap.org/doc/admin24/sasl.html эти DN не должны фактически существовать в дереве (что должно быть истинно, по крайней мере, для PLAIN а также LOGIN как там все работает нормально).
В целях тестирования я в настоящее время использую olcAccess: to * by dn.regex="replication" read by * break чтобы убедиться, что вход в систему репликации получает, по крайней мере, доступ на чтение ко всему (да, я знаю, что это небезопасно, и я дам ему соответствующие разрешения для производства) в главном дереве LDAP.

Полномочия находятся в /etc/sasldb2 и они успешно проверены при использовании PLAIN или же LOGIN (см. выше). Для справки, это выглядит так:

# sasldblistusers2
replication@ldap-master: userPassword
…

# db_dump -p /etc/sasldb2 
VERSION=3
format=print
type=hash
h_nelem=4
db_pagesize=4096
HEADER=END
 replication\00ldap-master\00userPassword
 PasswordCensored
…

Тем не менее, в случае DIGEST-MD5 а также CRAM-MD5 это не похоже на контакт saslauthd вообще (из-за того, что я что-то упустил или сделал что-то не так, возможно), поэтому с базой данных, скорее всего, тоже не справились.

Источник

3 ответа

Решение

Мой рецепт для OpenLDAP, чтобы проверить напрямую /etc/sasldb2,

Первый шаг: обеспечить /etc/sasldb2 принадлежит пользователю slapd.

Следующий шаг: есть slapd не искать учетные данные в дереве каталогов, что делается следующим образом:

dn: cn=config
changetype: modify
replace: olcSaslAuxprops
olcSaslAuxprops: sasldb

Позже вам также понадобится olcAuthzRegexp правило, но для того, чтобы проверить, работает ли аутентификация, это необязательно.

Эти настройки работают на Debian GNU/Linux Jessie OpenLDAP-2.4.40, созданной из исходного кода.

Источник

Методы CRAM-MD5 и DIGEST-MD5 невозможны с помощью "pwcheck_method: saslauthd". Им нужны простые, незашифрованные пароли в самой директории LDAP.

Источник

Я провел несколько обширных тестов с различными конфигурациями с разными учетными данными в sasldb,

В заключение выясняется, что проблема, которая меня больше всего преследовала, заключалась в том, что согласно какому методу аутентификации (saslauthd против auxprop) (который, в свою очередь, зависит от запрошенного механизма аутентификации - DIGEST-MD5/CRAM-MD5 против PLAIN/LOGIN), искал другое domain, Я не ожидал этого, и поскольку у меня была только одна пара домен-пользователь в sasldb, он не нашел другого.

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

  1. В случае, если вы просите PLAIN или же LOGIN механизм, slapd будет использовать метод аутентификации, настроенный в pwcheck_method в /etc/ldap/sasl2/slapd.conf,
  2. В случае, если вы просите DIGEST-MD5 или же CRAM-MD5 механизм, slapd всегда будет использовать auxprop метод, независимо от того, что настроено для pwcheck_method,
  3. По сути, это означает, что вы можете иметь slapd используйте тот же метод для всех 4 механизмов, если вы настраиваете pwcheck_method: auxprop, Или вы можете решить использовать 2 различных метода, если вы настраиваете что-то другое для pwcheck_method,
  4. В любом случае, auxprop_plugin в /etc/ldap/sasl2/slapd.conf игнорируется Вместо slapd использует то, что настроено для olcSaslAuxprops в своей собственной базе данных конфигурации. Обратите внимание, что это верно как для неявного auxprop метод при запросе DIGEST-MD5 или же CRAM-MD5 механизмы, а также для явно настроенного pwcheck_method: auxprop при запросе одного из двух других механизмов.
  5. В моем случае, saslauthd ищет учетные данные с неукрашенным именем хоста (т.е. просто ldap-master) как domain составная часть. Если бы я сделал обоснованное предположение, я бы сказал, что он использует что-то вроде gethostname() чтобы придумать это, так что это может быть как-то настраивается.
  6. В моем случае при прохождении auxprop так или другой, slapd использует полное доменное имя (т.е. ldap-master.example.com) как domain составная часть. Вероятно, это происходит из исходного URL-адреса запроса (мои альтернативы для генерации запроса ограничены, когда я хочу использовать STARTTLS и хочу иметь возможность правильно проверить сертификат сервера, который запрашивает соответствующее доменное имя), но это может быть настроен настройкой olcSaslHost в slapdбаза данных конфигурации. Обратите внимание, что я не пытался настроить его.

Итак, для создания рабочей конфигурации у вас есть несколько вариантов:

  1. Если ты в порядке только PLAIN а также LOGIN механизмы по STARTTLS, настроить pwcheck_method в /etc/ldap/sasl2/slapd.conf как требуется. Если это будет auxpropтакже настроить olcSaslAuxprops в slapdбаза данных конфигурации (установите ее на sasldbНапример, если вы хотите использовать /etc/sasldb2 как хранилище учетных данных).
  2. Если ты в порядке только DIGEST-MD5 (Я обычно вижу CRAM-MD5 рекомендуется из-за плохой безопасности, поэтому старайтесь избегать этого), установите olcSaslAuxprops в slapdбаза данных конфигурации, как auxprop метод будет использоваться независимо от того, что вы настраиваете pwcheck_method,
  3. Если вы хотите иметь возможность использовать механизмы из набора DIGEST-MD5, CRAM-MD5 (однако старайтесь избегать CRAM-MD5) а также набор PLAIN, LOGIN (убедитесь, что они используются только по зашифрованному соединению, например STARTTLS-one) и предпочитаете использовать один и тот же метод аутентификации для всех из них, а также проверять один и тот же набор учетных данных. auxprop, конфигурировать pwcheck_method: auxprop в /etc/ldap/sasl2/slapd.conf и установить olcSaslAuxprops в slapdконфигурация базы данных по мере необходимости.

  4. Если вы хотите иметь возможность использовать механизмы из обоих наборов при использовании для них разных методов аутентификации (для меня это звучит как кошмар администрирования, но все готово), настройте pwcheck_method в /etc/ldap/sasl2/slapd.conf соответственно для PLAIN а также LOGIN и помните, что вы вынуждены использовать auxprop за DIGEST-MD5 (а также CRAM-MD5 если вы настаиваете) и установить olcSaslAuxprops в slapdконфигурация базы данных по мере необходимости.

    • Если вам случится настроить saslauthd для непокрытых механизмов и убедитесь, что saslauthd обращается к другой базе данных, чем что slapd доступ через auxprop или использовать что-то еще, чем sasldb за olcSaslAuxprops, у вас есть они хорошо разделены и не о чем беспокоиться.

    • Если вам случится настроить saslauthd для нерушенных механизмов и sasldb за auxprop для механизмов хеширования и предоставления им доступа к одной и той же базе данных учетных данных у вас есть 3 варианта в порядке предпочтения:

      1. Так или иначе, убедитесь, что оба saslauthd так же как slapd доступ к sasldb напрямую через auxprop запросить учетные данные с тем же domain (попробуйте установить olcSaslHost или принуждение saslauthd использовать полное доменное имя), поэтому вам придется заботиться только об одной записи учетных данных для каждой сущности для аутентификации.
      2. Умышленно принимайте решение использовать разные учетные данные для хэшированных и хэшированных механизмов. Использовать userid-hostname пара для неразделенных механизмов над saslauthd и использовать userid-hostname.domain.name пара для хешированных механизмов через auxprop,
      3. Сохраняйте две учетные записи для каждой сущности для аутентификации - одну с "именем хоста", а другую с "hostname.domain.name" - и синхронизируйте пароли обоих (тьфу).
Источник
Другие вопросы по тегам