Bug 1378722 - [RFE] Make GETSIDBYNAME and GETORIGBYNAME request aware of UPNs and aliases
Summary: [RFE] Make GETSIDBYNAME and GETORIGBYNAME request aware of UPNs and aliases
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.3
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: SSSD Maintainers
QA Contact: Sudhir Menon
Depends On:
TreeView+ depends on / blocked
Reported: 2016-09-23 08:10 UTC by Jakub Hrozek
Modified: 2020-05-02 18:30 UTC (History)
10 users (show)

Fixed In Version: sssd-1.15.1-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-08-01 09:00:03 UTC
Target Upstream Version:

Attachments (Terms of Use)
Helper to verify ticket for getorigbyname (735 bytes, text/x-csrc)
2017-05-31 14:15 UTC, Sumit Bose
no flags Details

System ID Priority Status Summary Last Updated
Github SSSD sssd issues 4227 None None None 2020-05-02 18:30:12 UTC
Red Hat Product Errata RHEA-2017:2294 normal SHIPPED_LIVE sssd bug fix and enhancement update 2017-08-01 12:39:55 UTC

Description Jakub Hrozek 2016-09-23 08:10:33 UTC
This bug is created as a clone of upstream ticket:

Currently GETSIDBYNAME and GETORIGBYNAME can only handled request with a (fully-qualified) user name but not with UPNs, email addresses or aliases which might have a different domain component.

This can e.g. be seen when trying to add an IPA user-overrride when a UPN is used instead of a user name.
# getent passwd cu1@alt.alt
cu1@ChIlD.ad.devel:*:1296801104:1296801104:c u:/home/ChIlD.ad.devel/cu1:
# ipa idoverrideuser-add "Default Trust View" cu1@alt.alt
ipa: ERROR: cu1@alt.alt: user not found

Comment 1 Jakub Hrozek 2016-10-10 10:37:00 UTC
* master: dcdf292567d50e5cc527766c1944dcf6a8ecacc5

Comment 3 Martin Kosek 2017-05-26 09:39:51 UTC
Please note that Red Hat officially released public RHEL-7.4 Beta this week, as announced here:

The new RHEL-7.4 release includes a lot of new IdM functionality, including this RFE. Highlights can be found in RHEL-7.4 Release Notes, especially in the Authentication & Interoperability chapter:

IdM Engineering team would like to encourage everyone interested in this new functionality (and especially customers or community members requesting it) to try Beta and provide us with your feedback!

Comment 4 Sudhir Menon 2017-05-31 07:05:40 UTC
Tested on RHEL7.4 using


    [root@autohv02 ~]# ipa trust-find
    1 trusts matched
      Realm name: pne.qe
      Domain NetBIOS name: PNE
      Domain Security Identifier: S-1-5-21-2202318585-426110948-4011710778
      Trust type: Active Directory domain
      UPN suffixes: test.qa, pune.in
    Number of entries returned 1
    [root@autohv02 ~]# id aduser20@pne.qe
    uid=1261601533(aduser20@pne.qe) gid=1261601533(aduser20@pne.qe) groups=1261601533(aduser20@pne.qe),1261600513(domain users@pne.qe)
    [root@autohv02 ~]# id aduser20@pune.in
    uid=1261601533(aduser20@pne.qe) gid=1261601533(aduser20@pne.qe) groups=1261601533(aduser20@pne.qe),1261600513(domain users@pne.qe)
    [root@autohv02 ~]# getent passwd aduser20@pune.in
    [root@autohv02 ~]# ipa idoverrideuser-add "Default Trust View" aduser20@pune.in
    Added User ID override "aduser20@pune.in"
      Anchor to override: aduser20@pne.qe
    [root@autohv02 ~]# ipa idoverrideuser-find "Default Trust View"
    1 User ID override matched
      Anchor to override: aduser20@pne.qe
    Number of entries returned 1

Comment 5 Lukas Slebodnik 2017-05-31 07:57:40 UTC
I do not think that previous steps verify the bug. "id user" does not cover operations GETSIDBYNAME or GETORIGBYNAME.

I think we would need to use python binding.

  import pysss_nss_idmap

Comment 6 Lukas Slebodnik 2017-05-31 07:59:06 UTC
you are an author of the patch. Could you confirm my suspicion?
or even better provide better steps to reproduce.

Comment 7 Sumit Bose 2017-05-31 08:28:25 UTC
Yes, the 'id' command uses a different code path in the SSSD nss responder which was already aware of UPNs/emails.

The python bindings are the most easy way to test the getsidbyname and getorigbyname requests.

Comment 8 Sumit Bose 2017-05-31 09:49:20 UTC

[root@ipa-devel-f25 ~]# python
Python 2.7.13 (default, Jan 12 2017, 17:58:54) 
[GCC 6.3.1 20161221 (Red Hat 6.3.1-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pysss_nss_idmap
>>> pysss_nss_idmap.getsidbyname('Administrator@ad.devel')
{'Administrator@ad.devel': {'type': 3, 'sid': u'S-1-5-21-3692237560-1981608775-3610128199-500'}}

Comment 9 Sudhir Menon 2017-05-31 13:38:54 UTC
Tested on RHEL7.4


[root@ibmserver ~]# python
Python 2.7.5 (default, May  3 2017, 07:55:04) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-14)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pysss_nss_idmap
>>> pysss_nss_idmap.getsidbyname('aduser2@pne.qe')
{'aduser2@pne.qe': {'type': 3, 'sid': u'S-1-5-21-2202318585-426110948-4011710778-1539'}}

Search with UPN set for the same trusted AD user.
>>> pysss_nss_idmap.getsidbyname('aduser2@pune.in')
{'aduser2@pune.in': {'type': 3, 'sid': u'S-1-5-21-2202318585-426110948-4011710778-1539'}}

Comment 11 Sumit Bose 2017-05-31 14:15:34 UTC
Created attachment 1283805 [details]
Helper to verify ticket for getorigbyname

Comment 12 Sudhir Menon 2017-05-31 17:53:05 UTC
Getorigbyname also works fine.

[root@ibmserver ~]# ./getorigbyname aduser2@pune.in
User [aduser2@pune.in] found.
[root@ibmserver ~]# ./getorigbyname aduser2@pne.qe
User [aduser2@pne.qe] found.

Marking the bug VERIFIED as per comment 9 and 12.

Comment 13 errata-xmlrpc 2017-08-01 09:00:03 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.


Note You need to log in before you can comment on or make changes to this bug.