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.