Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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.
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.
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