One of the odd things I've noticed since moving to OpenLDAP managing memberOf is that memberOf is a hidden attribute by default. Is that because it is treated as operational (due to being managed by the module)?
I can un-hide it for Samba (I have code that adds a list of attributes to any query for *), but I just wanted to check there wasn't a more elegant way to do it.
Thanks,
Andrew Bartlett
Andrew Bartlett wrote:
One of the odd things I've noticed since moving to OpenLDAP managing memberOf is that memberOf is a hidden attribute by default. Is that because it is treated as operational (due to being managed by the module)?
Operational attributes are not returned when using * as attribute list. But they are returned when using +. So use *,+ for fetching all attrs. See also http://www.ietf.org/rfc/rfc3673.txt.
I can un-hide it for Samba (I have code that adds a list of attributes to any query for *), but I just wanted to check there wasn't a more elegant way to do it.
If you're only interested in certain attributes you should not use * anyway since this would return also binary attributes like jpegPhoto and userCertificate which likely are of not much use for Samba, are they?
Ciao, Michael.
On Fri, 2008-01-11 at 10:04 +0100, Michael Ströder wrote:
Andrew Bartlett wrote:
One of the odd things I've noticed since moving to OpenLDAP managing memberOf is that memberOf is a hidden attribute by default. Is that because it is treated as operational (due to being managed by the module)?
Operational attributes are not returned when using * as attribute list. But they are returned when using +. So use *,+ for fetching all attrs. See also http://www.ietf.org/rfc/rfc3673.txt.
I can un-hide it for Samba (I have code that adds a list of attributes to any query for *), but I just wanted to check there wasn't a more elegant way to do it.
If you're only interested in certain attributes you should not use * anyway since this would return also binary attributes like jpegPhoto and userCertificate which likely are of not much use for Samba, are they?
The problem is not Samba4, but Samba4's clients. See, Samba4 is an LDAP proxy in this situation, and has a role simply to try and make OpenLDAP look more like AD than it does at present.
Samba4's clients are written expecting AD's behaviour, and while I might hope that they would explicitly request the attributes they need, if I can make such mistakes in my test scripts, so can they...
Andrew Bartlett
Andrew Bartlett wrote:
I can un-hide it for Samba (I have code that adds a list of attributes to any query for *), but I just wanted to check there wasn't a more elegant way to do it.
The only alternative I see consists in moving the addition of "memberOf" to the list of attrs when it's empty, or '*' is present and either '+' or 'extensibleObject' are absent, into slapd (again, using an overlay).
If you're only interested in certain attributes you should not use * anyway since this would return also binary attributes like jpegPhoto and userCertificate which likely are of not much use for Samba, are they?
The problem is not Samba4, but Samba4's clients. See, Samba4 is an LDAP proxy in this situation, and has a role simply to try and make OpenLDAP look more like AD than it does at present.
Samba4's clients are written expecting AD's behaviour, and while I might hope that they would explicitly request the attributes they need, if I can make such mistakes in my test scripts, so can they...
The addition of this feature is (almost) trivial. So the decision should be based on: - should this "feature" be exposed to all users, or - should it be exposed only to users using samba4 as proxy? I'll code it anyway (not now, perhaps later today) and let you decide after experimenting.
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:
Samba4's clients are written expecting AD's behaviour, and while I might hope that they would explicitly request the attributes they need, if I can make such mistakes in my test scripts, so can they...
The addition of this feature is (almost) trivial. So the decision should be based on:
- should this "feature" be exposed to all users, or
- should it be exposed only to users using samba4 as proxy?
I think the latter. See, my main scope as a consultant is directory integration/consolidation. So my recommendation is that everything should be avoided which turns an OpenLDAP directory into a special Samba4 LDAP backend which is not usable with other LDAPv3 compliant software anymore.
How about such an overlay specially treating * based on <who> like defined in ACLs? Or maybe one should recommend in a deployment note to use this overlay with back-ldap?
Ciao, Michael.
Michael Ströder wrote:
Pierangelo Masarati wrote:
Andrew Bartlett wrote:
Samba4's clients are written expecting AD's behaviour, and while I might hope that they would explicitly request the attributes they need, if I can make such mistakes in my test scripts, so can they...
The addition of this feature is (almost) trivial. So the decision should be based on:
- should this "feature" be exposed to all users, or
- should it be exposed only to users using samba4 as proxy?
I think the latter. See, my main scope as a consultant is directory integration/consolidation. So my recommendation is that everything should be avoided which turns an OpenLDAP directory into a special Samba4 LDAP backend which is not usable with other LDAPv3 compliant software anymore.
The fact that we always speak about overlays/modules instead of direct modifications to OpenLDAP should be intended to make sure that OpenLDAP itself does not drift from its route, i.e. becoming as compliant as possible with standard track. In this sense, I believe all modules developed for the sole purpose of downgrading OpenLDAP to behave like AD should clearly carry the indication that they introduce a breach into LDAP specs, and that this breach is intentional for a specific purpose. LDAPv3 client users and developers should be cautioned about relying on those breaches.
How about such an overlay specially treating * based on <who> like defined in ACLs?
I don't think this a viable solution since it appears to require too much effort; moreover, there might not be a practical way to distinguish accesses by samba4 and accesses by other clients.
Or maybe one should recommend in a deployment note to use this overlay with back-ldap?
The deployment note should recommend to avoid using this overlay at all, except for the purpose it was designed. I would recommend to avoid distributing it with OpenLDAP; rather, with samba4 for use with OpenLDAP.
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 Mon, 2008-01-14 at 16:59 +0100, Pierangelo Masarati wrote:
Michael Ströder wrote:
Pierangelo Masarati wrote:
Andrew Bartlett wrote:
Samba4's clients are written expecting AD's behaviour, and while I might hope that they would explicitly request the attributes they need, if I can make such mistakes in my test scripts, so can they...
The addition of this feature is (almost) trivial. So the decision should be based on:
- should this "feature" be exposed to all users, or
- should it be exposed only to users using samba4 as proxy?
I think the latter. See, my main scope as a consultant is directory integration/consolidation. So my recommendation is that everything should be avoided which turns an OpenLDAP directory into a special Samba4 LDAP backend which is not usable with other LDAPv3 compliant software anymore.
The fact that we always speak about overlays/modules instead of direct modifications to OpenLDAP should be intended to make sure that OpenLDAP itself does not drift from its route, i.e. becoming as compliant as possible with standard track. In this sense, I believe all modules developed for the sole purpose of downgrading OpenLDAP to behave like AD should clearly carry the indication that they introduce a breach into LDAP specs, and that this breach is intentional for a specific purpose. LDAPv3 client users and developers should be cautioned about relying on those breaches.
How about such an overlay specially treating * based on <who> like defined in ACLs?
I don't think this a viable solution since it appears to require too much effort; moreover, there might not be a practical way to distinguish accesses by samba4 and accesses by other clients.
Indeed - how access control and identity is handled is a matter that will continue to evolve. I would hate to see that made more complected by mixing this into the puzzle.
Or maybe one should recommend in a deployment note to use this overlay with back-ldap?
The deployment note should recommend to avoid using this overlay at all, except for the purpose it was designed. I would recommend to avoid distributing it with OpenLDAP; rather, with samba4 for use with OpenLDAP.
While I don't want to be antagonistic about this, if it becomes a situation where Samba4 has to distribute OpenLDAP overlays (rather than have a reasonable expectation that distributions will pick them up as part of OpenLDAP distributions), I'm worried about the logistics.
How would Samba best go about packaging, maintaining and distributing OpenLDAP overlays? How specific to particular versions of OpenLDAP are overlays, when built as binaries?
Also, how would I as an external package build an overlay against OpenLDAP? Would the normal results of an OpenLDAP installation be enough? (I'm just not familiar with this area).
Fortunately, in this particular case I already handle on the client side (where I prefer to handle most of this). My philosophy is to do as much as possible on the client side, as this will promote interoperability with other directory servers, if and when they want to have Samba4 support as well. But I like to at least ask the question, as the less fiddling I have to do the better.
I also think it could be useful to others in future, as transitions are made from manual to automatic management of some attributes.
Andrew Bartlett
Andrew Bartlett wrote:
Or maybe one should recommend in a deployment note to use this overlay with back-ldap?
The deployment note should recommend to avoid using this overlay at all, except for the purpose it was designed. I would recommend to avoid distributing it with OpenLDAP; rather, with samba4 for use with OpenLDAP.
While I don't want to be antagonistic about this, if it becomes a situation where Samba4 has to distribute OpenLDAP overlays (rather than have a reasonable expectation that distributions will pick them up as part of OpenLDAP distributions), I'm worried about the logistics.
How would Samba best go about packaging, maintaining and distributing OpenLDAP overlays? How specific to particular versions of OpenLDAP are overlays, when built as binaries?
Also, how would I as an external package build an overlay against OpenLDAP? Would the normal results of an OpenLDAP installation be enough? (I'm just not familiar with this area).
Fortunately, in this particular case I already handle on the client side (where I prefer to handle most of this). My philosophy is to do as much as possible on the client side, as this will promote interoperability with other directory servers, if and when they want to have Samba4 support as well. But I like to at least ask the question, as the less fiddling I have to do the better.
I also think it could be useful to others in future, as transitions are made from manual to automatic management of some attributes.
I was not speaking "officially"; I just wanted to note that we have a somewhat "loose" policy about external modules:
- generally useful: get into servers/slapd/overlays/ and known to configure, so that they can either be statically built into slapd or built and installed as run-time modules
- less generally useful: get distributed into contrib/slapd-modules/ and usually maintained lined up with the rest of the suite
- even less generally useful: remain into the ITS in the contrib folder and, unless the contributor maintains them, they slowly fade away because of the evolution of slapd.
Specially developed modules that are mainly useful for interaction with Samba4, like those we're prototyping in these days, would be generally useful for Samba4 users/developers, but while in some cases they might be of really general usefulness even for non-Samba4 users, in other cases they are quite specific and occasionally violate LDAPv3 specs. In that case, it is (as usual) a matter of drawing the line.
I don't have any objection into maintaining and distributing, say, the contents of a folder contrib/slapd-samba4-modules, including a dedicated configure (or extending OpenLDAP's, or whatever), but I'd like to make it clear what modules are, let's say, recommended for general use and what are not, unless in the specific context of interoperating with Samba4.
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 Tue, 2008-01-15 at 09:41 +0100, Pierangelo Masarati wrote:
Andrew Bartlett wrote:
Or maybe one should recommend in a deployment note to use this overlay with back-ldap?
The deployment note should recommend to avoid using this overlay at all, except for the purpose it was designed. I would recommend to avoid distributing it with OpenLDAP; rather, with samba4 for use with OpenLDAP.
While I don't want to be antagonistic about this, if it becomes a situation where Samba4 has to distribute OpenLDAP overlays (rather than have a reasonable expectation that distributions will pick them up as part of OpenLDAP distributions), I'm worried about the logistics.
How would Samba best go about packaging, maintaining and distributing OpenLDAP overlays? How specific to particular versions of OpenLDAP are overlays, when built as binaries?
Also, how would I as an external package build an overlay against OpenLDAP? Would the normal results of an OpenLDAP installation be enough? (I'm just not familiar with this area).
Fortunately, in this particular case I already handle on the client side (where I prefer to handle most of this). My philosophy is to do as much as possible on the client side, as this will promote interoperability with other directory servers, if and when they want to have Samba4 support as well. But I like to at least ask the question, as the less fiddling I have to do the better.
I also think it could be useful to others in future, as transitions are made from manual to automatic management of some attributes.
I was not speaking "officially"; I just wanted to note that we have a somewhat "loose" policy about external modules:
- generally useful: get into servers/slapd/overlays/ and known to
configure, so that they can either be statically built into slapd or built and installed as run-time modules
- less generally useful: get distributed into contrib/slapd-modules/ and
usually maintained lined up with the rest of the suite
- even less generally useful: remain into the ITS in the contrib folder
and, unless the contributor maintains them, they slowly fade away because of the evolution of slapd.
Thanks for spelling this out.
Specially developed modules that are mainly useful for interaction with Samba4, like those we're prototyping in these days, would be generally useful for Samba4 users/developers, but while in some cases they might be of really general usefulness even for non-Samba4 users, in other cases they are quite specific and occasionally violate LDAPv3 specs. In that case, it is (as usual) a matter of drawing the line.
I don't have any objection into maintaining and distributing, say, the contents of a folder contrib/slapd-samba4-modules, including a dedicated configure (or extending OpenLDAP's, or whatever), but I'd like to make it clear what modules are, let's say, recommended for general use and what are not, unless in the specific context of interoperating with Samba4.
This all seems quite reasonable. I think we can make progress on this basis, and if we are careful it should not hinder either Samba4 or OpenLDAP's mission.
Andrew Bartlett
Pierangelo Masarati wrote:
Samba4's clients are written expecting AD's behaviour, and while I might hope that they would explicitly request the attributes they need, if I can make such mistakes in my test scripts, so can they...
The addition of this feature is (almost) trivial. So the decision should be based on:
- should this "feature" be exposed to all users, or
- should it be exposed only to users using samba4 as proxy?
I'll code it anyway (not now, perhaps later today) and let you decide after experimenting.
Prototype:
http://www.sys-net.it/~ando/Download/opattrs_expose.c
Should be improved to make "memberOf" configurable, and handle a list of operational attrs to expose (I bet there's more than just "memberOf").
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 Mon, 2008-01-14 at 14:34 +0100, Pierangelo Masarati wrote:
Andrew Bartlett wrote:
I can un-hide it for Samba (I have code that adds a list of attributes to any query for *), but I just wanted to check there wasn't a more elegant way to do it.
The only alternative I see consists in moving the addition of "memberOf" to the list of attrs when it's empty, or '*' is present and either '+' or 'extensibleObject' are absent, into slapd (again, using an overlay).
Looking at this again, why is memberOf operational, or indeed special?
As far as I can tell, if I do:
diff -u -r1.19 memberof.c --- servers/slapd/overlays/memberof.c 11 Jan 2008 05:07:43 -0000 1.19 +++ servers/slapd/overlays/memberof.c 16 Jan 2008 05:29:39 -0000 @@ -2032,6 +2032,7 @@ { int code, i;
+#if 0 for ( i = 0; as[ i ].desc != NULL; i++ ) { code = register_at( as[ i ].desc, as[ i ].adp, 0 ); if ( code ) { @@ -2041,6 +2042,7 @@ return code; } } +#endif
memberof.on_bi.bi_type = "memberof";
Then it just works, and I don't have to do an extra fish for this particular operational attribute.
What am I missing?
Andrew Bartlett
--On Wednesday, January 16, 2008 4:31 PM +1100 Andrew Bartlett abartlet@samba.org wrote:
Then it just works, and I don't have to do an extra fish for this particular operational attribute.
I'm somewhat curious why "memberOf" the attribute would be operational. "member" isn't, and it is of a similar vein..
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
On Tue, 2008-01-15 at 21:46 -0800, Quanah Gibson-Mount wrote:
--On Wednesday, January 16, 2008 4:31 PM +1100 Andrew Bartlett abartlet@samba.org wrote:
Then it just works, and I don't have to do an extra fish for this particular operational attribute.
I'm somewhat curious why "memberOf" the attribute would be operational. "member" isn't, and it is of a similar vein..
In the AD aggregate schema they are marked:
attributeTypes: ( 1.2.840.113556.1.2.102 NAME 'memberOf' SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' NO-USER-MODIFICATION ) attributeTypes: ( 2.5.4.31 NAME 'member' SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' )
'memberOf' is the end that is calculated, while 'member' is the end being modified by the administrator.
Andrew Bartlett
--On Wednesday, January 16, 2008 4:59 PM +1100 Andrew Bartlett abartlet@samba.org wrote:
'memberOf' is the end that is calculated, while 'member' is the end being modified by the administrator.
Ah, I see. Somewhat annoying though, I always thought it'd be nice to use it to make dynamic groups from. Oh well.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
On Tue, 2008-01-15 at 22:33 -0800, Quanah Gibson-Mount wrote:
--On Wednesday, January 16, 2008 4:59 PM +1100 Andrew Bartlett abartlet@samba.org wrote:
'memberOf' is the end that is calculated, while 'member' is the end being modified by the administrator.
Ah, I see. Somewhat annoying though, I always thought it'd be nice to use it to make dynamic groups from. Oh well.
Which is perhaps why it should not be defined in the module, as otherwise I can't see why you should not be able to configure the module that way around.
Andrew Barteltt
Andrew Bartlett wrote:
On Tue, 2008-01-15 at 22:33 -0800, Quanah Gibson-Mount wrote:
--On Wednesday, January 16, 2008 4:59 PM +1100 Andrew Bartlett abartlet@samba.org wrote:
'memberOf' is the end that is calculated, while 'member' is the end being modified by the administrator.
Ah, I see. Somewhat annoying though, I always thought it'd be nice to use it to make dynamic groups from. Oh well.
Which is perhaps why it should not be defined in the module, as otherwise I can't see why you should not be able to configure the module that way around.
It has to be defined by __a__ module because there's no other way to define operational attrs: through configuration you can only define user attrs.
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 ---------------------------------------
Andrew Bartlett wrote:
On Tue, 2008-01-15 at 21:46 -0800, Quanah Gibson-Mount wrote:
--On Wednesday, January 16, 2008 4:31 PM +1100 Andrew Bartlett abartlet@samba.org wrote:
Then it just works, and I don't have to do an extra fish for this particular operational attribute.
I'm somewhat curious why "memberOf" the attribute would be operational. "member" isn't, and it is of a similar vein..
In the AD aggregate schema they are marked:
attributeTypes: ( 1.2.840.113556.1.2.102 NAME 'memberOf' SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' NO-USER-MODIFICATION ) attributeTypes: ( 2.5.4.31 NAME 'member' SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' )
'memberOf' is the end that is calculated, while 'member' is the end being modified by the administrator.
I wanted the attribute playing the role of "memberOf" operational for two reasons:
- so that it can apply to any object without the need to be allowed by its objectClass chain and without the need to add the extensibleObject class, or the need to define and add an extra "canBeMemberOfGroup" class
- because it is managed by the DSA
There are other solutions, like the one I mentioned in the first place.
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 ---------------------------------------
Quanah Gibson-Mount wrote:
--On Wednesday, January 16, 2008 4:31 PM +1100 Andrew Bartlett abartlet@samba.org wrote:
Then it just works, and I don't have to do an extra fish for this particular operational attribute.
I'm somewhat curious why "memberOf" the attribute would be operational.
Its value is generated by the DSA.
"member" isn't, and it is of a similar vein..
No, it's not similar. It's usually maintained by a directory user with a DUA. BTW: Abusing attribute 'member' for dynamic grouping is a hack not really compliant with the original schema.
Ciao, Michael.
Andrew Bartlett wrote:
One of the odd things I've noticed since moving to OpenLDAP managing memberOf is that memberOf is a hidden attribute by default. Is that because it is treated as operational (due to being managed by the module)?
I can un-hide it for Samba (I have code that adds a list of attributes to any query for *), but I just wanted to check there wasn't a more elegant way to do it.
It is hidden because, due to design considerations, the memberof (or any reverse membership link) has to be operational, and OpenLDAP does only return user attributes if the attribute list is empty or equal to "*".
I think it MUST be operational because any class of entries must be allowed to be listed as member of a group; thus, the memberOf attribute has to be allowed by any objectClass. The only valid option would have been to add the extensibleObject class to all group members, and I didn't consider this a viable option. Moreover, it is by no means a user attribute, since it is maintained by the DSA (and the user must not be allowed to much with it).
For those reasons, I believe returning it by default has to be an option, since it seems definitely appropriate to require a client to explicitly request it.
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 Fri, 2008-01-11 at 17:57 +0100, Pierangelo Masarati wrote:
Andrew Bartlett wrote:
One of the odd things I've noticed since moving to OpenLDAP managing memberOf is that memberOf is a hidden attribute by default. Is that because it is treated as operational (due to being managed by the module)?
I can un-hide it for Samba (I have code that adds a list of attributes to any query for *), but I just wanted to check there wasn't a more elegant way to do it.
It is hidden because, due to design considerations, the memberof (or any reverse membership link) has to be operational, and OpenLDAP does only return user attributes if the attribute list is empty or equal to "*".
I think it MUST be operational because any class of entries must be allowed to be listed as member of a group; thus, the memberOf attribute has to be allowed by any objectClass. The only valid option would have been to add the extensibleObject class to all group members, and I didn't consider this a viable option.
I was about to argue that memberOf should just be in the normal schema, and that normal schema checks should apply. But Microsoft puts 'memberOf' in their 'top', so aside from being hidden, it seems perfectly appropriate to be a operational attribute...
Moreover, it is by no means a user attribute, since it is maintained by the DSA (and the user must not be allowed to much with it).
For those reasons, I believe returning it by default has to be an option, since it seems definitely appropriate to require a client to explicitly request it.
If there is a way to make it appear by default, I would appreciate it.
Andrew Bartlett
openldap-technical@openldap.org
-
Andrew Bartlett -
Michael Ströder -
Pierangelo Masarati -
Quanah Gibson-Mount