You are viewing a plain text version of this content. The canonical link for it is here.
Posted to api@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2010/02/23 17:33:13 UTC
Handling M$ specification violations
Hi,
M$, as usual, is violating many LDAP RFCs. For instance, you can send a
simple BindRequest where the user name is *not* a DN.
I guess we will have to bend the API to accept such crapity...
wdyt ?
<curse>M$</curse>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
Re: Handling M$ specification violations
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 2/23/10 10:06 PM, Matthew Swift wrote:
> I think so - I realize that our OpenDS SDK needs to cope with this as
> well :-(
>
> It makes me wonder what else could be violated? Should we permit
> non-DNs for all operations?
IMO, no.
> E.g. modifying the entry "joe.bloggs@example.com"? It seems a bit
> inconsistent to be lax in only one part of the protocol but not
> others. ;-)
There is a difference with the Bind operation DN : for M$, it makes
sense to enforce their own rule, as they can't ask people to type a DN
to login (even if they could have used SASL instead of a Simple
BindRequest). But AFAIK, I don't think you need to 'fix' some other
request to accept something else than a DN.
>
> My preference is to encourage conformance where possible. What other
> known violations are there other than the bind DN?
You can rad this very interesting paper from Symas :
http://www.symas.com/documents/Adam-Eval1-0.pdf
One of the major violation, beside the use of a non-DN in a SimpleBind
operation is the fact that anonymous authent is not allowed on AD/ADAM
by default, but this should not be a problem from the API pov, and
another one is the retrieval of MV attributes that may need a special
treatment when here are more than 1500 values (and I guess we have to
deal with this problem...).
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
Re: Handling M$ specification violations
Posted by Matthew Swift <Ma...@Sun.COM>.
I think so - I realize that our OpenDS SDK needs to cope with this as
well :-(
It makes me wonder what else could be violated? Should we permit non-DNs
for all operations? E.g. modifying the entry "joe.bloggs@example.com"?
It seems a bit inconsistent to be lax in only one part of the protocol
but not others. ;-)
My preference is to encourage conformance where possible. What other
known violations are there other than the bind DN?
Matt
On 23/02/10 17:33, Emmanuel Lecharny wrote:
> Hi,
>
> M$, as usual, is violating many LDAP RFCs. For instance, you can send
> a simple BindRequest where the user name is *not* a DN.
>
> I guess we will have to bend the API to accept such crapity...
>
> wdyt ?
>
> <curse>M$</curse>
>
Re: Handling M$ specification violations
Posted by Matthew Swift <Ma...@Sun.COM>.
I think so - I realize that our OpenDS SDK needs to cope with this as
well :-(
It makes me wonder what else could be violated? Should we permit non-DNs
for all operations? E.g. modifying the entry "joe.bloggs@example.com"?
It seems a bit inconsistent to be lax in only one part of the protocol
but not others. ;-)
My preference is to encourage conformance where possible. What other
known violations are there other than the bind DN?
Matt
On 23/02/10 17:33, Emmanuel Lecharny wrote:
> Hi,
>
> M$, as usual, is violating many LDAP RFCs. For instance, you can send
> a simple BindRequest where the user name is *not* a DN.
>
> I guess we will have to bend the API to accept such crapity...
>
> wdyt ?
>
> <curse>M$</curse>
>