Информация про одинаковые UID/GID на разных серверах Samba.
Смотрим по слову idmap_rid.
Копия на всякий случай под катом:
Figure 1: A Typical winbind Architecture (click figure for larger view)
Смотрим по слову idmap_rid.
Копия на всякий случай под катом:
Q: What is Samba winbind and how can I use it to let users log on to their UNIX or Linux host with their Windows credentials that are defined in Active Directory (AD)?
Samba winbind, Windows security, Windows Server, Windows access control, UNIX, Linux
A: Samba winbind provides a unified login experience between UNIX or Linux and Windows systems by letting users log on to a UNIX or Linux host by using Windows domain credentials. There are, however, some complexities you need to watch out for when configuring winbind.
Winbind is a service that comes bundled with the free Samba software. Samba is a collection of software that enables UNIX and Linux platforms to access file and print services by using the Server Message Block (SMB) and Common Internet File System (CIFS) network protocols on Windows platforms and to provide file and print services to Windows clients using SMB and CIFS. You can find more information and download Samba from the Samba website.
Figure 1 illustrates winbind architecture. Note in the figure that winbind not only allows a UNIX/Linux user to use a Windows domain for authentication, but it also allows for the UNIX/Linux host to be joined to and authenticate to a Windows domain.
Winbind works against Windows NT 4.0, Windows 2000, Windows Server 2003, and Windows Server 2008 domain controllers (DCs) and domains. Winbind doesn't require changes on the Windows DC side; most changes are UNIX or Linux client-related. The winbind solution is built on the winbind daemon (winbindd), a pluggable authentication module (PAM) called pam_winbind, a Name Service Switch (NSS) module called libnss_winbind, and a database file called winbind_idmap.tdb.
The winbindd code includes a UNIX implementation of Microsoft remote procedure calls (RPCs). Winbindd uses RPCs to authenticate users against a Windows domain, to obtain Windows domain user and group details from a Windows DC, and to change the passwords of Windows accounts.
The pam_winbind module enables users to log on to a UNIX/Linux host with their Windows credentials. Following is an excerpt of a sample PAM configuration file that enables the UNIX/Linux logon process to call on winbind for authenticating a user; in this particular example, pam_unix would reuse the credentials provided by the user if winbind authentication failed:
login auth sufficient pam_winbind.so
login auth required pam_unix.so nullok try_first_pass
The libnss_winbind NSS module enables UNIX/Linux hosts and the services running on these hosts to call on a Windows DC for user password and group naming information. To use the winbind NSS module, you must edit the nsswitch.conf NSS configuration file as follows:
passwd: files winbind
group: files winbind
You can find the nsswitch.conf file in the /etc directory (which also contains other configuration files) on your UNIX/Linux host.
The winbind_idmap.tdb database contains mappings between a Windows user and group names and their corresponding UNIX/Linux User Identifiers (UIDs) and Group Identifiers (GIDs). When a user logs on to a UNIX/Linux host by using a Windows account, the UNIX/Linux host doesn't understand the Windows account format. Also, Windows accounts can't be used to set permissions on UNIX/Linux resources: UNIX/Linux access control settings require UIDs and GIDs. Therefore, winbind automatically creates a Windows user account-to-UNIX/Linux UID mapping for each new Windows user that logs on to a winbind-enabled UNIX/Linux host.
The UIDs winbind uses for the Windows account mappings are defined in the Samba smb.conf configuration file. Administrators can set aside a range of UIDs and GIDs to be used by winbind on a UNIX/Linux host by setting the idmap parameters in the smb.conf Samba configuration file. For example, the following smb.conf entries set aside the UID range 2,000 to 3,000 and the GID range 2,000 to 3,000 for use by winbind:
idmap uid = 2000-3000
idmap gid = 2000-3000
These mappings must be defined on each UNIX/Linux host to which users will log on with Windows credentials. When defining the idmap UID and GID ranges for a host, you must make sure these ranges don't overlap with locally defined UNIX/Linux users or groups.
Also, standard winbind doesn't include a feature to ensure that a Windows user is assigned the same UID on different UNIX/Linux hosts. This limitation explains why idmap can lead to inconsistencies if Windows users are logging on from different UNIX/Linux hosts and accessing shared resources such as, for example, NFS file servers. Because different UNIX/Linux hosts can map different UIDs, whether users can access a particular NFS resource might depend on what UID they use or, in other words, which UNIX/Linux host they use to accesses the resource.
Some winbind implementations provide a solution to this problem based on the idmap_rid smb.conf configuration setting. The idmap_rid setting enables winbind daemons to generate unique UIDs and GIDs across a Windows domain; the uniqueness is based on mapping the Relative Identifier (RID) portion of a Windows SID to a UNIX/Linux UID or GID.
You can find more information about how to set up winbind and its different components in the Samba-HOWTO Collection documentation.
You can also find commercial alternatives to Samba winbind, such as Quest Authentication Services (formerly known as Vintela Authentication Services) and Centrify DirectControl. Both solutions provide centralized Active Directory–based user and machine account management for Windows and UNIX/Linux clients. Compared to Samba winbind, these solutions offer much easier deployment and more configuration options, but those expanded choices obviously come at a price.
