Issue #6: Protocol error in proxied operations - 389-ds-base

389-ds-base

#6 Protocol error in proxied operations

Closed: wontfix None Opened 12 years ago by mkosek.

https://bugzilla.redhat.com/show_bug.cgi?id=768934

Description of problem:

I am trying to test the proxied operations in 389 DS. For now, I have
written a small script using UnboundID LDAP SDK [1]:

ModifyRequest modifyRequest = new
ModifyRequest("uid=XXXXXXXX,ou=People,o=XXXXXXXX,dc=XXXXXXXX,dc=XXXXXXXX",
new Modification(ModificationType.REPLACE, "address", "Nueva
direcci?n"));
modifyRequest.addControl(new ProxiedAuthorizationV2RequestControl(
"dn:" + proxiedUserEntry.getDN()) );

try
{
   LDAPResult modifyResult =
ldapConnectable.getConnection(session).modify(modifyRequest);
   // If we got here, then the modify was successful.
}
catch (LDAPException le)
{
   System.out.println(le.getDiagnosticMessage() + " (" +
le.getResultCode() + ")");
}

Although I have not yet assigned any ACIS as described in [2], I
supposed to get a denied response, not a protocol error as I get:

unable to parse proxied authorization control (2 (protocol error))

This error is returned by the LDAP server, although it is not
reported in the error LOG.

[1] http://www.unboundid.com/products/ldapsdk/docs/javadoc/index.html
[2] http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html/Adminis
tration_Guide/Managing_Access_Control-Access_Control_Usage_Examples.html#Access
_Control_Usage_Examples-Proxied_Authorization_ACI_Example


Version-Release number of selected component (if applicable): Tested in 1.2.5


How reproducible / Steps to Reproduce:

Running the code below.


Actual results:

unable to parse proxied authorization control (2 (protocol error))


Expected results:

An access denied in this case, as not applied any proxying configuration, or
the actual proxied search result if configured.

mreynolds commented 12 years ago

Reproduced issue:

ldapsearch -x -D "uid=scarter,ou=people,dc=example,dc=com" -w sprain -b "dc=example,dc=com"
-e !authzid="dn:uid=aworrell,ou=People,dc=example,dc=com" -LLL cn=*
Protocol error (2)
Additional information: unable to parse proxied authorization control

Continuing investigation...

Mark

mreynolds commented 12 years ago

The problem was that ber_scanf was rejected the authdn value because it was expecting it to be encoded in a octet string. This encoding is no longer required. So the fix was to check if the value started with a octet string. If it didn't then there was no need to pass it through ber_scanf, and we can use the value as is.

Sending fix out for review...

nhosoi commented 12 years ago

Your fix looks good. We may want to use the macro instead of the hex digit here...?

/usr/include/lber.h:#define LBER_OCTETSTRING ((ber_tag_t) 0x04UL)

mreynolds commented 12 years ago

Agreed! Changing patch...

nhosoi commented 12 years ago

Cool! Thanks!!

mreynolds commented 12 years ago

final revision
0001-Ticket-6-protocol-error-from-proxied-auth-operation.patch

mreynolds commented 12 years ago

I could not use LBER_OCTETSTRING because it has the wrong cast. So I created a new macro in slap.h, CHAR_OCTETSTRING, because I think it's possible we might start seeing this issue more often and I wanted the macro to be available to slapd.

[mareynol@localhost slapd]$ git merge ticket6
Updating b4cd137..5232b20
Fast-forward
ldap/servers/slapd/proxyauth.c | 30 +++++++++++++++++-------------
ldap/servers/slapd/slap.h | 2 ++
2 files changed, 19 insertions(+), 13 deletions(-)
[mareynol@localhost slapd]$ git push origin master
Counting objects: 13, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 1.09 KiB, done.
Total 7 (delta 5), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
b4cd137..5232b20 master -> master