Bug 1287209 - [RFE] Allow short usernames in trust setups
[RFE] Allow short usernames in trust setups
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd (Show other bugs)
7.2
All Linux
medium Severity low
: rc
: ---
Assigned To: SSSD Maintainers
Steeve Goveas
Aneta Šteflová Petrová
: FutureFeature
: 1328069 (view as bug list)
Depends On:
Blocks: 1361329
  Show dependency treegraph
 
Reported: 2015-12-01 13:47 EST by Sean Elble
Modified: 2017-03-03 08:08 EST (History)
13 users (show)

See Also:
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`.
Story Points: ---
Clone Of:
: 1361329 (view as bug list)
Environment:
Last Closed: 2016-11-04 03:13:00 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Sean Elble 2015-12-01 13:47:06 EST
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 02:14:24 EST
> 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 08:04:02 EST
(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 05:55:40 EST
Upstream ticket:
https://fedorahosted.org/sssd/ticket/2838
Comment 4 Jakub Hrozek 2015-12-10 05:58:38 EST
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 10:50:41 EST
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 06:52:16 EDT
Fixed in e6b6b9f..c88b63b
Comment 10 Jakub Hrozek 2016-07-14 04:55:39 EDT
*** Bug 1328069 has been marked as a duplicate of this bug. ***
Comment 11 Orion Poplawski 2016-07-15 18:32:16 EDT
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 16:39:03 EDT
Upstream ticket:
https://fedorahosted.org/sssd/ticket/2929
Comment 13 Niranjan Mallapadi Raghavender 2016-09-23 00:48:13 EDT
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
Comment 20 errata-xmlrpc 2016-11-04 03:13:00 EDT
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 08:08:10 EST
*** 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.