Re: [nssldap] nss_map_attribute gidNumber problem

[Jeffrey Watts <jeffrey.w.watts [at] gmail.com>]

Unix groups also have a gidNumber.  What I suspect is happening is that when you map gidNumber to gidNumberSYS1, the LDAP groups do not have that attribute defined and thus gidNumber gets mapped by default to cn.

I'm not sure if there's a way to add filter options to nss_map_attribute much like you can with nss_base_group.  For example, it'd be nice to be able to do something like:

nss_map_attribute gidNumber gidNumberSYS1 &(objectcategory=user)
Basically:  <attribute> <value> <filter>

If the functionality doesn't exist it might be a good thing to suggest for a future version.

Jeffrey.

On Thu, Feb 11, 2010 at 3:16 AM, Liam Gretton <liam.gretton [at] leicester.ac.uk> wrote:

I have user accounts for various systems within an OpenLDAP db (OpenLDAP 2.4.12 on openSUSE 11.1). Clients are running the same version on the same OS. Both are using nss_ldap 262.

As accounts have different requirements depending on which host is being logged into, I've created a custom schema which implements the following custom attributes:

loginShellSYS1
homeDirectorySYS1
gidNumberSYS1

...and so on for multiple SYSn systems.

On the client using nss_ldap side I am mapping these to the plain
attributes as so in /etc/ldap.conf:

nss_map_attribute loginShell loginShellSYS1
nss_map_attribute homeDirectory homeDirectorySYS1
nss_map_attribute gidNumber gidNumberSYS1

Everything works perfectly EXCEPT for the gidNumber mapping. If that's
in place then 'getent group' does not return the LDAP groups. The logs on the LDAP server logs show that when gidNumber is mapped, getent is requesting 'cn' instead of 'gidNumber' from the record. Without the mapping, it correctly requests the gidNumber attribute.

ldapsearch on an account from the client returns all the expected
attributes including the gidNumberSYSn ones.

The LDAP accounts also have a normal gidNumber attribute, and if I
remove the mapping and use that, then getent group returns the expected
results.

It's entirely likely that I've done something plain silly which is
causing this problem, but is there any special behaviour regarding group mapping that I should have taken into account?

-- 

"He that would make his own liberty secure must guard even his enemy from oppression; for if he violates this duty he establishes a precedent that will reach to himself." -- Thomas Paine