Solaris netgroups and openldap problem was due to nis.schema

[dijuremo@math.gatech.edu]

This posting is in reference to:

http://www.openldap.org/lists/openldap-software/200408/msg00483.html

where Kurt said solaris clients were to blame because of wrong search
filters while querying netgroups, but that is not totally correct.

It turns out the issue with Solaris clients querying netgroups is a schema
problem.  Here is what we got from sun.  We have modified the schema and
things work fine with solaris clients querying netgroups just fine from our
openldap server.

Is it possible to include this modification for the nis.schema for future
openldap releases?

Diego

######################### Quoting sun engineer #####################

Progress:
***********
I believe that I now understand the differences between OpenLDAP and our
LDAP server, as far as nisNetGroupTriple attribute is concerned.

OpenLDAP provides the following definition for nisNetGroupTriple in the
schmea file nis.schema:

attributetype ( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple'
         DESC 'Netgroup triple'
         SYNTAX 1.3.6.1.1.1.0.0 )
where 1.3.6.1.1.1.0.0 is nisNetgroupTripleSyntax.

which looks compliant to RFC2307 (An Approach for Using LDAP as a Network
Information Service, all details from:

  http://www.ietf.org/rfc/rfc2307.txt?number=2307).

Sun's OpenLDAP server, when configured to serve Native LDAP clients, comply
to RFC2307bis, which is a *draft* revised version of RFC2307. Note that man
page for ldap(9) on Solaris 9 states:
....
      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.
......

Anyway, this draft defines nisNetGroupTriple as follow:

( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple'
                DESC 'Netgroup triple'
                EQUALITY caseIgnoreIA5Match
                SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
where 1.3.6.1.4.1.1466.115.121.1.2 is IA5 String (that is, ASCII string).

The other important bit here is the EQUALITY line, which states that LDAP
search operations on the value of attribute nisNetgroupTriple are allowed
(e.g., with a filter such as nisNetgroupTriple=<some_value>).

If this line is not present, such LDAP search operations are not allowed,
and only LDAP search operations on the existence of this attribute (e.g.,
with a filter such as nisNetgroupTriple=*) are allowed.

These differences explains why:

1. OpenLDAP server, when using the default nis.schema files,
    does not understand the filters sent by Solaris Native LDAP
    clients, when looking for netgroup triples.
2. OpenLDAP server, when using the suggested schema for RFC2307bis,
    does understand such filters for nisNetgroupTriple, and hence
    responds to the ldapsearch that use such filters.

However, OpenLDAP server still does not process as expected (by Solaris
Native LDAP clients at least) filters such as:

nisNetgroupTriple=(<machine>,*,*).

Reason is that such filters trigger substring searches, which are not
explicitly allowed by the definition for nisNetgroupTriple.

Modifying the schema so that nisNetgroupTriple definition is:

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 )

does seem to solve the issue (note the extra SUBSTR line).

######################### Quoting sun engineer #####################