[Date Prev][Date Next]
Re: LDAP_OPERATIONS_ERROR instead of LDAP_INSUFFICIENT_ACCESS (ITS#1987)
At 06:41 AM 2002-07-26, Michael Ströder wrote:
>Kurt D. Zeilenga wrote:
>>>>2.1 includes operations error checks which previous versions
>>>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.
>I usually do a cvs up -RdP weekly or sometimes even daily. Is that recent enough? I checked now and REL_ENG_2 returns insufficientAccessRights with info "no write access to parent". That seems reasonable to me.
Different check. insufficientAccessRights is returned with
the access policy, as defined in RFC 2829, 3.1, doesn't allow
the access to the requested resource.
operationsError is returned regardless of the access control
policy (as defined in RFC 2829, 3.1) and the resource which
access was requested to.
>Again: Note that a BindRequest was sent before => the protocol operation sequence is not violated.
Yes. Note that our implementation doesn't generally
require bind before other operations. This is not
viewed as a protocol violation. But if configured
to require bind before other operations, operationsError
is use to indicate this to the client (per 2251).
>2.1 treats anon bind as you would never have received a BindRequest.
No. It's treating it as a different operations error, which
is checked/handled separately from the above case in our
>That seems like a bug to me.
No. operationsError can be returned by any operation to indicate
a sequencing error.
>>Now, it could be argued that strongAuthRequired would
>>be a more appropriate result code in this case.
> From draft-ietf-ldapbis-protocol-07:
> - strongAuthRequired: the server requires authentication be
> performed with a SASL mechanism.
You quote from the Bind response section... the general meaning
> strongAuthRequired (8)
> Except when returned in a Notice of Disconnect (see section
> 4.4.1), this indicates that the server requires the client to
> authentication using a strong(er) mechanism.
I note that the Bind section should be clarified... the intent
is simply that a strong(er) mechanism should be used. Not
necessarily SASL (not all SASL mechansism are stronger than
simple authentication, and there are other authentication
methods than simple and SASL). I'll have to make a note of this
>>>>>But OpenLDAP 2.1.x returns LDAP_OPERATIONS_ERROR with info field saying
>>>>>"modifications require authentication".
>Im my situation the client is already authenticated. Well, anonymous, but authenticated.
Your client is not authenticated in that it has not established
the identity of the user. It has completed a mechanism establishing
an anonymous authentication state. That is, establishing no
identity and establish an identity are semantically different.
I think the message is clear enough to indicate to the user
that it should establish its identity before attempting a
modification. But, if you like, I'll change the message to:
"modifications require establish of client's identity"
But I suspect that would confuse most users.
>>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).
>>>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.
>And I would classify this restriction as (reasonable) access control.
This, IMO, is problematic as it doesn't adequately distinguish
access control policy violation (which control access to information
held in the directory) from a security restriction upon the
>>>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
>Why? It's very user-friendly. The user can browse anonymously and, if required, bind with higher-privileged Bind-DN. Well, the user should login before but usually forgets it. That works for me all day for access control restrictions.
I think it would be better (security wise) for the client to
track its authentication/security layer state and not attempt
operations when inadequate authentication/security layers
are not present. That is, instead of sending the update
anonymously and trying to decipher why it failed, you could
immediately notify the user that it is not currently authenticated
and suggest that not only authenticate, but that it establish
That is, I think it would be better (and very user friendly)
for the client to be proactive, not reactive, about security.
>>>>>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
>"Generic" means that the application is unable to figure out which protocol sequence was violated.
>> And, IIRC, I've seen other servers return
>>codes other than insufficientAccess in this case.
That I don't recall which...
>> I won't be
>>surprised to find strongAuthRequired or unwillingToPerform here
>unwillingToPerform is sometimes used on old LDAPv2 servers or something shitty like ldap.bigfoot.com.
IIRC, I saw this at a DirConnect... it was from general-purpose
commercial LDAPv3 implementation(s).
>>>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?
>No, since it would mandate a SASLBindRequest.
I think you confuse the (flawed) Bind-specific meaning
with the general meaning of the result code.