Howard Chu wrote:

It's not just perfectly valid, it is exactly correct. RFC4519 defines the attribute name to be 'cn' and we always return the canonical name for a given attribute. As always with Microsoft, AD is a broken abomination.

Of course, the point remains that attribute names are case-insensitive, and any user doing a case-sensitive compare on the attribute names is begging for disappointment.

I know we've had this conversation before, but I think it bears repeating - you don't always need to be bug-for-bug compatible with Microsoft. As long as low-level system functions that people can't easily get at to fix all work, you're close enough. It's also important to stress - it's better to educate your users and teach them best practices, than to keep catering to their ignorance. The only way things improve is when you emphasize doing things right and teaching others to also be able to do things right. Keep aiming for the lowest common denominator, and you get Microsoft, Hollywood, and the majority of US mass media.

Right now Microsoft AD is the market leader for directory services in identity management, and OpenLDAP is #2. (See here http://connexitor.com/blog/pivot/entry.php?id=190 for some pointers to the story.) If the Samba and OpenLDAP teams continue to do their job right, we can easily push Microsoft into the back seat. Microsoft has already demonstrated their (in)ability to produce any quality software (see Vista, see the benchmarks of OpenLDAP vs AD); unless they fire the majority of their developers and start over from scratch they'll never be able to close that gap.

People keep piping up "performance isn't the only thing that matters" - of course it's not. Correct operation is #1. By any measure, OpenLDAP is the *most correct* directory server implementation in existence, *and* it can easily be extended to include any features necessary. And when it can outperform other "competitors" (I use the term very loosely) by margins of over 5 to 1, the reasons for using anything else really tend to disappear. That means any enterprise using OpenLDAP has at least a 5:1 cost advantage over any competitor who's not using it, in terms of hardware/maintenance cost, data center provisioning costs, system management cost, etc... Any CIO who isn't leveraging all of these advantages for their own enterprise is wasting money. Any CIO that *is* leveraging all of these advantages will have a distinct competitive advantage over all of those other enterprises, because more of their IT budget will be freed up to provide more useful services for the company.

If you're a shareholder or Board member of a company that *isn't* already using OpenLDAP, you need to ask your CIOs "Why Not? How Soon Will You Switch?" and if there's no good answer to those questions, those CIOs need to be fired. It *is* as clear cut as that. Other products may win on slick marketing points, but in the end, the bottom line is still the bottom line, and no enterprise can ignore it. Indeed, they have a duty to their shareholders *not* to ignore it.

So weigh that into your bug-for-bug-compatibility considerations - over time, Samba+OpenLDAP will be the #1 directory deployed in Windows environments, just as it already is in Unix/Linux environments. As long as neither one of us badly screws up the code bases it is inevitable. So some places where you bend over backwards to accommodate Microsoft's flagrant disregard of open standards won't be so important down the road, because we are the de jure standard and will be the de facto standard.

Andrew Bartlett wrote:

On Sun, 2008-01-06 at 17:35 -0800, Howard Chu wrote:

...

Howard Chu wrote:

...

It's not just perfectly valid, it is exactly correct. RFC4519 defines the attribute name to be 'cn' and we always return the canonical name for a given attribute. As always with Microsoft, AD is a broken abomination.

Of course, the point remains that attribute names are case-insensitive, and any user doing a case-sensitive compare on the attribute names is begging for disappointment.

I know we've had this conversation before, but I think it bears repeating - you don't always need to be bug-for-bug compatible with Microsoft.

Perhaps it's my history with this area, or working in for appliance vendors in the past, but I've never quite had the luxuary of being able to say 'our users will understand, we are doing it right'.

Your users are probably the Most Likely to understand, of any user base. Anyone installing Samba is already strongly motivated to get away from Microsoft, I don't think anyone could be more understanding.

Of course things will be different, and the network interfaces won't quite match up, but the lesson the team has had so often is until your tests prove you are byte-for-byte idential, something will break...

Sure, that's understandable, especially for a closed protocol whose only specification is its implementation. (Does anyone believe that the docs Microsoft has licensed actually describe the code they've delivered?)

...

So weigh that into your bug-for-bug-compatibility considerations - over time, Samba+OpenLDAP will be the #1 directory deployed in Windows environments, just as it already is in Unix/Linux environments. As long as neither one of us badly screws up the code bases it is inevitable. So some places where you bend over backwards to accommodate Microsoft's flagrant disregard of open standards won't be so important down the road, because we are the de jure standard and will be the de facto standard.

In the meantime, I have to hope we can produce something that can get us into the position. How do we slip into an IT department that already has it's scripts, processes and stubbornly, poorly written software, without breaking the lot?

80/20 rule... 20% will break, regardless of your best efforts. Get over it, move on. If you aim for 100% compatibility you're going to have to insert delay loops everywhere, and you know what response that suggestion is going to get. ;)

That all said - I understand your perspective; we won't actively try to make your job harder, and we will try to help make it easier where we can.

Pierangelo Masarati wrote:

Andrew Bartlett wrote:

...

Can the case of the attribute names (CN and DC) in that DN be made to be UPPER case easily? (Alternately I'll write a filter module on the Samba4 side to do that).

Aside from Howard's comments, which I fully agree with, see http://www.sys-net.it/~ando/Download/adinsanity.c

Nice work. Much more direct approach than I had in mind.

On Mon, 2008-01-07 at 11:37 +0100, Pierangelo Masarati wrote:

Andrew Bartlett wrote:

...

Can the case of the attribute names (CN and DC) in that DN be made to be UPPER case easily? (Alternately I'll write a filter module on the Samba4 side to do that).

Aside from Howard's comments, which I fully agree with, see http://www.sys-net.it/~ando/Download/adinsanity.c

Attached is what I ended up with, for OpenLDAP.

How easy would it be for your patch to handle all attribute names in a DN, rather than a list?

Andrew Bartlett

Pierangelo Masarati wrote:

Andrew Bartlett wrote:

...

Attached is what I ended up with, for OpenLDAP.

How easy would it be for your patch to handle all attribute names in a DN, rather than a list?

My example changes the case of the listed attributeTypes at startup; would what you suggest be the same? Namely, you configure the module with a DN and all it needs is parse the DN and uppercase the naming attributes in that DN,

Please forget about the above

or should it be something done run-time, any time a DN needs to be prettified?

This should do the trick: http://www.sys-net.it/~ando/Download/nsdn.c.

With respect to making sure the parent's DN and the parent portion of an entry's DN exactly match, I think we need to intercept add operations to enforce that. Or, in general, this change could be beneficial to slapd: since we're checking for the existence of the parent anyway, we could rebuild the entry's DN using the normal/pretty RDN and the parent's DN.

p.

Ing. Pierangelo Masarati OpenLDAP Core Team

SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------