The Geek Diary

Windows Active Directory Account Shows Inconsistent UID/GID In Different Linux SSSD Clients (CentOS/RHEL)

by

The Problem

The id command shows different UID and GID on different sssd servers for the same Windows Active Directory user. After purging the sssd cache by sss_cache, the UID and GID are still different.

1. Output from one server:

# id ad_test_user
uid=[UID](ad_test_user) gid=[GID](ad_test_group) groups=[GID](ad_test_group2),[GID](ad_test_group)
# sss_cache -u ad_test_user
# id ad_test_user
uid=[UID](ad_test_user) gid=[GID](ad_test_group) groups=[GID](ad_test_group2),[GID](ad_test_group)

2. Output from another server:

# id ad_test_user
uid=[UID](ad_test_user) gid=[GID](ad_test_group) groups=[GID](ad_test_groups),[GID](ad_test_group3),[GID](ad_test_group4),[GID](ad_test_group5), [GID](ad_test_group2),[GID](ad_test_group)
# sss_cache -u ad_test_user
# id ad_test_user
uid=[UID](ad_test_user) gid=[GID](ad_test_group) groups=[GID](ad_test_groups),[GID](ad_test_group3),[GID](ad_test_group4),[GID](ad_test_group5), [GID](ad_test_group2),[GID](ad_test_group)

Possible impacts to Linux server: AD user cannot log into Linux

# su - ad_test_user
Last login: Fri Sep 11 11:11:11 COT 2015 from 10.10.xx.xx on pts/1
Last failed login: Tue Mar 13 13:13:13 COT 2015 from 10.10.10.2 on ssh:hostname
There were 1 failed login attempts since the last successful login.
su: warning: cannot change directory to /home/ad_test_user: Permission denied
id: cannot find name for group ID [GID]
-bash: /home/ad_test_user/.bash_profile: Permission denied
-bash-4.2$

The Solution

Linux user’s UID and GID are coming from Windows AD SID. The sssd will not change it. The ID-mapping feature allows sssd to act as a client of Active Directory without requiring administrators to extend user attributes to support POSIX attributes for user and group identifiers.

Active Directory provides an objectSID for every user and group object in the directory. This objectSID can be broken up into components that represent the Active Directory domain identity and the relative identifier (RID) of the user or group object. The sssd ID-mapping algorithm takes a range of available UID’s and divides it into equally-sized component sections – called “slices“-. Each slice represents the space available to an Active Directory domain.

When a user or group entry for a particular domain is encountered for the first time, the sssd(8) allocates one of the available slices for that domain. In order to make this slice-assignment repeatable on different client machines, the following algorithm is used: the SID string is passed through the murmurhash3 algorithm to convert it to a 32-bit hashed value. Then take the modulus of this value with the total number of available slices to pick the slice.

Note: It is possible to encounter collisions in the hash and subsequent modulus. In these situations, the next available slice is used, but it may not be possible to reproduce the same exact set of slices on other machines since the order that they are encountered will determine their slice. In this situation, it is recommended to either switch to using explicit POSIX attributes in Active Directory (disabling ID-mapping) or configure a default domain to guarantee that at least one is always consistent. See “Configuration” for details.

When ID-mapping is enabled in sssd(8), the uidNumber and gidNumber attributes are ignored. This is to avoid the possibility of conflicts between automatically-assigned and manually-assigned values. If you need to use manually-assigned values, ALL values must be manually-assigned.

Note: the changing the ID mapping related configuration options will cause user and group IDs to change. At the moment, sssd(8) does not support changing IDs, so the sssd database must be removed. Because cached passwords are also stored in the database, removing the database should only be performed while the authentication servers are reachable, otherwise, users might get locked out. In order to cache the password, an authentication must be performed.

The sssd.conf file on Linux clients should be consistent. Especially following two parameters must be consistent in all sssd.conf because they affect the sssd ID-mapping algorithm:

1. ldap_idmap_default_domain_sid (string)
Specify the domain SID of the default domain. This will guarantee that this domain will always be assigned to slice zero in the ID map, bypassing the murmurhash algorithm described above.
Default: not set

2. ldap_idmap_default_domain (string)
Specify the name of the default domain.
Default: not set

You May Also Like