search

389ds / 389-ds-base

The enterprise-class Open Source LDAP server for Linux
https://www.port389.org/
Other
210 stars 89 forks source link

LDAP_UNAVAILABLE_CRITICAL_EXTENSION not returned when proxyauth is requested but unavailable #1698

Closed 389-ds-bot closed 4 years ago

389-ds-bot commented 4 years ago

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/48367

$ 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
389-ds-bot commented 4 years ago

Comment from lkrispen (@elkris) at 2015-12-04 20:46:55

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 ?

389-ds-bot commented 4 years ago

Comment from pspacek at 2015-12-04 21:12:40

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.

389-ds-bot commented 4 years ago

Comment from lkrispen (@elkris) at 2015-12-04 21:45:01

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.

389-ds-bot commented 4 years ago

Comment from lkrispen (@elkris) at 2015-12-04 22:22:50

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

389-ds-bot commented 4 years ago

Comment from pspacek at 2015-12-08 14:10:03

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.

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2016-01-13 10:46:44

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

389-ds-bot commented 4 years ago

Comment from pspacek at 2016-01-13 15:28:35

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

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2016-02-08 10:55:09

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

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2016-02-15 04:19:20

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:

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

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2016-05-20 06:40:34

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.

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2017-02-11 23:06:35

Metadata Update from @Firstyear: