Я пытаюсь использовать бэкэнд мета openldap для выполнения следующих задач в одном запросе:
запросите учетную запись в локальной базе данных openldap. (Я контролирую этот ресурс, и здесь будет храниться только несколько учетных записей.)
если учетная запись не найдена локально, то следующий запрос активный каталог (где у меня нет возможности создавать учетные записи)
Пользователь будет найден только в одном или другом, но не в обоих.
Я пытался следовать многочисленным руководствам, чтобы добиться этого, но ни один из них не соответствовал моему точному сценарию, и я не смог настроить ни один из них в рабочий режим.
Для тестирования я создал простой бэкэнд LDIF, позволяющий анонимные привязки:
database ldif
suffix "ou=local,dc=proxy,dc=ldap"
directory "/var/lib/ldap/"
Моя мета настроена следующим образом:
database meta
suffix "dc=example,dc=com"
uri "ldaps://ad.my.edu/ou=org-1,dc=example,dc=com"
suffixmassage "dc=org-1,dc=example,dc=com" "ou=axxxx,dc=sxxxx,dc=xxx,dc=xx,dc=xxx"
idassert-authzFrom "dn:*"
idassert-bind bindmethod=simple
binddn="cn=XXXX,ou=it,ou=services,ou=axxxx,dc=sxxxx,dc=nxx,dc=xx,dc=xxx"
credentials="XXXX"
mode=none
overlay rwm
rwm-map attribute uid sAMAccountName
rwm-map objectClass posixAccount person
uri "ldap://127.0.0.1/ou=org-2,dc=example,dc=com"
suffixmassage "ou=org-2,dc=example,dc=com" "ou=local,dc=proxy,dc=ldap"
Вот результат моего поиска из командной строки:
ldapsearch -x -H 'ldap://127.0.0.1' -b dc=example,dc=com -s sub '(sAMAccountNAme=xxxxxx*)' -LLL
slapd[1949]: conn=1014 op=2 UNBIND
slapd[1949]: conn=1014 fd=9 closed
slapd[1949]: conn=1015 fd=9 ACCEPT from IP=127.0.0.1:59624 (IP=127.0.0.1:389)
slapd[1949]: conn=1015 op=0 BIND dn="" method=128
slapd[1949]: conn=1015 op=0 RESULT tag=97 err=0 text=
slapd[1949]: conn=1015 op=1 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(?sAMAccountName=xxxxxxxx*)"
slapd[1949]: conn=1015 op=1 meta_search_dobind_init[0]: retrying URI="ldaps://ad.my.edu" DN="cn=xxxx,ou=it,ou=services,ou=axxxx,dc=sxxxx,dc=nxx,dc=xx,dc=xxx"
slapd[1949]: conn=1002 op=9 SRCH base="ou=local,dc=proxy,dc=ldap" scope=2 deref=0 filter="(?sAMAccountName=xxxxxxx*)"
slapd[1949]: conn=1002 op=9 SEARCH RESULT tag=101 err=32 nentries=0 text=
slapd[1949]: conn=1015 op=1 meta_back_search[1] match="" err=32 (No such object) text="".
slapd[1949]: conn=1015 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text=
ldapsearch[2054]: DIGEST-MD5 common mech free
slapd[1949]: conn=1015 op=2 UNBIND
slapd[1949]: conn=1015 fd=9 closed
Я добился некоторого прогресса. Теперь я могу получить информацию о пользователе из Active Directory, если она не найдена локально, но не могу затем повторно привязать ее как пользователя для завершения аутентификации.
Я получаю сообщение об ошибке «Не удалось повторить попытку прокси-операции»:
slapd[22555]: conn=1000 fd=8 ACCEPT from IP=127.0.0.1:35848 (IP=127.0.0.1:389)
slapd[22555]: conn=1001 fd=9 ACCEPT from IP=127.0.0.1:35850 (IP=127.0.0.1:389)
slapd[22555]: conn=1000 op=0 BIND dn="cn=xxxx,ou=local" method=128
slapd[22555]: conn=1000 op=0 BIND dn="cn=xxxx,ou=local" mech=SIMPLE ssf=0
slapd[22555]: conn=1000 op=0 RESULT tag=97 err=0 text=
slapd[22555]: conn=1000 op=1 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(uid=xxxxxx)"
slapd[22555]: conn=1002 fd=11 ACCEPT from IP=127.0.0.1:35852 (IP=127.0.0.1:389)
slapd[22555]: conn=1002 op=0 BIND dn="cn=xxxx,ou=local" method=128
slapd[22555]: conn=1002 op=0 BIND dn="cn=xxxx,ou=local" mech=SIMPLE ssf=0
slapd[22555]: conn=1002 op=0 RESULT tag=97 err=0 text=
slapd[22555]: conn=1003 fd=13 ACCEPT from IP=127.0.0.1:35854 (IP=127.0.0.1:389)
slapd[22555]: conn=1003 op=0 BIND dn="cn=xxxx,ou=local" method=128
slapd[22555]: conn=1003 op=0 BIND dn="cn=xxxx,ou=local" mech=SIMPLE ssf=0
slapd[22555]: conn=1003 op=0 RESULT tag=97 err=0 text=
slapd[22555]: conn=1002 op=1 SRCH base="ou=xxxx,dc=sxxxx,dc=nxx,dc=xx,dc=xxx" scope=2 deref=0 filter="(uid=xxxxxx)"
slapd[22555]: conn=1003 op=1 SRCH base="ou=local" scope=2 deref=0 filter="(uid=xxxxxx)"
slapd[22555]: conn=1003 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text=
slapd[22555]: conn=1000 op=1 meta_back_search[1] match="" err=32 (No such object) text="".
slapd[22555]: conn=1002 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
slapd[22555]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
slapd[22555]: conn=1001 op=0 BIND dn="cn=xxxxxx,ou=xxxx,dc=a,dc=example,dc=com" method=128
slapd[22555]: conn=1004 fd=16 ACCEPT from IP=127.0.0.1:35858 (IP=127.0.0.1:389)
slapd[22555]: conn=1004 op=0 BIND dn="cn=xxxxxx,ou=General,ou=xxxx,dc=sxxxx,dc=nxx,dc=xx,dc=xxx" method=128
slapd[22555]: conn=1004 op=0 ldap_back_retry: retrying URI="ldaps://active.directory" DN=""
slapd[22555]: conn=1004 op=0 RESULT tag=97 err=52 text=Proxy operation retry failed
slapd[22555]: conn=1004 op=1 UNBIND
slapd[22555]: conn=1001 op=0 RESULT tag=97 err=52 text=
slapd[22555]: conn=1004 fd=16 closed
Вот моя измененная мета-конфигурация:
database meta
suffix dc=example,dc=com
# The last rwm-map line maps all other attributes to nothing.
overlay rwm
rwm-map attribute uid sAMAccountname
rwm-map attribute *
#rwm-map objectclass posixGroup group
#rwm-map objectclass posixAccount person
#rwm-map objectclass memberUid member
##
uri "ldap://127.0.0.1/dc=a,dc=example,dc=com"
suffixmassage "dc=a,dc=example,dc=com" "ou=xxxx,dc=sxxxx,dc=nxx,dc=xx,dc=xxx"
rebind-as-user true
idassert-bind
bindmethod=simple
binddn="cn=XXXX,ou=local"
credentials=XXXX
mode=none
idassert-authzFrom "dn.regex:.*"
##
uri "ldap://127.0.0.1/dc=b,dc=example,dc=com"
suffixmassage "dc=b,dc=example,dc=com" "ou=local"
rebind-as-user true
idassert-bind
bindmethod=simple
binddn="cn=XXXX,ou=local"
credentials=XXXX
mode=none
idassert-authzFrom "dn.regex:.*"
##
database ldap
uri ldaps://active.directory
suffix ou=xxxx,dc=sxxxx,dc=nxx,dc=xx,dc=xxx
rebind-as-user true
idassert-bind
bindmethod=simple
binddn="cn=XXXX,ou=xxxx,ou=sxxxx,ou=axxxx,dc=sxxxx,dc=nxx,dc=xx,dc=xxx"
credentials=XXXX
tls_reqcert=allow
tls_cacert=/etc/letsencrypt/live/xxxx/fullchain.pem
tls_cert=/etc/letsencrypt/live/xxxx/cert.pem
tls_key=/etc/letsencrypt/live/xxxx/privkey.pem
mode=none
idassert-authzFrom "dn.regex:.*"
Я искал это решение около месяца и, наконец, наткнулся на ответ на странице руководства slapd, увидев пример конфигурации в потоке openldap, непосредственно связанный с моей проблемой.
Ключом к моему решению является раздел флагов idassert-bind для бэкэнда ldap. я добавил
flags=override
На странице руководства slapd:
Flags can be
override,[non-]prescriptive,proxy-authz-[non-]critical
When the override flag is used, identity assertion takes place even
when the database is authorizing for the identity of the client, i.e.
after binding with the provided identity, and thus authenticating it,
the proxy performs the identity assertion using the configured dentity
and authentication method.
Final working Backend LDAP configuration:
database meta
suffix dc=example,dc=com
##
uri "ldaps://127.0.0.1/dc=a,dc=example,dc=com"
suffixmassage "dc=a,dc=example,dc=com" "ou=local"
rebind-as-user yes
idassert-bind
bindmethod=simple
binddn="cn=admin,ou=local"
credentials=XXXXXXXX
starttls=yes
tls_reqcert=allow
tls_cacert=/etc/letsencrypt/live/my.site.com/fullchain.pem
tls_cert=/etc/letsencrypt/live/my.site.com/cert.pem
tls_key=/etc/letsencrypt/live/my.site.com/privkey.pem
mode=none
idassert-authzFrom "dn.regex:.*"
##
uri "ldaps://127.0.0.1/dc=b,dc=example,dc=com"
suffixmassage "dc=b,dc=example,dc=com" "ou=axxxx,dc=sxxxx,dc=nxx,dc=xx,dc=xxx"
rebind-as-user yes
idassert-bind
bindmethod=simple
binddn="cn=admin,ou=local"
credentials=XXXXXXXX
starttls=yes
tls_reqcert=allow
tls_cacert=/etc/letsencrypt/live/my.site.com/fullchain.pem
tls_cert=/etc/letsencrypt/live/my.site.com/cert.pem
tls_key=/etc/letsencrypt/live/my.site.com/privkey.pem mode=none
mode=none
idassert-authzFrom "dn.regex:.*"
##
database ldap
uri ldaps://ldaps.my.site.com/
suffix "OU=AXXXX,DC=sxxxx,DC=nxx,DC=xx,DC=xxx"
rebind-as-user yes
chase-referrals yes
readonly yes
idassert-bind
bindmethod=simple
binddn="CN=IXXXX,OU=IX,OU=SXXXX,OU=AXXXX,DC=sxxxx,DC=nxx,DC=xx,DC=xxx"
credentials=XXXXXXXX
flags=override
mode=none
idassert-authzFrom "dn.regex:.*"
# The last rwm-map line maps all other attributes to nothing.
overlay rwm
rwm-map attribute uid sAMAccountname
rwm-map attribute cn cn
rwm-map attribute sn sn
rwm-map attribute givenName givenName
rwm-map attribute employeeID employeeID
rwm-map attribute employeeNumber employeeNumber
rwm-map attribute uidNumber uidNumber
rwm-map attribute gidNumber gidNumber
rwm-map attribute mail mail
rwm-map attribute departmentNumber departmentNumber
rwm-map attribute department department
rwm-map attribute home extensionAttribute12
rwm-map attribute *