Winbind Features

Winbind provides the following features:

Identity resolution via the Name Services Switch (NSS) (as configured in /etc/nsswitch.conf)
The Name Service Switch (NSS) is an HP-UX feature which allows system information such as host names, user names, and group names to be resolved from different sources.
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 between systems for the same Windows user. Also, if the idmap file 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 file to avoid having to recreate UID and GID maps. The local increment model requires the idmap file 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 file 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.
  Advantages
  The advantages of using the shared sambaUnixIDPool method are as follows:
  UIDs and GIDs are unique across all domain member servers that access this LDAP database.
  Native non-winbind users can be authorized using the POSIX objectclass and LDAP PAM module from the same LDAP database.
  The database can be replicated. Replication reduces the likelihood of data loss and provides backup servers if the primary server is unavailable.
  A single LDAP database can provide consistent ID data for a large number of domain member servers and greatly reduces network traffic and the load on domain and trust Domain Controllers.
ID mapping
Winbind creates mappings between given Windows SIDs and corresponding HP-UX UIDs and GIDs. Winbind uses one of the methods described above to create a mapping between HP-UX UIDs/GIDs and Windows SIDs. With a Windows SID, winbind either finds the existing UID and GID map or creates a new map if none currently exits.
Identity storage
Winbind maintains a database where it stores the mappings between HP-UX UIDs and GIDs and Windows SIDs. In the simplest case, winbind maintains the database in a local Trivial Data Base (TDB) file called winbind_idmap.tdb. If the idmap backend parameter in smb.conf has been specified as ldap:ldap://<ldap server name>:[389], then instead of using a local mapping file, winbind maintains the ID mapping data in the Directory Server database. It is important to back up the data often, particularly if you use a solution other than the idmap rid method. Refer to the tdbbackup man page for detailed information about TDB file backup.

Winbind Features

Technical documentation

» Table of Contents

» Glossary

» Index

Advantages