[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: OpenLDAP 2.4.16: can not add multiple 'member' attributes to object groupOfNames

Dieter Kluenter wrote:

"O. Hartmann"<ohartman@zedat.fu-berlin.de>  writes:


Michael Ströder wrote:

O. Hartmann wrote:

[...]

Yes, indeed, I tried 'dummy' values and then it worked. Well, why is
"member: port=5432" syntactically invalid? I follow the guideline in
the PostgreSQL 8.4 handbook for LDAP authentication (found here:
http://www.postgresql.org/docs/8.4/interactive/libpq-ldap.html) and
since objectclass:groupOfUniqueNames is supposed to be bogus in
OpenLDAP 2.4 I tried changing it. Strange.


The member attribute description requires distinguishedName syntax and
port=5432 is not a DN.
Assuming the "port" attributeType is defined in the schema, it may be a valid DN. But if not, then not. 


objectclass groupOfUniqueNames is not bogus but it only makes sense if
you provide uniqueness, see RFC 4517, 3.3.21.
The semantics of uniqueness in this context are completely braindead in LDAP. groupofUniqueNames *is* bogus, because uniqueMember uses a bogus syntax.
The NameAndOptionalUID syntax in LDAP is completely stupid and cannot be parsed reliably or logically. 

The X.520 definition of NameAndOptionalUID is:

	NameAndOptionalUid	::=	SEQUENCE {
		dn			DistinguishedName,
		uid			UniqueIdentifier OPTIONAL }
The LDAP transformation into "dn [ # uid ]" is first of all useless because it overlooks the possibility of "#" being an actual part of the rightmost DN component, and is secondly illogical because while at a superficial level it appears to preserve the order specified in X.500, it actually associated the uid to the wrong RDN.
A DN is a sequence of RDNs from most superior to most inferior. E.g., for the DN "cn=foo,ou=users,dc=example,dc=com" the actual ASN.1 encoding should be in this order: 
{	dc com
	dc example
	ou users
	cn foo }
The uid is associated to the object named by the full DN; it is thus logically associated to the object whose RDN is "cn=foo". So a NameAndOptionalUID value with the above dn and uid=101 should look like 
{{	dc com
	dc example
	ou users
	cn foo }
	uid 101 }
Since the LDAP designers screwed up and reversed the order of DNs in their string construction, the logical LDAP format for NameAndOptionalUID should have been "[ uid # ] dn" e.g. 
	101#cn=foo,ou=users,dc=example,dc=com
This would have been perfectly unambiguous, perfectly parseable, and completely logical - keeping the uid associated to the DN element that it actually applies to.
But those mistakes were made over a decade ago and we're stuck with them now. The only sane thing to do now is avoid using uniqueMember / NameAndOptionalUID syntax in 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/