Hi everyone!
This may be a simple question but googling didn't help me at all.
Let's consider ldap add operation. According to RFC4511 Fields of the Add Request are:
- entry: the name of the entry to be added. The server SHALL NOT dereference any aliases in locating the entry to be added.
- attributes: the list of attributes that, along with those from the RDN, make up the content of the entry being added. Clients MAY or MAY NOT include the RDN attribute(s) in this list. Clients MUST NOT supply NO-USER-MODIFICATION attributes such as the createTimestamp or creatorsName attributes, since the server maintains these automatically.so adding something like
dn: uid=test,dc=edu,dc=ru objectClass: testClass
while testClass classify uid as MAY attribute is correct. Ain't I wrong? Though if you try to do it via OpenLDAP you get "Naming violation. Naming attribute uid is not present in entry."
Doesn OpenLDAP really violates RFC here? Or I just don't get something?
Thanks in advance! Regards, Alexander
1 writes:
Let's consider ldap add operation. According to RFC4511 (...)
- attributes: (...) Clients MAY or MAY NOT include the RDN attribute(s) in this list.
(...) dn: uid=test,dc=edu,dc=ru objectClass: testClass
while testClass classify uid as MAY attribute is correct. Ain't I wrong? Though if you try to do it via OpenLDAP you get "Naming violation. Naming attribute uid is not present in entry."
The error message is not about the requirement that an entry must have all 'MUST'-attributes in its object classes. It's about the requirement that all the attributes in the RDN *also* must be present.
In RFC 2251 (the previous revision of LDAPv3), the client had to ensure the latter: The "MAY or MAY NOT include..." you quoted was "MUST include". In RFC 4511, that has become the server's job.
Doesn OpenLDAP really violates RFC here?
Not RFC 2251:-)
1 wrote:
Doesn OpenLDAP really violates RFC here?
Not RFC 2251:-)
Thanks, Hallvard! Now I got it ;)
But it's a pity to learn that OpenLDAP doesn't fully support actual RFC :(
That's not what Hallvard said.
Thanks, Hallvard! Now I got it ;)
But it's a pity to learn that OpenLDAP doesn't fully support actual RFC :(
GH> That's not what Hallvard said.
Sorry, but what do you mean?
Hallvard said, RFC 2251 is a previous revision of LDAPv3 and OpenLDAP doesn't violate it in the part I pointed out. Agree. But it does according to current revision.
As I can see RFC2251 is obsolete and RFC4511 is a proposed standard. The string you disagree isn't what Hallvard said, yeah, but it's my point and actual state of affairs. If I'm wrong please point it out.
Anyway, I don't want to say that it's bad or whatever. I just got software that behaves according to RFC4511 - that was the reason I asked my question.
Regards, Alexander
Alexander Markov wrote:
Thanks, Hallvard! Now I got it ;)
But it's a pity to learn that OpenLDAP doesn't fully support actual RFC :(
GH> That's not what Hallvard said.
Sorry, but what do you mean?
Hallvard said, RFC 2251 is a previous revision of LDAPv3 and OpenLDAP doesn't violate it in the part I pointed out. Agree. But it does according to current revision.
As I can see RFC2251 is obsolete and RFC4511 is a proposed standard. The string you disagree isn't what Hallvard said, yeah, but it's my point and actual state of affairs. If I'm wrong please point it out.
Anyway, I don't want to say that it's bad or whatever. I just got software that behaves according to RFC4511 - that was the reason I asked my question.
In other words, you have software that was broken for the past 10 years that RFC2251 was in effect, before RFC4511 was written to allow your software vendor to get away with never fixing their broken code. Nice.
Howard Chu wrote:
In other words, you have software that was broken for the past 10 years that RFC2251 was in effect, before RFC4511 was written to allow your software vendor to get away with never fixing their broken code. Nice.
But IMO it's worth thinking about how to deal in slapd with the wording "MAY or MAY NOT include the RDN attribute(s)" found in RFC4511 today.
Ciao, Michael.
Michael Ströder wrote:
Howard Chu wrote:
In other words, you have software that was broken for the past 10 years that RFC2251 was in effect, before RFC4511 was written to allow your software vendor to get away with never fixing their broken code. Nice.
But IMO it's worth thinking about how to deal in slapd with the wording "MAY or MAY NOT include the RDN attribute(s)" found in RFC4511 today.
Ultimately, there's nothing to think about. RFC2251 is now obsolete and RFC4511 is the spec, so we'll have to change to comply. It's just a question of someone who feels strongly enough getting motivated to write the patch.
Howard Chu wrote:
But IMO it's worth thinking about how to deal in slapd with the wording "MAY or MAY NOT include the RDN attribute(s)" found in RFC4511 today.
Ultimately, there's nothing to think about. RFC2251 is now obsolete and RFC4511 is the spec, so we'll have to change to comply. It's just a question of someone who feels strongly enough getting motivated to write the patch.
The more I re-read that sentence, the more I think OpenLDAP's slapd still behaves correctly (or, the spec is ambiguous). In fact, according to RFC 4511, now a request that is missing any naming attributes or distinguished values would be legitimate, from a client's perspective, but the server has to ensure that entries conform to user and system schema. So, unless the meaning of "ensure" requires the server to proactively modify the request to "ensure" it complies, simply analyzing it and returning an error code if it doesn't comply, IMHO, complies with the spec. In other words:
CLIENT
| | | v
ADD REQUEST (missing naming attrs/distinguished vals)
- here the request is still valid
-----------------------------------------------------
- here it is no longer valid
|/ x /|\ v
SERVER
So I'd interpret it in the sense that it's not the client's duty to check if the request complies, but a non-compliant request remains invalid.
--- o --- o ---
The issue about OpenLDAP's slapd being able to proactively modify a non-compliant add request in order to make it compliant is a completely different business; this could be easily be accomplished by an overlay, much like slapo-addpartial.
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 writes:
But IMO it's worth thinking about how to deal in slapd with the wording "MAY or MAY NOT include the RDN attribute(s)" found in RFC4511 today.
The more I re-read that sentence, the more I think OpenLDAP's slapd still behaves correctly (or, the spec is ambiguous). (...) unless the meaning of "ensure" requires the server to proactively modify the request to "ensure" it complies, simply analyzing it and returning an error code if it doesn't comply, IMHO, complies with the spec.
You are confusing the protocol request with the directory entry. The server does not modify the request. It acts on the request. The requested action includes to create a directory entry with the attributes mentioned in the request and some not mentioned in the request. The latter include the naming attributes if needed, and various operational attributes like createTimestamp.
openldap-software@openldap.org
-
1 -
Alexander Markov
-
Gavin Henry -
Hallvard B Furuseth -
Howard Chu -
Michael Ströder -
Pierangelo Masarati