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.
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/sssd/ticket/2402
With the current IFP code, a fully qualified lookup doesn't work:
{{{
dbus-send --print-reply \
--system \
--dest=org.freedesktop.sssd.infopipe \
/org/freedesktop/sssd/infopipe \
org.freedesktop.sssd.infopipe.GetUserGroups string:user@domain
}}}
There is already a patch on the list, this ticket is mostly a tracking one.
If it's enough to test with dbus-send, then the following command invocation should do the trick:
dbus-send --print-reply \
--system \
--dest=org.freedesktop.sssd.infopipe \
/org/freedesktop/sssd/infopipe \
org.freedesktop.sssd.infopipe.GetUserGroups string:user@domain
The user visible part of the problem would appear if someone configured their sssd.conf with:
use_fully_qualified_names=yes
then sssd requires you to use logins in the form of "user@domain", not just "user" and that's where we fail.
Comment 7Jan Pazdziora (Red Hat)
2014-08-11 14:04:11 UTC
(In reply to Jakub Hrozek from comment #6)
>
> The user visible part of the problem would appear if someone configured
> their sssd.conf with:
> use_fully_qualified_names=yes
>
> then sssd requires you to use logins in the form of "user@domain", not just
> "user" and that's where we fail.
Even without use_fully_qualified_names=yes, would for example KrbLocalUserMapping Off in mod_auth_kerb configuration also demonstrate the issue?
Comment 8Jan Pazdziora (Red Hat)
2014-08-11 14:12:04 UTC
Is the reproducer supposed to be visible with GetUserAttr as well? I can't seem to get the faulty behaviour with sssd-dbus-1.12.0-1.el7.x86_64 and GetUserAttr.
(In reply to Jan Pazdziora from comment #8)
> Is the reproducer supposed to be visible with GetUserAttr as well? I can't
> seem to get the faulty behaviour with sssd-dbus-1.12.0-1.el7.x86_64 and
> GetUserAttr.
Yes, the two methods share the same common (broken) code.
Comment 10Jan Pazdziora (Red Hat)
2014-08-12 08:36:37 UTC
Why does the following seem to work then?
# rpm -q sssd-dbus
sssd-dbus-1.12.0-1.el7.x86_64
# dbus-send --print-reply \
> --system \
> --dest=org.freedesktop.sssd.infopipe \
> /org/freedesktop/sssd/infopipe \
> org.freedesktop.sssd.infopipe.GetUserAttr string:bob23392 array:string:mail
method return sender=:1.19 -> dest=:1.83 reply_serial=2
array [
dict entry(
string "mail"
variant array [
string "bob23392"
]
)
]
Chances are bob is already cached with some other nsswitch call, maybe with getpwnam or id. The lookups works fine if the user was already cached, it's "just" not able to request a non-existant user from the back end.
Can you try:
service sssd stop
rm -f /var/lib/sss/db/cache_*
service sssd start
dbus-send XXX
Comment 12Jan Pazdziora (Red Hat)
2014-08-12 12:18:05 UTC
(In reply to Jakub Hrozek from comment #11)
> Chances are bob is already cached with some other nsswitch call, maybe with
> getpwnam or id. The lookups works fine if the user was already cached, it's
> "just" not able to request a non-existant user from the back end.
>
> Can you try:
>
> service sssd stop
> rm -f /var/lib/sss/db/cache_*
> service sssd start
> dbus-send XXX
Confirming. Thank you.
By the way, when after that cleanup I first try to get GetUserAttr for the FQDN username, it fails (Error org.freedesktop.DBus.Error.Failed: No such user), and the subsequent GetUserAttr for local username fails with the same error message.
Comment 16Kaushik Banerjee
2014-09-10 11:49:50 UTC
Marking the bug verified SanityOnly with version 1.11.6-29. Existing automation runs passes.
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.
http://rhn.redhat.com/errata/RHBA-2014-1375.html