HP CIFS Server Administrator Guide Version A.03.01.03 (5900-2006, October 2011)

Winbind provides a library routine, /usr/lib/libnss_winbind.1, that NSS can use to
interface to the winbind daemon to resolve ID mappings.
• User and group ID allocation
When winbind is presented with a Windows SID for which there is no corresponding UID
and GID, winbind generates a UID and GID. Depending on the configuration, winbind
uses one of the following three different algorithms for creating IDs:
◦ Local increment
Winbind default settings will result in ID values based on a simple increment above the
current highest value within a defined range. The pool of values is confined to the local
HP CIFS Server. This solution is limited by the fact that UID and GID values may differ
among multiple HP CIFS Servers within the same Windows domain for the same Windows
user. Also, if the idmap database need to be recreated for any reason, UID and GID
maps could differ from the previous map which can lead to serious security issues (file
ownership may change).
NOTE: You can back up and restore the idmap database to avoid having to recreate
UID and GID maps. The local increment model requires the idmap database to be backed
up frequently.
◦ Idmap rid
The idmap rid solution resolves the potential problems with the local increment algorithm
because winbind provides a unique mapping of Windows SIDs to local UNIX UIDs and
GIDs across multiple HP CIFS Servers. The UIDs and GIDs are generated based on the
RID portion of the Windows SID, the RID is unique within the domain. This solution can
be particularly helpful if there are multiple HP CIFS member servers connected to the
domain and it is useful to have user names and group names with unique IDs across
multiple HP CIFS member servers. However, without the domain portion of the SID, the
idmap rid method is limited by the fact that it is not appropriate for domains that trust
other domains unless you do not require IDs to be resolved from the domain trusts.
You can not migrate the idmap rid model to the local increment or shared
sambaUnixIDPool model because of the way it assigns IDs. This model can be quite useful
if a unique mapping of Windows SIDs to UNIX UIDs and GIDs across multiple member
servers within a domain is needed.
If you are configuring a large number of CIFS member servers, or if it is important to be
able to provide access to Windows trusts, you may want to consider the shared
sambaUnixIDPool method. Using the shared sambaUnixIDPool model reduces the traffic
and load in maintaining similar idmap caches and mapping user and group names of
Windows trusted domains. See the shared sambaUnixIDPool method below for details.
◦ Shared sambaUnixIDPool
When using the shared Samba UNIX ID pool method, you use an LDAP backend to store
user and group identities across multiple servers and domains. Winbind makes use of
a shared sambaUnixIDPool value to increment UID and GID values across all HP CIFS
member servers sharing the LDAP backend. As with the local increment solution, if the
idmap database needs to be recreated for any reason, UID and GID maps could differ
from the previous map which could lead to serious security issues (file ownership may
change).
The user and group data should be replicated and/or backed up using this model. The
disadvantage of using this model is that it is more complicated to configure. However,
the shared sambaUnixIDPool method provides several significant benefits described below
to customers who have multiple CIFS member servers connected to a Windows Active
Directory Server (ADS) environment.
98 Winbind support