Jeff Blaine wrote:

I've come across the same problem as the original poster found here:

http://www.openldap.org/lists/openldap-technical/200804/msg00127.html

The only reply to him indicated that his syntax was incorrect for nisnetgrouptriple according to RFC 2307.

I cannot see how it is invalid based on the syntax definition from RFC 2307.

My example:

...

dn: cn=users1,ou=Netgroup,dc=rcf,dc=foo,dc=com objectClass: nisNetgroup objectClass: top cn: users1 nisNetgroupTriple: (-,asgen2m,) nisNetgroupTriple: (-,apdons,) nisNetgroupTriple: (-,ffeins,) nisNetgroupTriple: (-,faullton,)

The syntax definition:

...

nisnetgrouptriple = "(" hostname "," username "," domainname ")" hostname = "" / "-" / keystring username = "" / "-" / keystring domainname = "" / "-" / keystring

Does that not state that hostname, username, domainname can each be ANY of:

empty
-
keystring

??

Your example loads seamlessly on OpenLDAP 2.4. What version are you using? What's the exact issue you're encountering?

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: ando@sys-net.it -----------------------------------

Jeff Blaine wrote:

Interesting.

First, thanks for the reply. Second, I apologize for "sanitizing" my example with fake names in the nisNetgroupTriples because it dodged the actual problem.

It appears the problem is with underscores in the triples' values:

nisNetgroupTriple: (-,foo_bar,)

Apparently an underscore is not valid in a 'keystring'?

An underscore __should__ be valid in the username part of nisNetgroupTriple, since it seems to be valid in usernames (alnum, "-", "_", ".", as far as I can tell, which means current code misses the "_"), although I don't have any authoritative reference handy.

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: ando@sys-net.it -----------------------------------

Changing the definition of nisNetgroupTriple in nis.schema to the modern-but-unofficial definition solves the problem for us. We'll just need to remember to always drop our nis.schema in place with every OpenLDAP upgrade :/

attributetype ( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple' DESC 'Netgroup triple' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

FWIW, from the ldap man page for Solaris:

Solaris LDAP clients use the LDAP v3 protocol to access nam- ing information from LDAP servers. The LDAP server must sup- port the object classes and attributes defined in RFC2307bis (draft), which maps the naming service model on to LDAP.

I wonder what, if any, other problems I'll run into with Solaris clients querying non-Solaris OpenLDAP servers.

Thanks for the help.

Hallvard B Furuseth wrote:

Pierangelo Masarati writes:

...

Jeff Blaine wrote:

...

Interesting.

First, thanks for the reply. Second, I apologize for "sanitizing" my example with fake names in the nisNetgroupTriples because it dodged the actual problem.

It appears the problem is with underscores in the triples' values:

nisNetgroupTriple: (-,foo_bar,)

Apparently an underscore is not valid in a 'keystring'?

Right. RFC 2307 refers to RFC 2252 (sectin 4.1) which defines it as allowing letters, digits, "-" and ";".

...

An underscore __should__ be valid in the username part of nisNetgroupTriple, (...)

It should have been. There is an "rfc2307bis" document which is supposed to update RFC 2307 if it ever gets released, and that simply uses the IA5 String syntax (in practice ASCII string) for nisNetgroupTriple.

RFC 2307 some other quirks, e.g. it demands the gecos field is ASCII. For that matter, I'm sure someone out there uses 8-bit usernames and directory names.