I've been working on making Samba4 pass it's testsuite with OpenLDAP as a backend.
One of my tests does what no LDAP client should do - it applies a case sensitive comparison of the returned DN, compared with what we expect and get from AD.
For example, we search for cn=ldaptestmachine and then ensure we get:
CN=ldaptestmachine,CN=Users,DC=samba,DC=example,DC=com
OpenLDAP returns
cn=ldaptestmachine,cn=users,dc=samba,dc=example,dc=com
which I'm sure is perfectly valid, but if I can write a bodgy script with case sensitive comparisons, so can an admin or sloppy app. Working in the windows space makes me like to eliminate differences where I can.
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).
Thanks,
Andrew Bartlett
Andrew Bartlett wrote:
I've been working on making Samba4 pass it's testsuite with OpenLDAP as a backend.
One of my tests does what no LDAP client should do - it applies a case sensitive comparison of the returned DN, compared with what we expect and get from AD.
For example, we search for cn=ldaptestmachine and then ensure we get:
CN=ldaptestmachine,CN=Users,DC=samba,DC=example,DC=com
OpenLDAP returns
cn=ldaptestmachine,cn=users,dc=samba,dc=example,dc=com
which I'm sure is perfectly valid, but if I can write a bodgy script with case sensitive comparisons, so can an admin or sloppy app. Working in the windows space makes me like to eliminate differences where I can.
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.
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).
If you can do this easily on your side, that would be best. We could also write an overlay for the slapd side, but it would be far more effort than it's worth.
Thanks,
Andrew Bartlett
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.
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'.
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...
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?
Andrew Bartlett
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.
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
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 ---------------------------------------
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 January 7, 2008 4:34:26 AM -0800 Howard Chu hyc@symas.com wrote:
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.
Should that be dropped into the contrib directory?
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
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
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, or should it be something done run-time, any time a DN needs to be prettified?
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 ---------------------------------------
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 ---------------------------------------
On Sat, 2008-01-12 at 11:09 +0100, Pierangelo Masarati wrote:
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.
I also use the same check to validate the schema, as AD has a concept of 'allowed child classes'. But yes, I think it's a very good idea.
Andrew Bartlett
openldap-technical@openldap.org
-
Andrew Bartlett -
Howard Chu -
Pierangelo Masarati -
Quanah Gibson-Mount