0

I have sssd installed on a server to use Active Directory accounts and can connect, but am seeing that the UIDs for AD users are very wrong (eg. an AD users posix UID is set to 1234, but I see something big like 987654987654 on the sssd machine). The /etc/sssd/sssd.conf file looks like...

[sssd]
domains = ucera.local
config_file_version = 2
services = nss, pam

[domain/ucera.local]
ad_domain = co.local
krb5_realm = CO.LOCAL
realmd_tags = manages-system joined-with-samba
cache_credentials = False
id_provider = ad
krb5_store_password_if_offline = False
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%u
access_provider = ad
default_domain_suffix = co.local

Any ideas why this could be happening? Any debugging advice?


I also notice that I sometimes have problems logging into the machine with AD users. Eg. when trying to ssh into server I get password denied, but when ssh in as root then su into that user and exit, I can then ssh into server directly as that AD user (like the server does not realize it has that user until I "remind" it by su'ing into as that user) (not sure if related).

0

Based on the article found here, seem to have fixed the problem, sssd.conf file now looks like...

[sssd]
domains = ucera.local
config_file_version = 2
services = nss, pam

[domain/ucera.local]
ad_domain = co.local
krb5_realm = CO.LOCAL
realmd_tags = manages-system joined-with-samba
cache_credentials = False
id_provider = ad
krb5_store_password_if_offline = False
default_shell = /bin/bash
ldap_id_mapping = False
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber
ldap_group_gid_number = gidNumber
use_fully_qualified_names = False
fallback_homedir = /home/%u
access_provider = ad
default_domain_suffix = co.local

Changes:

  1. ldap_id_mapping = False is, I think, the main fix which lets the AD posix IDs be used rather than calculating based on the AD users objectSID attribute
  2. I also added the ldap_..._...id_number = ... settings and set it to the corresponding attribute fields in AD for the users. After doing part (1), the UIDs on the machine were unchanged. Comparing to other sssd-using servers that did not have this problem, the only difference in sssd.conf was change (1). My though is that the other machines already had ldap_id_mapping = False, so when AD users signed in for the first time on those machines, they got thier AD posix UIDs automatically. On this messed up server, the UIDs had already been wrongly set, so needed to explicitly force the use of uidNumber and gidNumber AD attributes.

Then restart the sssd service.


Not very experienced with AD and SSSD, so if I'm misinterpreting anything, do leave a comment to let me know.

| improve this answer | |

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.