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.
Bug 1287209 - [RFE] Allow short usernames in trust setups
Summary: [RFE] Allow short usernames in trust setups
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.2
Hardware: All
OS: Linux
medium
low
Target Milestone: rc
: ---
Assignee: SSSD Maintainers
QA Contact: Steeve Goveas
Aneta Šteflová Petrová
URL:
Whiteboard:
: 1328069 (view as bug list)
Depends On:
Blocks: 1361329
TreeView+ depends on / blocked
 
Reported: 2015-12-01 18:47 UTC by Sean Elble
Modified: 2021-03-11 14:26 UTC (History)
13 users (show)

Fixed In Version: sssd-1.14.0-1.el7
Doc Type: Enhancement
Doc Text:
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`.
Clone Of:
: 1361329 (view as bug list)
Environment:
Last Closed: 2016-11-04 07:13:00 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
sssd.conf (1.36 KB, text/plain)
2015-12-01 18:47 UTC, Sean Elble 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 3879 0 None closed full_name_format and default_domain_suffix breaks supplemental AD trust groups 2021-02-15 15:25:09 UTC
Github SSSD sssd issues 3970 0 None closed NSS responder does not lowercase AD external group members 2021-02-15 15:25:09 UTC
Red Hat Product Errata RHEA-2016:2476 0 normal SHIPPED_LIVE sssd bug fix and enhancement update 2016-11-03 14:08:11 UTC

Description Sean Elble 2015-12-01 18:47:06 UTC 
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.
Comment 1 Lukas Slebodnik 2015-12-02 07:14:24 UTC 
> 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".?
Comment 2 Sean Elble 2015-12-02 13:04:02 UTC 
(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.
Comment 3 Jakub Hrozek 2015-12-10 10:55:40 UTC 
Upstream ticket:
https://fedorahosted.org/sssd/ticket/2838
Comment 4 Jakub Hrozek 2015-12-10 10:58:38 UTC 
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.
Comment 5 Jakub Hrozek 2016-01-11 15:50:41 UTC 
We already have a WIP branch with the database changes, so this should find its way to 7.3..
Comment 7 Jakub Hrozek 2016-07-07 10:52:16 UTC 
Fixed in e6b6b9f..c88b63b
Comment 10 Jakub Hrozek 2016-07-14 08:55:39 UTC 
*** Bug 1328069 has been marked as a duplicate of this bug. ***
Comment 11 Orion Poplawski 2016-07-15 22:32:16 UTC 
sssd 1.14.0 is looking pretty go to me so far with full_name_format=$1.  Thanks!
Comment 12 Jakub Hrozek 2016-09-11 20:39:03 UTC 
Upstream ticket:
https://fedorahosted.org/sssd/ticket/2929
Comment 13 Niranjan Mallapadi Raghavender 2016-09-23 04:48:13 UTC 
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.122.60
Administrator@192.168.122.60's password:
Last login: Thu Sep 22 13:23:57 2016 from gateway
[administrator@client1 ~]$ whoami
administrator

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@client1 ~]$ whoami
administrator
Comment 20 errata-xmlrpc 2016-11-04 07:13:00 UTC 
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
Comment 21 Jakub Hrozek 2017-03-03 13:08:10 UTC 
*** Bug 1328069 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.