I have the following setting:

  • I have users in two different domains from two different organizations (separated AD installations) with users user@DOMAIN and user@OTHERDOMAIN
  • On the system, these users map to user_d and user_o.
  • For performance (and other reasons), user login to UID mapping, GIDs, and Gecos information are managed in /etc/{passwd,group}.
  • The AD servers are unaware of the mapping of logins to UID and the GIDs.

I am currently using CentOS 7.4 and consequently sssd 1.15.2 to realize this.

I have it almost working (see below for an excerpt of the relevant configuration parts). I can login with user@DOMAIN and locally I am (result of whoami) user_d. However, my uid is set to 10008. Some group assignment is bogus but my groups from /etc/groups is correct.

The output of getent passwd user_d also gives me the correct result from the /etc/passwd file.

It looks like I'm only missing a little piece of the puzzle...

sssd configuration

services = nss, pam
config_file_version = 2
domains = DOMAIN,OTHER

access_provider = ldap
auth_provider = ldap
id_provider = ldap
use_fully_qualified_names = True
full_name_format = %1$s_d

ldap_access_filter = objectClass=person
ldap_tls_reqcert = allow
ldap_schema = ad
ldap_user_object_class = person
ldap_user_name = sAMAccountName
ldap_user_fullname = displayName
ldap_id_mapping = False
ldap_uri = <ldap URI>
ldap_search_base = <search base>
ldap_default_bind_dn = <bind user>
ldap_default_authtok = <bind user password>


auth        required      pam_env.so
auth        required      pam_faildelay.so delay=2000000
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_sss.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     sufficient    pam_sss.so
session     required      pam_unix.so


passwd:     file

s sss
shadow:     files
group:      files
#initgroups: files

#hosts:     db files nisplus nis dns
hosts:      files dns myhostname

# Example - obey only what nisplus tells us...
#services:   nisplus [NOTFOUND=return] files
#networks:   nisplus [NOTFOUND=return] files
#protocols:  nisplus [NOTFOUND=return] files
#rpc:        nisplus [NOTFOUND=return] files
#ethers:     nisplus [NOTFOUND=return] files
#netmasks:   nisplus [NOTFOUND=return] files     

bootparams: nisplus [NOTFOUND=return] files

ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files

netgroup:   nisplus

publickey:  nisplus

automount:  files nisplus
aliases:    files nisplus

The only way to resolve this appears to be the sss_seed and sss_override_user commands.

First, import all users that you want into the SSS cache using sss_seed (e.g., from the existing /etc/passwd file).

Then, override the attributes appropriately using sss_override_user.

Note that the documentation appears to be misleading, you will need one more colon : in the override import file than in /etc/passwd file (just appending one worked fine for me).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.