Brad Hartlove wrote:

I get everything you said. I also understand that this may be a valid permissions issue. If the answer is "it isn't supposed to be done and the server will prevent that", that is what I will go with. This is not my first dance, but if I already knew every detail of LDAP's code, I wouldn't be on this mailing list.

There is no such thing as "LDAP's code" - LDAP is a protocol definition built on a data model. There is "OpenLDAP code" and "SunDS code" etc., various other implementations of the protocol and data model. It is well documented that Sun/Netscape/RedHat/Microsoft implemented the specs incorrectly.

As I have said, I am seeing this defined in

another LDAP's objectClass, so someone figured it out right, wrong, or indifferent. I am not here to argue, so if that is what I go with, so be it. Brad Hartlove

-----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Friday, March 28, 2014 11:08 AM To: Michael Ströder; brad.hartlove@g2-inc.com; openldap-technical@openldap.org Subject: Re: memberof in openldap

Michael Ströder wrote:

...

Brad Hartlove wrote:

...

The core problem is why can I not add the operational attribute to my custom objectclass.

Operational attributes are simply not normal user attributes.

If your LDAP client is supposed to alter an attribute via LDAP it has to be a user attribute. Period.

That's only a partial answer.

Brad, the answer is "go read the LDAP spec" - operational attributes are never part of any objectclass definition, and the server is free to use them in any entry regardless of objectclass.

The OpenLDAP manpages are not here to teach you the basics of LDAP. You're expected to read the specs and know the basics of LDAP.

-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/