#6 Protocol error in proxied operations
Closed: Fixed None Opened 7 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.

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

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...

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)

Agreed! Changing patch...

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

Thanks for the review Noriko!

Have you tested this with both mozldap ldapsearch and openldap ldapsearch?

This fix has been successfully tested against openldap and moz ldap searches.

Added initial screened field value.

Metadata Update from @nhosoi:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.2.10.rc1

2 years ago

Login to comment on this ticket.

Metadata