From my own investigation, if you have all the normal PAM / nsswitch.conf
plumbing set up, you can do this, but only by adding the local user to the group in the LDAP database directly using ldapmodify
on the memberUid
attribute on the LDAP server (see here):
$ ldapmodify -D <admin DN> -h <ldaphost> -W
password: [enter password]
dn: cn=vipb,ou=groups,dc=example,dc=com
changetype: modify
add: memberUid
memberUid: fred
^D
Note that the blank line is necessary.
Next, you have to invalidate the NCSD cache on server 2:
$ nscd --invalidate=group
You can then check the group membership on server 2 by issuing:
$ id -nG fred
CAVEAT: The use of LDAP as a user database relies on the schema detailed in this draft standard: rfc2307bis-02. There are THREE versions of the standard so far. Amongst the things that get tweaked between versions are the member and memberUid attributes; this means your LDAP set up may not play nicely. A fully bis-02 compliant install should contain and support both attributes: memberUid
(for local logins members of the LDAP group, without a dn) and member
(for LDAP users with a full dn) within a given group. They should also allow either or both to be empty, allowing empty groups. Your mileage may vary - you'll need to check your server's schema.
Tools like webmin can be useful for manipulating the LDAP users and groups and the LDAP database; but again they may not play nicely with rfc2307bis-02. For example, Webmin's LDAP Users and Groups module, copes with memberUid but not member.
Where things get really murky is memberof
support. Some systems (e.g. early ownCloud) rely on memberof
support to work out what groups a user is a member of without having to query the LDAP database twice. Often memberof
only works for one of the attributes and then only after heavily tweaking the LDAP config.