Hide Forgot
SSSD now supports using `full_name_format=%1$s` to set the output name of AD trusted users to a shortname Previously, in trust setups, certain System Security Services Daemon (SSSD) features required using the default value for the `full_name_format` option in the `/etc/sssd/sssd.conf` file. Using `full_name_format=%1$s` to set the output format of trusted Active Directory (AD) users to a shortname broke other functionality. This update decouples the internal representation of a user name from the output format. You can now use `full_name_format=%1$s` without breaking other SSSD functionality. Note that the input name must still be qualified, except for when the `default_domain_suffix` option is used in `sssd.conf`.
Created attachment 1100987 [details] sssd.conf Description of problem: In updating one of our RHEL 7 patch testing systems from 7.1 to 7.2, we noticed that SSSD started to behave differently with regards to what the user names appear to be with default_domain_suffix set. Prior to 7.2, we'd have default_domain_suffix set, and users would appear at the OS level (in the output of whoami, w, last, etc.). After the upgrade, we're now seeing the value of default_domain_suffix appended to it: [selble@dqs@nw-rhel7patch-d01 ~]$ whoami selble@dqs Version-Release number of selected component (if applicable): Red Hat Enterprise Linux Server release 7.2 (Maipo) Name : sssd-common Version : 1.13.0 Release : 40.el7 Architecture: x86_64 Install Date: Tue 01 Dec 2015 12:45:22 AM EST Group : Applications/System Size : 3310835 License : GPLv3+ Signature : RSA/SHA256, Thu 22 Oct 2015 10:11:13 AM EDT, Key ID 199e2f91fd431d51 Source RPM : sssd-1.13.0-40.el7.src.rpm Build Date : Wed 14 Oct 2015 07:49:12 AM EDT Build Host : x86-036.build.eng.bos.redhat.com Relocations : (not relocatable) Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> Vendor : Red Hat, Inc. URL : http://fedorahosted.org/sssd/ Summary : Common files for the SSSD Description : Common files for the SSSD. The common package includes all the files needed to run a particular back end, however, the back ends are packaged in separate subpackages such as sssd-ldap. How reproducible: Very easy to do with a RHEL 7.1 and a RHEL 7.2 system Steps to Reproduce: 1. Update RHEL 7.1 system to RHEL 7.2 with default_domain_suffix set to your sole SSSD domain 2. Observe that logins now have the suffix applied to it 3. On RHEL 7.1 system with the same configuration, observe that logins show just the user name 4. Remove/comment out default_domain_suffix from /etc/sssd/sssd.conf and restart sssd. Observe that logins no longer have the suffix applied. Actual results: [selble@dqs@nw-rhel7patch-d01 ~]$ whoami selble@dqs Expected results: [selble@nw-rhel7patch-d01 ~]$ whoami selble Additional info: I didn't see this in the release notes for RHEL 7.2, nor did I see it at a quick glance when reviewing the SSSD 1.13 release notes (since RHEL 7.2 rebased upon that version from 1.12 in RHEL 7.1). I realize that this is somewhat documented as a change, in that with the latest version, it is documented that setting default_domain_suffix to anything is not compatible with setting use_fully_qualified_names to false (and I stress "somewhat", since this is not listed in the release notes, nor does sssd error out when you have both parameters set). I also fail to see why the two parameters are mutually exclusive, though I do acknowledge given our configuration, it's somewhat meaningless to define a default domain. Our interest here lies in situations further down the road when we may have multiple domains for migratory purposes.
> Our interest here lies in situations further down the road when we may have multiple domains for migratory purposes. If you would like to use more domains in future then you will need to use fully qualified names anyway. You might still need to use default_domain_suffix. Could you describe how would you like to use more domains or what do you mean by "migratory purposes".?
(In reply to Lukas Slebodnik from comment #1) > If you would like to use more domains in future then you will need to use > fully qualified names anyway. You might still need to use > default_domain_suffix. The logic I see in requiring the use of fully qualified names is to prevent collisions between domains, but if one were willing to accept the risk of collisions, is there any reason not to permit it? The other side of it is I'm not sure I understand why the change in SSSD was made in the first place. The man page doesn't seem to indicate that the two options were mutually exclusive before 1.13, so perhaps the better question is why was the change made? > > Could you describe how would you like to use more domains or what do you > mean by > "migratory purposes".? This was actually brought up my a colleague of mine, and the situation we imagine is configuring an additional domain within SSSD that would point to an AD domain, while preserving the existing domain. Users would continue to use the existing domain as a default (i.e., without having to fully qualify their user name), while we could test out the changeover to the "new" (later to be primary/default) domain.
Upstream ticket: https://fedorahosted.org/sssd/ticket/2838
I would say at the moment it is expected that the qualified name shows up. Due to the unfortunate fact that the full_name_format also controls how the FQDN is stored in the cache and the reliance of the trust components on parsing name in the format of name@domain, it's not possible to use full_name_format=$1 to set the short name only. We have a patchset on review that changes the cache layout which would allow this use-case but it wouldn't land sooner than 7.3, sorry.
We already have a WIP branch with the database changes, so this should find its way to 7.3..
Fixed in e6b6b9f..c88b63b
*** Bug 1328069 has been marked as a duplicate of this bug. ***
sssd 1.14.0 is looking pretty go to me so far with full_name_format=$1. Thanks!
Upstream ticket: https://fedorahosted.org/sssd/ticket/2929
Versions: ========= sssd-ad-1.14.0-41.el7.x86_64 sssd-proxy-1.14.0-41.el7.x86_64 sssd-krb5-common-1.14.0-41.el7.x86_64 sssd-ldap-1.14.0-41.el7.x86_64 python-sssdconfig-1.14.0-41.el7.noarch sssd-common-1.14.0-41.el7.x86_64 sssd-krb5-1.14.0-41.el7.x86_64 sssd-ipa-1.14.0-41.el7.x86_64 sssd-client-1.14.0-41.el7.x86_64 sssd-common-pac-1.14.0-41.el7.x86_64 sssd-1.14.0-41.el7.x86_64 1. Configure RHEL7.3 client to authenticate to AD using sssd (ad provider) [sssd] domains = centaur.test config_file_version = 2 services = nss, pam [domain/centaur.test] ad_domain = centaur.test krb5_realm = CENTAUR.TEST cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%u@%d access_provider = ad debug_level = 9 2. Login as AD user [mniranja@mniranja tdb]$ ssh Administrator\@centaur.test@192.168.122.60 Administrator@centaur.test@192.168.122.60's password: Last login: Thu Sep 22 13:23:57 2016 from gateway [administrator@centaur.test@client1 ~]$ whoami administrator@centaur.test 3. Modify sssd.conf as below to add the line "full_name_format=%1$s" to the domain section [sssd] domains = centaur.test config_file_version = 2 services = nss, pam [domain/centaur.test] ad_domain = centaur.test krb5_realm = CENTAUR.TEST cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%u@%d access_provider = ad debug_level = 9 full_name_format=%1$s 4. Restart sssd 5. Now the Domain part is removed from whoami command [administrator@centaur.test@client1 ~]$ whoami administrator
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-2476.html