Авторизация через openldap
У меня возникли проблемы при обновлении с прокси авторизацией. Я использую LDAP SDK UnboundID для подключения к OpenLDAP и отправляю ProxiedAuthorizationV2RequestControl для dn: uid=me,dc=People,dc=example,dc=com с обновлением. Я проверил и подтвердил, что целевой пользователь имеет разрешение на выполнение операции, но я получаю
недостаточные права доступа
когда я пытаюсь сделать это через прокси-аутентификации.
Я настроил olcAuthzPolicy=both в cn=config а также authzTo={0}ldap:///dc=people,dc=example,dc=com??subordinate?(objectClass=inetOrgPerson) на первоначального пользователя. AuthzTo, кажется, работает; когда я изменяю это, я получаю
не уполномочен принимать личность
когда я пытаюсь обновить (также для поиска).
У меня есть это ldapwhoami -U portal -Y DIGEST-MD5 -X u:mace -H ldap://yorktown -Z работает сейчас без saslauthd. Мне просто нужно было сохранить пароль прокси-пользователя (портала) в виде простого текста. Но я все еще получаю "недостаточные права доступа", когда пытаюсь что-либо обновить.
Пользователь прокси
dn: uid=portal,ou=Special Accounts,dc=example,dc=com
objectClass: inetOrgPerson
cn: portal
sn: portal
uid: portal
userPassword: test
authzTo: {0}ldap:///dc=People,dc=example,dc=com??sub?(objectClass=inetOrgPerson)
Эффективный пользователь:
dn: employeeNumber=1400,dc=People,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: sambaSamAccount
objectClass: shadowAccount
uid: mace
...
Вот журнал с попытки обновления, пытаюсь добавить employeeNumber=1385 как member из cn=Data Management, Кажется, он правильно просматривает вложенные группы, но, похоже, он должен указывать на совпадение, как только он доходит до employeeNumber=1400 в cn=administrators,
op tag 0x66, time 1299022001
conn=31595 op=2 do_modify
conn=31595 op=2 do_modify: dn (cn=Data Management,dc=Roles,dc=example,dc=com)
>>> dnPrettyNormal: <cn=Data Management,dc=Roles,dc=example,dc=com>
<<< dnPrettyNormal: <cn=Data Management,dc=Roles,dc=example,dc=com>, <cn=data management,dc=roles,dc=example,dc=com>
conn=31595 op=2 modifications:
replace: member
multiple values
conn=31595 op=2 MOD dn="cn=Data Management,dc=Roles,dc=example,dc=com"
conn=31595 op=2 MOD attr=member
>>> dnPretty: <employeeNumber=1020,dc=People,dc=example,dc=com>
<<< dnPretty: <employeeNumber=1020,dc=People,dc=example,dc=com>
>>> dnPretty: <employeeNumber=1385,dc=People,dc=example,dc=com>
<<< dnPretty: <employeeNumber=1385,dc=People,dc=example,dc=com>
>>> dnNormalize: <employeeNumber=1020,dc=People,dc=example,dc=com>
<<< dnNormalize: <employeeNumber=1020,dc=people,dc=example,dc=com>
>>> dnNormalize: <employeeNumber=1385,dc=People,dc=example,dc=com>
<<< dnNormalize: <employeeNumber=1385,dc=people,dc=example,dc=com>
dnMatch -1 "employeeNumber=1020,dc=people,dc=example,dc=com" "employeeNumber=1385,dc=people,dc=example,dc=com"
bdb_dn2entry("cn=data management,dc=roles,dc=example,dc=com")
==> unique_modify <cn=Data Management,dc=Roles,dc=example,dc=com>
bdb_modify: cn=Data Management,dc=Roles,dc=example,dc=com
bdb_dn2entry("cn=data management,dc=roles,dc=example,dc=com")
bdb_modify_internal: 0x00000043: cn=Data Management,dc=Roles,dc=example,dc=com
>>> dnNormalize: <cn=Administrators,ou=LDAP,dc=Applications,dc=example,dc=com>
<<< dnNormalize: <cn=administrators,ou=ldap,dc=applications,dc=example,dc=com>
=> bdb_entry_get: ndn: "cn=administrators,ou=ldap,dc=applications,dc=example,dc=com"
=> bdb_entry_get: oc: "(null)", at: "member"
bdb_dn2entry("cn=administrators,ou=ldap,dc=applications,dc=example,dc=com")
bdb_entry_get: rc=0
>>> dnNormalize: <cn=system administrators,dc=roles,dc=example,dc=com>
<<< dnNormalize: <cn=system administrators,dc=roles,dc=example,dc=com>
=> bdb_entry_get: ndn: "cn=system administrators,dc=roles,dc=example,dc=com"
=> bdb_entry_get: oc: "(null)", at: "member"
bdb_dn2entry("cn=system administrators,dc=roles,dc=example,dc=com")
bdb_entry_get: rc=0
>>> dnNormalize: <employeeNumber=1306,dc=people,dc=example,dc=com>
<<< dnNormalize: <employeeNumber=1306,dc=people,dc=example,dc=com>
=> bdb_entry_get: ndn: "employeeNumber=1306,dc=people,dc=example,dc=com"
=> bdb_entry_get: oc: "(null)", at: "member"
bdb_dn2entry("employeeNumber=1306,dc=people,dc=example,dc=com")
bdb_entry_get: rc=16
>>> dnNormalize: <employeeNumber=1329,dc=people,dc=example,dc=com>
<<< dnNormalize: <employeeNumber=1329,dc=people,dc=example,dc=com>
=> bdb_entry_get: ndn: "employeeNumber=1329,dc=people,dc=example,dc=com"
=> bdb_entry_get: oc: "(null)", at: "member"
bdb_dn2entry("employeeNumber=1329,dc=people,dc=example,dc=com")
bdb_entry_get: rc=16
>>> dnNormalize: <employeeNumber=1401,dc=people,dc=example,dc=com>
<<< dnNormalize: <employeeNumber=1401,dc=people,dc=example,dc=com>
=> bdb_entry_get: ndn: "employeeNumber=1401,dc=people,dc=example,dc=com"
=> bdb_entry_get: oc: "(null)", at: "member"
bdb_dn2entry("employeeNumber=1401,dc=people,dc=example,dc=com")
bdb_entry_get: rc=16
>>> dnNormalize: <employeeNumber=1400,dc=people,dc=example,dc=com>
<<< dnNormalize: <employeeNumber=1400,dc=people,dc=example,dc=com>
=> bdb_entry_get: ndn: "employeeNumber=1400,dc=people,dc=example,dc=com"
=> bdb_entry_get: oc: "(null)", at: "member"
bdb_dn2entry("employeeNumber=1400,dc=people,dc=example,dc=com")
bdb_entry_get: rc=16
bdb_modify: modify failed (50)
send_ldap_result: conn=31595 op=2 p=3
send_ldap_result: err=50 matched="" text=""
send_ldap_response: msgid=3 tag=103 err=50
conn=31595 op=2 RESULT tag=103 err=50 text=
2 ответа
Я прошел через это около года назад, использование прокси-авторизации сводило меня с ума. Так что у меня может не быть окончательного ответа, но, возможно, я могу помочь.
Прежде всего: увеличьте ваш лог-уровень на slapd! Это многословно, но это помогает. Второе: используйте ldapwhoami для проверки авторизации прокси. Вы можете указать целевого пользователя с опцией -X, а вашего прокси-пользователя в -U.
# ldapwhoami -U proxyuser -Y DIGEST-MD5 -X u:targetuser -H ldap://localhost
В вашей конфигурации должны быть включены два параметра. OlcAuthzPolicy (что у вас есть) и olcAuthzRegexp (используется для построения строки аутентификации SASL). Вот что у меня в конфигурации:
olcAuthzRegexp: "^uid=([^,]+).*,cn=[^,]*,cn=auth$"
"ldap:///dc=example,dc=net??sub?(uid=$1)"
olcAuthzPolicy: to
И, наконец, как вы заявили, ваш прокси-пользователь должен иметь атрибут authzTo. Вот определение одного из моих прокси-пользователей:
dn: cn=proxyuser,dc=example,dc=net
uid: proxyuser
mail: proxyuser@example.net
sn: proxyuser
cn: proxyuser
objectClass: inetOrgPerson
objectClass: top
structuralObjectClass: inetOrgPerson
authzTo: {0}ldap:///dc=example,dc=net??sub?(objectClass=inetOrgPerson)
userPassword:: iodqwhdowihw0123hef92e=
Теперь этого должно быть достаточно для работы авторизации через прокси (еще раз, протестируйте ее с помощью ldapwhoami). Я написал главу об этом в моей вики (SASL и авторизация через прокси), так как мне нужно было подключаться из cyrus-imapd и postfix к openldap. Для получения дополнительной информации, посмотрите на это: http://wiki.linuxwall.info/doku.php/en:ressources:dossiers:openldap:openldap_debian
После решения нескольких проблем конфигурации с помощью Джулиена я обнаружил ошибку в UnboundID LDAP SDK v2.0.0, которая, по-видимому, приводит к тому, что запросы на изменение отправляются без их элементов управления. Я получил отличную поддержку на их форуме, они создали новую сборку для меня в течение нескольких часов после того, как я опубликовал журналы, в которых была обнаружена проблема, и похоже, что она будет исправлена в выпуске 2.1.0. Теперь мой код работает как задумано.