autorização em proxy openldap

Question

Estou tendo problemas para fazer atualizações com autorização por proxy. Estou usando o LDAP SDK do UnboundID para conectar-me ao OpenLDAP e enviar um ProxiedAuthorizationV2RequestControl para dn: uid=me,dc=People,dc=example,dc=com com a atualização. Eu testei e verifiquei que o usuário de destino tem permissão para executar a operação, mas recebo

insufficient access rights

quando tento fazer isso por meio de autenticação de proxy

Eu configurei olcAuthzPolicy=both em cn=config e authzTo={0}ldap:///dc=people,dc=example,dc=com??subordinate?(objectClass=inetOrgPerson) no usuário original. O authzTo parece estar funcionando; quando eu mudo eu recebo

not authorized to assume identity

quando tento a atualização (também para pesquisas).

Eu tenho esse ldapwhoami -U portal -Y DIGEST-MD5 -X u:mace -H ldap://yorktown -Z funcionando agora sem o saslauthd. Eu só precisava armazenar a senha do usuário proxy (portal) como texto simples. Mas ainda estou recebendo 'direitos de acesso insuficientes' quando tento atualizar qualquer coisa.

Utilizador proxy

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)

Usuário efetivo:

dn: employeeNumber=1400,dc=People,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: sambaSamAccount
objectClass: shadowAccount
uid: mace
...

Este é o log da tentativa de atualização, tentando adicionar employeeNumber=1385 como member de cn=Data Management . Parece estar olhando através dos grupos aninhados corretamente, mas parece que deveria indicar uma correspondência uma vez que chega a employeeNumber = 1400 em 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=

    

Answer 1

Eu passei por isso há cerca de um ano, usando autorização de proxy para me deixar louco. Então eu posso não ter a resposta definitiva, mas talvez eu possa ajudar.

Primeiro de tudo: aumentar seu nível de log no slapd! É verboso, mas ajuda. Segundo: use ldapwhoami para testar a autorização de proxy. Você pode especificar um usuário de destino com a opção -X e seu usuário de proxy em -U.

# ldapwhoami -U proxyuser -Y DIGEST-MD5 -X u:targetuser -H ldap://localhost

Você deve ter dois parâmetros ativados em sua configuração. O olcAuthzPolicy (que você tem) e o olcAuthzRegexp (usado para construir a sequência de autenticação SASL). Aqui está o que eu tenho na minha configuração:

olcAuthzRegexp: "^uid=([^,]+).*,cn=[^,]*,cn=auth$"
                "ldap:///dc=example,dc=net??sub?(uid=$1)"
olcAuthzPolicy: to

E, finalmente, como você afirmou, seu proxyuser deve ter um atributo authzTo . Aqui está a definição de um dos meus usuários proxy:

dn: cn=proxyuser,dc=example,dc=net
uid: proxyuser
mail: [email protected]
sn: proxyuser
cn: proxyuser
objectClass: inetOrgPerson
objectClass: top
structuralObjectClass: inetOrgPerson
authzTo: {0}ldap:///dc=example,dc=net??sub?(objectClass=inetOrgPerson)
userPassword:: iodqwhdowihw0123hef92e=

Agora, isso deve ser suficiente para que a autorização de proxy funcione (mais uma vez, teste-a com ldapwhoami). Eu escrevi um capítulo sobre isso no meu wiki (SASL e autorização de proxy), já que eu precisava conectar do cyrus-imapd e do postfix ao openldap. Para mais informações, dê uma olhada: link

    

Answer 2

Depois de resolver vários problemas de configuração com a ajuda de Julien, descobri um bug no UnboundID LDAP SDK v2.0.0 que aparentemente faz com que solicitações de modificação sejam enviadas sem seus controles. Eu tenho excelente suporte em seu fórum , eles colocaram uma nova compilação para mim dentro de algumas horas de meus registros de postagem identificando o problema, e parece que será corrigido na versão 2.1.0. Agora meu código está funcionando como pretendido.