HP CIFS Server 3.0k Administrator's Guide version A.02.04

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
110 Winbind Support