#48367 LDAP_UNAVAILABLE_CRITICAL_EXTENSION not returned when proxyauth is requested but unavailable
Closed: wontfix None Opened 8 years ago by pspacek.

$ ldapsearch -w testtest -D 'uid=test,cn=users,cn=accounts,dc=dom-058-103,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com' -e \!authzid=dn:uid=admin,cn=users,cn=accounts,dc=dom-058-103,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com -b uid=admin,cn=users,cn=accounts,dc=dom-058-103,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com userPassword

does not fail with LDAP_UNAVAILABLE_CRITICAL_EXTENSION even though OID 2.16.840.1.113730.3.4.18 is not listed in cn=features,cn=config at all.

Access log looks like if authzid was used:

[01/Dec/2015:12:05:30 +0100] conn=9887 fd=67 slot=67 SSL connection from 2620:52:0:224e:21a:4aff:fe23:1348 to 2620:52:0:224e:21a:4aff:fe23:1348
[01/Dec/2015:12:05:30 +0100] conn=9887 TLS1.2 128-bit AES
[01/Dec/2015:12:05:30 +0100] conn=9887 op=0 BIND dn="uid=test,cn=users,cn=accounts,dc=dom-058-103,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" method=128 version=3
[01/Dec/2015:12:05:30 +0100] conn=9887 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=test,cn=users,cn=accounts,dc=dom-058-103,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com"
[01/Dec/2015:12:05:30 +0100] conn=9887 op=1 SRCH base="uid=admin,cn=users,cn=accounts,dc=dom-058-103,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com" scope=2 filter="(objectClass=*)" attrs="userPassword" authzid="uid=admin,cn=users,cn=accounts,dc=dom-058-103,dc=abc,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com"
[01/Dec/2015:12:05:30 +0100] conn=9887 op=1 RESULT err=0 tag=101 nentries=0 etime=0 notes=U
[01/Dec/2015:12:05:30 +0100] conn=9887 op=2 UNBIND
[01/Dec/2015:12:05:30 +0100] conn=9887 op=2 fd=67 closed - U1

I think this is a misunderstanding, ds does support this control:

{{{
ldapsearch -LLL -x -h localhost -p 389 -b "" -s base | grep 2.16.840.1.113730.3.4.18
supportedControl: 2.16.840.1.113730.3.4.18

}}}
but it improperly handles it for operations where the original bin dn is directory manager.
So, this is a bug in handling the control and should be fixed. This is handled in ticket #48366.

is it ok to close this one ?

I think that this is a separate issue. DS does not return an error if the user is not authorized to use the control but the control is marked as critical. In that case I would expect LDAP_UNAVAILABLE_CRITICAL_EXTENSION error but currently DS just continues.

This applies to non-DM cases, too.

yes and no.

you are right that there is no entry in cn=features,cn=config defining access to the control and adding such an entry has no effect.
But on the other hand, aci code does a fine grained handling who is allowed to use the proxy contols on which attributes or entries. This is done by defining acis with "proxy" rights. So in the same search some netries could be returned, some not - it is not an all or nothing mechanism.

From RFC4511:

{{{
If the server does not recognize the control type, determines that
it is not appropriate for the operation, or is otherwise unwilling
to perform the operation with the control, and if the criticality
field is TRUE, the server MUST NOT perform the operation, and for
operations that have a response message, it MUST return with the
resultCode set to unavailableCriticalExtension.
}}}
so, we do recognize the control, it is seen appropriate for the operation, the condition to send the unavailableCriticalExtension response would be:

{{{
is otherwise unwilling to perform the operation with the control
}}}
But we do perform the operation, only the result is determined by the aci - so I don't see that we MUST return the unavailable response

Okay, I can see your point. In that case it would be good to somehow log information that proxy control was not used for particular operation because current log seems misleading to me.

Looking at the implementation [0]

{{{
The criticality MUST be present and MUST be TRUE. This requirement
protects clients from submitting a request that is executed with an
unintended authorization identity.

Clients MUST include the criticality flag and MUST set it to TRUE.
Servers MUST reject any request containing a Proxy Authorization
Control without a criticality flag or with the flag set to FALSE with
a protocolError error. These requirements protect clients from
submitting a request that is executed with an unintended
authorization identity.
}}}

and

{{{
If the requested authorization identity is recognized by the server,
and the client is authorized to adopt the requested authorization
identity, the request will be executed as if submitted by the proxy
authorization identity; otherwise, the result code 123 is returned.
}}}

So I think the real issue here is that the result code is being set to LDAP_SUCCESS rather than 123 as per the RFC when the access is denied. This is defined as LDAP_X_PROXY_AUTHZ_FAILURE in openldap/ldap.h, and does not appear to be used in the 389-ds code.

[0] https://tools.ietf.org/html/rfc4370

Ah, good, I missed that one in the RFC. Feel free to rename this ticket :-)

To keep you updated, we have been discussing this issue, and will come back with a plan of action soon. Hope that helps.

We have decided that given the current structure of the proxy aci rules, and their interactions with the code that we cannot easily make ds compliant with the RFC given the current structure.

We will develop a new aci type (authz) that is able to be RFC conformant within the DS code base. There are a number of reasons for this.

First, proxy rules don't control who you can proxy to: They allow you to proxy to anyone, but only if the target of the operation is to a specific target. These rules are not very secure or good.

Second, because of this design, the aci code cannot evaluate the proxy aci in isolation from the search operation. As a result, the search needs to already by complete by the time we need to return the error. We also may only have a partial search denial with the proxy rule structure, so it would not be "easy" to determine the correct result to send.

Given this, we have decided it's better to create a new right type that:

  • Determines what objects a user / group / filter can proxy on the behalf of: Rather than limiting to the proxy to some scope X as any object.
  • Can be evaluated before a search operation (IE in isolation of the search operation)

This change has a huge number of benefits to ds, and would allow us to use authz rules as an rfc compliant proxy mechanism.

#48847

We can't fix this (discovered issue) easily, and this ticket has taken a tangent from the original issue.

This new ticket will track the addition of the new right type.

Metadata Update from @firstyear:
- Issue assigned to firstyear
- Issue set to the milestone: 1.3.5.5

7 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1698

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Invalid)

3 years ago

Login to comment on this ticket.

Metadata