6

I'm preparing for an eventual upgrade from CentOS 6 to CentOS 7. Right now, in version 6, we just use LDAP mapped to AD for authentication. This then uses the UID and GID from the Active Directory extension for Unix.

In my experimentation with CentOS 7, I went through the documentation (I think it was from Red Hat) that explained how to join to a domain. The process was mostly straight forward, and mostly works great. However, it doesn't just use the UID and GIDs from AD Unix attributes. It is mapping those IDs to completely different IDs. In AD, users are in the 10000 range. CentOS7 is giving each user UID in the 625000000 range.

So far in my small scale testing (3 boxes) the UID seems to be consistent across them all and that is good. However, when I begin rolling 7 out in production, it will be a gradual upgrade. I won't be upgrading every box at the same time. I'm concerned about issues with users having different UIDs on different boxes. Is there a way I can get CentOS 7 to just use the UIDs and GIDs in the AD Unix attributes?

Here is my smb.conf:

[global]
    workgroup = COMPANY
    client signing = yes
    client use spnego = yes
    kerberos method = secrets and keytab
    log file = /var/log/samba/%m.log
    password server = ad_domaincontroller.company.net
    realm = COMPANY.NET
    security = ads
    server string = Samba Server Version %v
    max log size = 50

And here is my sssd.conf

[sssd]
config_file_version = 2
domains = company.net
services = nss, pam, pac

[nss]
filter_groups = root
filter_users = root

[domain/company.net]
id_provider = ad
ad_server = ad_domiancontroller.company.net
ad_hostname = centos7-22.company.net
auth_provider = ad
chpass_provider = ad
access_provider = ad
ldap_schema = ad
use_fully_qualified_names = False
cache_credentials = true
ldap_access_order = expire
ldap_account_expire_policy = ad
ldap_force_upper_case_realm = true

Edit: I've tried adding ldap_id_mapping = False to sssd.conf, but with that line included, sssd.service will not start. Here is the output:

Sep 29 12:59:55 centos7-22 sssd[32827]: Starting up
Sep 29 12:59:55 centos7-22 sssd[32828]: Starting up
Sep 29 12:59:55 centos7-22 sssd[32831]: Starting up
Sep 29 12:59:55 centos7-22 sssd[32830]: Starting up
Sep 29 12:59:55 centos7-22 sssd[32829]: Starting up
Sep 29 12:59:55 centos7-22 sssd[32832]: Starting up
Sep 29 12:59:56 centos7-22 sssd[be[32833]: Starting up
Sep 29 12:59:56 centos7-22 systemd[1]: sssd.service: control process exited, code=exited status=1
Sep 29 12:59:56 centos7-22 systemd[1]: Failed to start System Security Services Daemon.
-- Subject: Unit sssd.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit sssd.service has failed.
--
-- The result is failed.
Sep 29 12:59:56 centos7-22 systemd[1]: Unit sssd.service entered failed state.
mrwboilers
  • 83
  • 1
  • 2
  • 7
  • In AD users have SIDs which are in the form of S-1-.... (very long). Where are you seeing this IDs in "10000 range"? – gtirloni Sep 26 '14 at 21:07
  • The UID is set in the unix attributes tab in AD Users and Computers. I believe you only have that tab if services for Unix is installed in your domain. – mrwboilers Sep 26 '14 at 21:12

2 Answers2

6

From the man page of sssd-ad:

By default, the AD provider will map UID and GID values from the objectSID parameter in Active Directory. For details on this, see the "ID MAPPING" section below. If you want to disable ID mapping and instead rely on POSIX attributes defined in Active Directory, you should set ldap_id_mapping = False

Andy
  • 1,111
  • 1
  • 7
  • 10
  • Thanks for the reply. I've already tried ldap_id_mapping = False and with that setting in there, sssd won't even start. – mrwboilers Sep 29 '14 at 14:20
  • I can't find much detail as to why it won't start with that setting. This is all I've been able to find: – mrwboilers Sep 29 '14 at 17:06
  • 4
    Ultimately this is the correct answer. I had already tried it, but ldap_id_mapping = False was causing sssd to fail. I found a solution to there here: https://bugzilla.redhat.com/show_bug.cgi?id=1116758. The solution is to remove everything from /var/lib/sss/db/* and then restart sssd. Doing this not only allowed sssd to start, but also it started using the UID/GIDs that I was expecting. – mrwboilers Sep 29 '14 at 17:18
  • That's good to know. Removing those files has solved similar problems for me previously. – Andy Oct 04 '14 at 06:52
  • Better still, use the sss_cache utility -- added benefit; restart not required. – lingfish Jun 12 '15 at 05:24
  • @lingfish that didn't work for me, I needed to delete by hand – martin Jun 30 '15 at 11:34
  • @martin -- odd, sounds like a bug. – lingfish Aug 28 '15 at 08:35
  • delete /var/lib/sss/db/* works for me. thanks @mrwboilers – kholis Feb 03 '17 at 03:15
2

SSSD internally uses IDs as uniqueness attribute and changing UIDs is not supported at the moment.

It is expected and required that the database must be removed if ID allocation changes, as it does if you switch from ID mapping to POSIX information or vice versa. Perhaps it's not documented prominently in manual pages -- feel free to file a bug to improve our documentation. Thank you!

jhrozek
  • 1,370
  • 6
  • 5