Bug 1736110

In Apache error log I see:
[Thu Aug 01 15:01:47.605707 2019] [lookup_identity:error] [pid 88999] [client 192.168.45.4:42115] Error dbus calling GetUserAttr(first.last, name): org.freedesktop.DBus.Error.Failed: No such user\n
happens for user where:
sAMAccountName = first.last
uid = firstl

Now (interestingly enough) both commands:
# sssctl user-checks first.last
# sssctl user-checks firstl

correctly displays the identity of the user in question

Ok, as test with dbus-send fails (unable to detect user first.last) I guess it is rather a bug in SSSD, not sure.
What is important here that REMOTE_USER env variable usually contains the Kerberos User Principal.
Kerberos identity != Unix identity, see above.

Update: not sAMAccountName, but userPrincipalName attribute (which is by default same as sAMAccountName) is not causing this.
if userPrincipalName != uid, then mod_lookup_identity fails to resolve the authenticated user.

Thank you for the bug report. I can confirm that it is a bug in SSSD not in mod_lookup_identity.

The problem is that SSSD D-Bus method GetUserAttr parses the username on its own, instead of leaving it on underlying cache_req interface and therefore it will not try to search by principal name.

Upstream ticket:
https://pagure.io/SSSD/sssd/issue/4065

Upstream PR:
https://github.com/SSSD/sssd/pull/868

Ondřej, I can build you a test build if you want on. Just tell me which version should I build.

I am currently running sssd-1.16.2-13.el7_6.8.x86_64
but any version suitable for RHEL-7  would do.
Thanks!

I am bit worried about the fix implementation.
Imagine situation:
sssd.conf:
[sssd]
  ...
  domains = example.com

[domain/example.com]
  ...
  id_provider = ad
  ldap_user_name = uid # Let's honor RFC2307, but if we use sAMAccountName, it would be the same situation

Now, let's have 2 users:
A:
  UPN = user1
  uid = usrlinux

B:
  UPN = user2
  uid = user1

Now, which result is "sssctl user-checks user1" going to return?
I think the Dbus API (by a bare minimum) needs to be extended by some other function like GetUserByUPN or something like that.

Or am I missing something?

SSSD first looks up user by username (uid in your case), if it is not found and it is fully qualified name, it will try to search by UPN. So in your example, it will return uid=user1.

Here is the test build: https://pbrezina.fedorapeople.org/scratch/1736110/

(In reply to Pavel Březina from comment #12)
> SSSD first looks up user by username (uid in your case), if it is not found
> and it is fully qualified name, it will try to search by UPN. So in your
> example, it will return uid=user1.

Ok, that means that if we hit a situation as per the example above (and the "A" authenticates via mod_auth_gssapi for example), then the mod_lookup_identity might return wrong identity (i.e. user "B") - correct?

Yes. Sumit, is there anything we can do about it?

Hi,

I think currently there is no way other than choosing the LDAP attributes so that there is no such conflict. A GetUserByUPN as suggested would help here, but it should not be used by mod_auth_identity but better by SSSD's localauth plugin for MIT Kerberos so that mod_auth_gssapi can properly use 'GssapiLocalName on' to translate the principal to a local name. I think it would be worth to track such RFE in a separate ticket.

Btw, I think there will be no issue with AD because even as in the example the UPN is set to 'user1' the canonical principal in the Kerberos ticket and hence the one see by mod_auth_gssapi should be the one based on sAMAccountName 'usrlinux'.

bye,
Sumit

Phew, that's weird, but I confirm that changing UPN attribute of the user has no effect to the Kerberos tickets generated by AD - they are still based on (as per the Sumit's comment above) the sAMAccountName.
If it is really true, then:
1. I am lucky because it does not affect my business (we have uid == sAMAccountName for real user accounts)
2. I still think the issue outlined here (i.e. situations where uid != sAMAccountName && RFC2307 being used) should be addressed somehow, but if you don't want to fix it, I am fine for this bug to be closed as won't fix

Ondrej

Hi,

good to hear that due to Kerberos canonicalization helps to get around the issue.

Nevertheless we should use this ticket to track Pavel's fix. Additionally it would be nice if you can open a RFE to add the 'GetUserByUPN' functionality.

bye,
Sumit

* `master`
    * 18611d70e2916138103a099d45861252d6323366 - ifp: let cache_req parse input name so it can fallback to upn search

* `sssd-1-16`
    * cc7b9366fe7969edbc5694c6b6557d49567abb0d - ifp: call tevent_req_post in case of error in ifp_user_get_attr_send
    * c097e2b913f0ca7091bc1f9aa95af8c987bc7e7a - ifp: let cache_req parse input name so it can fallback to upn search

Reproduce with 
[root@ci-vm-10-0-154-131 ~]# rpm -qa sssd
sssd-1.16.4-37.el7_8.3.x86_64

1. Configure sssd with AD

2. Set  UPN using the following command on the AD server
Set-ADUser -UserPrincipalName abc -Identity adtestuser1

2. Run 
[root@ci-vm-10-0-154-131 ~]# dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserAttr string:abc array:string:name
Error org.freedesktop.DBus.Error.Failed: Failed to read user attribute

Update sssd to latest,

[root@ci-vm-10-0-154-131 ~]# rpm -qa sssd
sssd-1.16.5-7.el7.x86_64

3. Run the command again

[root@ci-vm-10-0-154-131 ~]#  dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserAttr string:abc array:string:name
method return time=1590666131.469439 sender=:1.138 -> destination=:1.137 serial=5 reply_serial=2
   array [
      dict entry(
         string "name"
         variant             array [
               string "adtestuser1"
            ]
      )
   ]

Username found in after upgrade,
thus from above marking this as verified.

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 (sssd bug fix and enhancement update), 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://access.redhat.com/errata/RHBA-2020:3904