4:16 a.m.
Hello,
I try to add multiple member attributes to an object of type
groupOfNames and I fail. The same is for objectClass groupOfUniqueNames.
Whenever I try to add the multi-attribute, I receive an error like
'info: member: value #1 invalid per syntax, dec: invalid syntax'. I can
add exactly one attribute of type 'member' for this object.
Well, I'm confused, since this worked in older OpenLDAP versions (I'm
now using 2.4.16). The client(s) I try to add attributes are 'ldapadd'
with a regular LDIF file (file works well if only ONE member-attribute
is specified), LUMA and LAM. All have their described problems.
I guess there is a knob I've overseen or I do something conceptionally
wrong with OpenLDAP 2.4.
Can you help?
Regards,
Oliver
P.S. Server is OpenLDAP 2.4.16 on FreeBSD 7.2 and 8.0, for information.
7:20 a.m.
New subject: OpenLDAP 2.4.16: can not add multiple 'member' attributes to object groupOfNames
O. Hartmann wrote:
I try to add multiple member attributes to an object of type
groupOfNames and I fail. The same is for objectClass groupOfUniqueNames.
Whenever I try to add the multi-attribute, I receive an error like
'info: member: value #1 invalid per syntax, dec: invalid syntax'. I can
add exactly one attribute of type 'member' for this object.
This diagnostic message says that the 2nd value does not conform to the
syntax, here 'DistinguishedName' for attribute type 'member'. Maybe you
could post the data you're trying to add?
Well, I'm confused, since this worked in older OpenLDAP versions
(I'm
now using 2.4.16).
It might be that very old versions of OpenLDAP (prior 2.3) were more
loose on some syntax checking. But if the attribute values of 'member'
are all valid DNs there should not be any problem.
The client(s) I try to add attributes are 'ldapadd'
with a regular LDIF file (file works well if only ONE member-attribute
is specified), LUMA and LAM. All have their described problems.
That's because the OpenLDAP server rejects the input data as invalid.
Ciao, Michael.
--
Michael Ströder
E-Mail: michael(a)stroeder.com
http://www.stroeder.com
11:13 p.m.
New subject: OpenLDAP 2.4.16: can not add multiple 'member' attributes to object groupOfNames
Michael Ströder wrote:
O. Hartmann wrote:
> I try to add multiple member attributes to an object of type
> groupOfNames and I fail. The same is for objectClass groupOfUniqueNames.
> Whenever I try to add the multi-attribute, I receive an error like
> 'info: member: value #1 invalid per syntax, dec: invalid syntax'. I can
> add exactly one attribute of type 'member' for this object.
This diagnostic message says that the 2nd value does not conform to the
syntax, here 'DistinguishedName' for attribute type 'member'. Maybe you
could post the data you're trying to add?
> Well, I'm confused, since this worked in older OpenLDAP versions (I'm
> now using 2.4.16).
It might be that very old versions of OpenLDAP (prior 2.3) were more
loose on some syntax checking. But if the attribute values of 'member'
are all valid DNs there should not be any problem.
> The client(s) I try to add attributes are 'ldapadd'
> with a regular LDIF file (file works well if only ONE member-attribute
> is specified), LUMA and LAM. All have their described problems.
That's because the OpenLDAP server rejects the input data as invalid.
Ciao, Michael.
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.
Oliver
1:50 a.m.
New subject: OpenLDAP 2.4.16: can not add multiple 'member' attributes to object groupOfNames
O. Hartmann wrote:
Michael Ströder wrote:
> O. Hartmann wrote:
>> I try to add multiple member attributes to an object of type
>> groupOfNames and I fail. The same is for objectClass groupOfUniqueNames.
>> Whenever I try to add the multi-attribute, I receive an error like
>> 'info: member: value #1 invalid per syntax, dec: invalid syntax'. I can
>> add exactly one attribute of type 'member' for this object.
>
> This diagnostic message says that the 2nd value does not conform to the
> syntax, here 'DistinguishedName' for attribute type 'member'. Maybe
you
> could post the data you're trying to add?
Yes, indeed, I tried 'dummy' values and then it worked. Well, why is
"member: port=5432" syntactically invalid?
This is likely because attribute 'port' is not defined in your subschema.
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.
Using 'groupOfNames' is just fine.
Ciao, Michael.
--
Michael Ströder
E-Mail: michael(a)stroeder.com
http://www.stroeder.com
1:06 a.m.
New subject: OpenLDAP 2.4.16: can not add multiple 'member' attributes to object groupOfNames
"O. Hartmann" <ohartman(a)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.
objectclass groupOfUniqueNames is not bogus but it only makes sense if
you provide uniqueness, see RFC 4517, 3.3.21.
-Dieter
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:8EF7B6C6
53°08'09,95"N
10°08'02,42"E
1:54 a.m.
New subject: OpenLDAP 2.4.16: can not add multiple 'member' attributes to object groupOfNames
Dieter Kluenter wrote:
"O. Hartmann"<ohartman(a)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/
4:19 a.m.
New subject: NameAndOptionalUID (was: OpenLDAP 2.4.16: can not add multiple 'member' attributes to object groupOfNames)
Howard Chu wrote:
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 UniqueIdentifier is BIT STRING. Looking at section 3.3.21. of RFC
4517 it's declared like this:
NameAndOptionalUID = distinguishedName [ SHARP BitString ]
[..]
Example:
1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
This could also be a valid DN.
So the way it is used in various deployments with values like
uid=user1,dc=example,dc=com#user1
is invalid either. AFAICS nobody uses BitString syntax for real-world
attribute values at all. Well, others are confused too by
UniqueIdentifier not being a normal string-based UID:
https://issues.apache.org/bugzilla/show_bug.cgi?id=45107
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.
I don't understand this sentence. Could you please elaborate on that?
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.
I don't understand that either. How is "uid 101" related to the DN at
all? From my understanding the UniqueIdentifier could be just any unique
identifier represented as BitString and may be part of the referenced
entry e.g. in attribute 'x500UniqueIdentifier'. How the DSA would make
use of this UniqueIdentifier is completely implementation-specific.
I agree that
NameAndOptionalUID = BitString SHARP distinguishedName
would have been better. But then the UID could not be optional.
Anyway this is all academic. I don't see a real use-case for
groupOfUniqueNames->uniqueMember either...
Ciao, Michael.
5186
days inactive
5192
days old
openldap-software@openldap.org
6 comments
4 participants
participants (4)
-
Dieter Kluenter -
Howard Chu -
Michael Ströder -
O. Hartmann