Re: LDAP_OPERATIONS_ERROR instead of LDAP_INSUFFICIENT_ACCESS (ITS#1987)

[Kurt@OpenLDAP.org]

At 03:22 AM 2002-07-26, Michael Ströder wrote:
>Kurt D. Zeilenga wrote:
>>>What's the rationale behind changing the error code returned if
>>>a write access
>>>to the directory with anonymous bind fails?
>>
>> 2.1 includes operations error checks which previous versions
>> didn't.
>
>Can you elaborate on this? Which checks.

Actually, I was incorrect.  2.0 returned operationsError in this
case as well.  Not sure when it was back ported, I presume after
the version you were using.

>>>In OpenLDAP 2.0.x and any other LDAP server I know of LDAP_INSUFFICIENT_ACCESS
>>>is returned if the add or modify operation fails.
>>insufficientAccess indicates that the operation failed
>>due to violation of the access control policy.
>
>Which makes sense in that case either. Doesn't it?

No.  Because the operation is not being disallowed as
a matter of access policy.  Protocol restrictions are
not viewed as access policy (even if configurable).

Now, it could be argued that strongAuthRequired would
be a more appropriate result code in this case.

>>>But OpenLDAP 2.1.x returns LDAP_OPERATIONS_ERROR with info field saying
>>>"modifications require authentication".
>>operationsError indicates that the client has attempted an
>>operation before some other required operation and/or without
>>other pending operations to complete.  In this case, it
>>indicates that the client has failed to authenticate to the
>>directory (using the bind operation) prior to attempting
>>to modify the directory (using the modify operation).
>
>Well, this is a matter of interpretation.

Unfornately, a number of vendors have misinterpreted
operations error to be some sort of catch all (mainly
because 2251 has a bug in its description of this code
with regards to the bind operation).

draft-ietf-ldapbis-protocol describes operationsError as:
>        operationsError (1) 
>           Indicates that the operation is not properly sequenced with
>           relation to other operations (of same or different type).    

This is consistent, I believe, with the current X.511 definition
of the result code.  This is the sense of which OpenLDAP returns
this code.

>The new way in OpenLDAP 2.1.x does not allow write operations for anonymous bind at all?

The restriction can be disabled (like most of the restrictions),
but, yes, 2.1 is designed to disallow all anonymous updates
regardless of access control policy.

>Note that my client does the anonymous bind explicitly before any other operation (except StartTLS extended operation) for probing LDAPv3 vs. LDAPv2.

I think it odd that you attempt an update operation while
anonymous.

>>>This is bad since LDAP_OPERATIONS_ERROR can be anything
>>No!  The operationsError resultCode indicates an operations error,
>>which has specific meaning in LDAP
>
>Fact is that it's a common practice with LDAP servers to return LDAP_INSUFFICIENT_ACCESS and that it's pretty convenient for the user getting a login form instead of generic operations error message.

Not sure what you mean by "generic" here.  OperationsError is
actually quite specific.  It reports a problem due to how this
operation relates to other operations. (Hence the "s" in
operationsError).  And, IIRC, I've seen other servers return
codes other than insufficientAccess in this case.  I won't be
surprised to find strongAuthRequired or unwillingToPerform here
as well.

>The new way in OpenLDAP 2.1.x makes the life of LDAP application programmers even more miserable than it already is.

Would changing this to strongAuthRequired help?

>Or do you suggest that the client application should look at the info field?

No.  That field is for informational purposes only.