Good evening,
We are currently in the process of upgrading our OpenLDAP installation and we have hit a behaviour we can’t explain by perusing the documentation.
When using slapo-dynlist to set memberOf attributes the dn of the group the object is a member of gets lowercased. So for example the object that is a member of a group has:
=== memberOf: ou=kiosk,ou=ags,ou=groups,dc=fsinfo,dc=cs,dc=tu-dortmund,dc=de ===
Although the group has a dn of:
=== dn: ou=Kiosk,ou=AGs,ou=groups,dc=fsinfo,dc=cs,dc=tu-dortmund,dc=de ===
Is this expected behaviour? Is there a setting we overlooked? Is this is a bug in the version shipped with Ubuntu (2.5.6+dfsg-1~exp1ubuntu1.1)?
Thank you,
Felix
--On Sunday, June 5, 2022 10:21 PM +0200 Felix Schäfer felix.schaefer@tu-dortmund.de wrote:
Good evening,
We are currently in the process of upgrading our OpenLDAP installation and we have hit a behaviour we can't explain by perusing the documentation.
When using slapo-dynlist to set memberOf attributes the dn of the group the object is a member of gets lowercased. So for example the object that is a member of a group has:
=== memberOf: ou=kiosk,ou=ags,ou=groups,dc=fsinfo,dc=cs,dc=tu-dortmund,dc=de ===
Although the group has a dn of:
=== dn: ou=Kiosk,ou=AGs,ou=groups,dc=fsinfo,dc=cs,dc=tu-dortmund,dc=de ===
Is this expected behaviour? Is there a setting we overlooked? Is this is a bug in the version shipped with Ubuntu (2.5.6+dfsg-1~exp1ubuntu1.1)?
ou is a case insensitive attribute, there is no issue here unless poorly written applications are expecting case sensitivity to be preserved.
--Quanah
On 6/5/22 22:00, Quanah Gibson-Mount wrote:
--On Sunday, June 5, 2022 10:21 PM +0200 Felix Schäfer felix.schaefer@tu-dortmund.de wrote:
When using slapo-dynlist to set memberOf attributes the dn of the group the object is a member of gets lowercased. So for example the object that is a member of a group has:
=== memberOf: ou=kiosk,ou=ags,ou=groups,dc=fsinfo,dc=cs,dc=tu-dortmund,dc=de ===
Although the group has a dn of:
=== dn: ou=Kiosk,ou=AGs,ou=groups,dc=fsinfo,dc=cs,dc=tu-dortmund,dc=de ===
Is this expected behaviour? Is there a setting we overlooked? Is this is a bug in the version shipped with Ubuntu (2.5.6+dfsg-1~exp1ubuntu1.1)?
ou is a case insensitive attribute, there is no issue here unless poorly written applications are expecting case sensitivity to be preserved.
Quanah, I understand why you're arguing like this.
But, like it or not, POSIX names are case-sensitive. So with posixGroup entries you have to preserve the case for completely consistent data.
Ciao, Michael.
Good evening,
Am 05.06.2022 um 22:00 schrieb Quanah Gibson-Mount quanah@fast-mail.org:
ou is a case insensitive attribute, there is no issue here unless poorly written applications are expecting case sensitivity to be preserved.
Ok, so what you are saying is dynlist can not be used as a drop-in replacement for memberof, correct? Fair, but maybe don’t be surprised if people get discouraged trying to use or using OpenLDAP.
Let’s go with another part of the argument. Are there other case sensitive attributes that could be part of the dn and cause a mismatch because of the casing? Would the casing be discarded in the memberOf in that case?
Anyway, we haven’t migrated yet because of such minutiae. We are not aware of one of the apps using the LDAP being case-sensitive in the memberOf (NextCloud, Zammad and Gitlab don’t seem to be?) attribute, but we’d rather not find out the hard way.
If the answer is „this is intended“, we can live with it and consider dynlist to not be a drop-in replacement for memberof and just continue using the later.
Thanks,
Felix
Hi,
Am 05.06.2022 um 22:36 schrieb Michael Ströder michael@stroeder.com:
But, like it or not, POSIX names are case-sensitive. So with posixGroup entries you have to preserve the case for completely consistent data.
It’s not just posix. If some client were to just consider the memberOf as an opaque string and use this as a key for the group membership on the client side, it would break.
Again, this is a not problem we currently have, but one we are trying to avoid. Most apps we host and use against the LDAP server are OSS apps that probably don’t have LDAP specialists keen to the intricates of the spec, so I wouldn’t expect for example case insensitivity to be on the mind of every developer of those apps.
Best,
Felix
--On Sunday, June 5, 2022 11:36 PM +0200 Michael Ströder michael@stroeder.com wrote:
ou is a case insensitive attribute, there is no issue here unless poorly written applications are expecting case sensitivity to be preserved.
Quanah, I understand why you're arguing like this.
But, like it or not, POSIX names are case-sensitive. So with posixGroup entries you have to preserve the case for completely consistent data.
If you can show that an attribute that is defined as case sensitive is not preserved when using dynlist for memberof instantiation, then that would be a bug. Outside of that, any client that mandates case sensitive matching on items that are not case sensitive is broken by definition.
--Quanah
On 6/5/22 23:06, Quanah Gibson-Mount wrote:
--On Sunday, June 5, 2022 11:36 PM +0200 Michael Ströder michael@stroeder.com wrote:
ou is a case insensitive attribute, there is no issue here unless poorly written applications are expecting case sensitivity to be preserved.
Quanah, I understand why you're arguing like this.
But, like it or not, POSIX names are case-sensitive. So with posixGroup entries you have to preserve the case for completely consistent data.
If you can show that an attribute that is defined as case sensitive is not preserved when using dynlist for memberof instantiation, then that would be a bug.
That's not the point.
Outside of that, any client that mandates case sensitive matching on items that are not case sensitive is broken by definition.
The issue with case-sensitive POSIX names is a well-understood problem. It's not that easy to deal with.
=> slapo-dynlist should work in a case-preserving way.
Ciao, Michael.
On 6/5/22 23:02, Felix Schäfer wrote:
Am 05.06.2022 um 22:36 schrieb Michael Ströder michael@stroeder.com:
But, like it or not, POSIX names are case-sensitive. So with posixGroup entries you have to preserve the case for completely consistent data. >
It’s not just posix.
Believe me I'm aware of all those issues.
That's the reason why my Æ-DIR mandates lower-cased user and group names.
Ciao, Michael.
Top posting as this goes a bit off-topic.
First, for those administrators that require it, I would recommend arranging to modify the OpenLDAP code to enforce case sensitivity and have the team add the "patch" as a supported "option". I'm not sure how well the team will accept that idea.
Second, though, I'd like to point out that as it stands OpenLDAP does (or seems to, I'm no expert) support the specifications tightly and that is a good thing. Those who care about this, perhaps a dwindling community of old-fashion developers, will hopefully agree with me and consider this an opportunity to test clients for compliance, which would be more difficult if the standards are relaxed.
So I disagree with Felix that this is a show stopper and recommend staying within the boundaries of the standards as far as possible, preferably encouraging others to do the same. Let's try to envisage how Microsoft would handle this and see which situation is preferable.
Lucio.
On 2022/06/05 22:57, Felix Schäfer wrote:
Good evening,
Am 05.06.2022 um 22:00 schrieb Quanah Gibson-Mount quanah@fast-mail.org:
ou is a case insensitive attribute, there is no issue here unless poorly written applications are expecting case sensitivity to be preserved.
Ok, so what you are saying is dynlist can not be used as a drop-in replacement for memberof, correct? Fair, but maybe don’t be surprised if people get discouraged trying to use or using OpenLDAP.
Let’s go with another part of the argument. Are there other case sensitive attributes that could be part of the dn and cause a mismatch because of the casing? Would the casing be discarded in the memberOf in that case?
Anyway, we haven’t migrated yet because of such minutiae. We are not aware of one of the apps using the LDAP being case-sensitive in the memberOf (NextCloud, Zammad and Gitlab don’t seem to be?) attribute, but we’d rather not find out the hard way.
If the answer is „this is intended“, we can live with it and consider dynlist to not be a drop-in replacement for memberof and just continue using the later.
Thanks,
Felix
Hi,
Am 06.06.2022 um 06:06 schrieb Lucio De Re lucio@ff.co.za:
So I disagree with Felix that this is a show stopper and recommend staying within the boundaries of the standards as far as possible, preferably encouraging others to do the same.
Again, my point isn’t to say that one or the other approach is better or even that dynlist should adhere to whatever memberof did. However propping up dynlist to be a drop-in replacement for memberof, which it clearly is not, and especially without caveats attached to that claim, is at least dangerous for whomever might switch later and not pay as much attention, if not disingenuous.
Best,
Felix
--On Monday, June 6, 2022 10:29 AM +0200 Felix Schäfer felix.schaefer@tu-dortmund.de wrote:
Hi,
Am 06.06.2022 um 06:06 schrieb Lucio De Re lucio@ff.co.za:
So I disagree with Felix that this is a show stopper and recommend staying within the boundaries of the standards as far as possible, preferably encouraging others to do the same.
Again, my point isn't to say that one or the other approach is better or even that dynlist should adhere to whatever memberof did. However propping up dynlist to be a drop-in replacement for memberof, which it clearly is not, and especially without caveats attached to that claim, is at least dangerous for whomever might switch later and not pay as much attention, if not disingenuous.
If someone wrote code depending on memberOf to always maintain case with non-case sensitive attributes than their client was broken to begin with, as that was never a guarantee. I.e., the behavior of slapo-memberof could change at any time. So your starting position is invalid since it's based on incorrect assumptions.
slapo-dynlist is a functional replacement for the slapo-memberof that keeps the actual guarantees around the LDAP RFCs. Hope that helps.
--Quanah
On 6/6/22 06:06, Lucio De Re wrote:
Second, though, I'd like to point out that as it stands OpenLDAP does (or seems to, I'm no expert) support the specifications tightly and that is a good thing. Those who care about this, perhaps a dwindling community of old-fashion developers, will hopefully agree with me and consider this an opportunity to test clients for compliance, which would be more difficult if the standards are relaxed.
So I disagree with Felix that this is a show stopper and recommend staying within the boundaries of the standards as far as possible,
Which particular standard are you referring to?
AFAIK no standard mandates to return 'memberOf' values normalized to lower-case. I'd even argue that there's no standard defining 'memberOf' values in particular.
There is only RFC 4517 defining matching-rule distinguishedNameMatch which Quanah is referring to:
https://datatracker.ietf.org/doc/html/rfc4517#section-4.2.15
But on the other hand there's e.g. the POSIX standard defining POSIX "names" to be case-sensitive which is relevant when using posixGroup definition from RFC2307bis.
Like it or not, for strictly matching POSIX group names you *must* distinguish these values no matter what the LDAP matching rule says:
memberOf: cn=Foo,ou=1,dc=example,dc=com memberOf: cn=foo,ou=2,dc=example,dc=com
(note the different parent DNs)
=> Think twice before wiping Felix' request away and choose your poison.
For new deployments: Strictly use lower-cased user and group names for everything resulting in a POSIX name to avoid any of those "standards" conflicts. That's what I'm doing with Æ-DIR.
Ciao, Michael.
P.S.: Anybody here remembering Mark's DBIS effort? He addressed this conflict by defining his own schema:
https://ldapcon.org/2015/accepted-papers/dbis-directory-based-information-se...
--On Monday, June 6, 2022 5:19 PM +0200 Michael Ströder michael@stroeder.com wrote:
But on the other hand there's e.g. the POSIX standard defining POSIX "names" to be case-sensitive which is relevant when using posixGroup definition from RFC2307bis.
posix groups are not LDAP groups, nor should posix groups be represented using memberof.
posixGroup uses "memberUID" and "gidNumber" attributes. Neither of these are LDAP DN based. posixgroup has zero place in any discussion of the memberOf, which is for representing membership information of DN based LDAP groups.
--Quanah
--On Monday, June 6, 2022 8:29 AM -0700 Quanah Gibson-Mount quanah@fast-mail.org wrote:
--On Monday, June 6, 2022 5:19 PM +0200 Michael Ströder michael@stroeder.com wrote:
But on the other hand there's e.g. the POSIX standard defining POSIX "names" to be case-sensitive which is relevant when using posixGroup definition from RFC2307bis.
posix groups are not LDAP groups, nor should posix groups be represented using memberof.
posixGroup uses "memberUID" and "gidNumber" attributes. Neither of these are LDAP DN based. posixgroup has zero place in any discussion of the memberOf, which is for representing membership information of DN based LDAP groups.
Note, that's with RFC2307 definitions. While RFC2307bis does allow the use of DNs for group representations, if you require case sensitivity then case sensitive attributes must be used if one wants them preserved.
--Quanah
--On Monday, June 6, 2022 5:19 PM +0200 Michael Ströder michael@stroeder.com wrote:
Like it or not, for strictly matching POSIX group names you *must* distinguish these values no matter what the LDAP matching rule says:
memberOf: cn=Foo,ou=1,dc=example,dc=com memberOf: cn=foo,ou=2,dc=example,dc=com
(note the different parent DNs)
Regardless of case sensitivity, these are already by definition two entirely separate groups because they point to different entries.
--Quanah
On 6/6/22 16:29, Quanah Gibson-Mount wrote:
--On Monday, June 6, 2022 5:19 PM +0200 Michael Ströder michael@stroeder.com wrote:
But on the other hand there's e.g. the POSIX standard defining POSIX "names" to be case-sensitive which is relevant when using posixGroup definition from RFC2307bis.
posix groups are not LDAP groups, nor should posix groups be represented using memberof.
posixGroup uses "memberUID" and "gidNumber" attributes. Neither of these are LDAP DN based.
True for RFC 2307, wrong when using RFC2307bis:
https://datatracker.ietf.org/doc/html/draft-howard-rfc2307bis#section-5.2
posixgroup has zero place in any discussion of the memberOf
This statement is wrong.
Ciao, Michael.
On 6/6/22 17:35, Quanah Gibson-Mount wrote:
--On Monday, June 6, 2022 5:19 PM +0200 Michael Ströder michael@stroeder.com wrote:
Like it or not, for strictly matching POSIX group names you *must* distinguish these values no matter what the LDAP matching rule says:
memberOf: cn=Foo,ou=1,dc=example,dc=com memberOf: cn=foo,ou=2,dc=example,dc=com
(note the different parent DNs)
Regardless of case sensitivity, these are already by definition two entirely separate groups because they point to different entries.
This is your personal interpretation based on focusing on the DN matching rule.
But it's not a sufficient argument if you think in terms of compability to the origin of the 'memberOf' attribute (MS AD, look at OID used).
Ciao, Michael.
--On Monday, June 6, 2022 7:06 PM +0200 Michael Ströder michael@stroeder.com wrote:
On 6/6/22 17:35, Quanah Gibson-Mount wrote:
--On Monday, June 6, 2022 5:19 PM +0200 Michael Ströder michael@stroeder.com wrote:
Like it or not, for strictly matching POSIX group names you *must* distinguish these values no matter what the LDAP matching rule says:
memberOf: cn=Foo,ou=1,dc=example,dc=com memberOf: cn=foo,ou=2,dc=example,dc=com
This is your personal interpretation based on focusing on the DN matching rule.
That is not an "interpretation". Those are literally two completely different entries as they exist in entirely different namespaces. The first is in ou=1, the second is in ou=2. This is a fundemantal concept of LDAP (regardless of whether or not underneath they could point to the same entry using back-relay or slapo-rwm or something). DN's are by definition unique and point to a singular unique object.
--Quanah
On 6/6/22 18:09, Quanah Gibson-Mount wrote:
--On Monday, June 6, 2022 7:06 PM +0200 Michael Ströder michael@stroeder.com wrote:
On 6/6/22 17:35, Quanah Gibson-Mount wrote:
--On Monday, June 6, 2022 5:19 PM +0200 Michael Ströder michael@stroeder.com wrote:
Like it or not, for strictly matching POSIX group names you *must* distinguish these values no matter what the LDAP matching rule says:
memberOf: cn=Foo,ou=1,dc=example,dc=com memberOf: cn=foo,ou=2,dc=example,dc=com
This is your personal interpretation based on focusing on the DN matching rule.
That is not an "interpretation". Those are literally two completely different entries as they exist in entirely different namespaces. The first is in ou=1, the second is in ou=2.
Welcome to the wonderful world of heterogenous systems integration. Your LDAP server is not the only system. And matching entries during a search and returning values are two different things.
Ciao, Michael.
Michael Ströder michael@stroeder.com schrieb am 05.06.2022 um 23:16 in
Nachricht 51b7e769-522d-a547-4b4e-637e9d035ba6@stroeder.com:
On 6/5/22 23:02, Felix Schäfer wrote:
Am 05.06.2022 um 22:36 schrieb Michael Ströder michael@stroeder.com:
But, like it or not, POSIX names are case-sensitive. So with posixGroup entries you have to preserve the case for completely consistent data. >
It’s not just posix.
Believe me I'm aware of all those issues.
That's the reason why my Æ-DIR mandates lower-cased user and group names.
Ah that bug: In the past we could lock out a user by entering it's name in capitals (the user couldn't log in even with the correct password, as LDAP did find the user). Later the lower-case variant of the user would be locked out as well.
Ciao, Michael.
On 6/7/22 08:25, Ulrich Windl wrote:
Michael Ströder michael@stroeder.com schrieb am 05.06.2022 um 23:16 in
Nachricht 51b7e769-522d-a547-4b4e-637e9d035ba6@stroeder.com:
On 6/5/22 23:02, Felix Schäfer wrote:
Am 05.06.2022 um 22:36 schrieb Michael Ströder michael@stroeder.com:
But, like it or not, POSIX names are case-sensitive. So with posixGroup entries you have to preserve the case for completely consistent data. >
It’s not just posix.
Believe me I'm aware of all those issues.
That's the reason why my Æ-DIR mandates lower-cased user and group names.
Ah that bug: In the past we could lock out a user by entering it's name in capitals (the user couldn't log in even with the correct password, as LDAP did find the user). Later the lower-case variant of the user would be locked out as well.
Hmm, which component enforced the lock out in this case?
Ciao, Michael.
Michael Ströder michael@stroeder.com schrieb am 07.06.2022 um 08:27 in
Nachricht 7ea49afd-d5f1-b7dc-e41a-709e523fdf3e@stroeder.com:
On 6/7/22 08:25, Ulrich Windl wrote:
Michael Ströder michael@stroeder.com schrieb am 05.06.2022 um 23:16
in
Nachricht 51b7e769-522d-a547-4b4e-637e9d035ba6@stroeder.com:
On 6/5/22 23:02, Felix Schäfer wrote:
Am 05.06.2022 um 22:36 schrieb Michael Ströder michael@stroeder.com:
But, like it or not, POSIX names are case-sensitive. So with posixGroup entries you have to preserve the case for completely consistent data. >
It’s not just posix.
Believe me I'm aware of all those issues.
That's the reason why my Æ-DIR mandates lower-cased user and group names.
Ah that bug: In the past we could lock out a user by entering it's name in capitals (the user couldn't log in even with the correct password, as LDAP
did
find the user). Later the lower-case variant of the user would be locked out as well.
Hmm, which component enforced the lock out in this case?
It's quite some time ago; I can hardly remember. I searched and found it. Seems to be a different problem, but now that you were asking, I'm explaining: For NIS compatibility were were uing ent´tries like this at the end of the password file: +@dialog_users:::::: +:NO-LOGIN:::::/sbin/nologin
So all non-dialog users were denied login. When I had eneterd the user in capital letters the NO-LOGIN entry matched, but when entering the name correctly later, I could not log in. I had found out that "getent passwd user" would show /sbin/nologin as shell then.
In that case the solution was: "nscd -i passwd" (invalidate the password cache)
So a different problem it seems, and sorry for the confusion.
Regards, Ulrich
Ciao, Michael.
openldap-technical@openldap.org
-
Felix Schäfer -
Lucio De Re -
Michael Ströder -
Quanah Gibson-Mount -
Ulrich Windl