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

прокси-авторизация openldap

У меня проблемы с обновлением с авторизацией через прокси. Я использую LDAP SDK UnboundID для подключения к OpenLDAP и отправляю ProxiedAuthorizationV2RequestControl для dn: uid=me,dc=People,dc=example,dc=com с обновлением. Я проверил и подтвердил, что у целевого пользователя есть разрешение на выполнение операции, но я получаю

недостаточные права доступа

когда я пытаюсь сделать это через прокси auth.

Я настроил 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=

Я прошел через это около года назад, использование прокси-авторизации сводит меня с ума. Так что, возможно, у меня нет окончательного ответа, но, возможно, я смогу помочь.

Прежде всего: увеличьте свой лог-уровень на 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#sasl

После решения нескольких проблем с конфигурацией с помощью Жюльена я обнаружил ошибку в UnboundID LDAP SDK v2.0.0, которая, по-видимому, вызывает отправку запросов на изменение без их контроля. я получил отличная поддержка на их форуме, они поставили для меня новую сборку в течение нескольких часов после того, как я опубликовал журналы, в которых была указана проблема, и похоже, что она будет исправлена в выпуске 2.1.0. Теперь мой код работает так, как задумано.