Bug 1408294

Note that we have a server still running RHEL 7.1, and it isn't having this issue.

Also, it's always the same user.

I'm sorry, but this bug report doesn't contain any technical details, so it's impossible to help you without providing them.

Please follow https://fedorahosted.org/sssd/wiki/Reporting_sssd_bugs and include logs and ideally steps to reproduce the issue you're seeing.

On a more general level, bugzilla is not a support forum, but an issue tracker.

I'm not able to provide logs, due to security restrictions. The best I can do is tell you what's in them.

Running sssd in the forground with debug level 7 I get this when trying to login as user myuser:

'myuser' matched without domain, user is myuser
Requesting info for [myuser] from [<ALL>]
Requesting info for [myuser]
getpwnam call returned more than one result !?!

Then sssd exits.

And yet this users only exists once in the IPA LDAP directory, and there's no local user with this name. This started happening immediately after reinstalling ipa client on every host in our network, just before which the sssd package was updated. No issue before that. No changes to the IPA directory, other than migrating it to a new server. So this does appear to be a bug. SSSD didn't behave this way before. It may be a bug with IPA, though.

"getent passwd myuser" returns nothing, but the command works for other users. 

I tried wiping the cache:

sss_cache -E

But that didn't help. There are some users that have admin accounts, and the admin accounts have the same email address set. I'm wondering if that's has something to do with it.

Again, this issue only occurs on hosts that have been upgraded to RHEL 7.3.

In fact since RHEL-7.3 SSSD supports login by email, but I doubt that this causes the issue here, because the email is only checked if the search by user name didn't return a result and at the login prompt a fully qualified name, i.e. a name with an '@' sign in it, was given.

Nevertheless the cache might get corrupted during the update. 'sss_cache -E' only invalidates the entries but does not remove them. So I would recommend to re-try with an empty cache. For this please stop SSSD, move the /var/lib/sss/db/cache_* file to some other directory and restart SSSD. You can remove /var/lib/sss/db/cache_* completely as well, most information can be read from the server again, only cached password are lost. If it is important for the system to work offline as well all user which should access the system offline must login successfully with the password once if the cache it removed to make sure offline authentication is working for them.

Changing the email address did indeed seem to eliminate the problem. I'll try the method you suggested as well. I'm surprised nobody has run into this already, but perhaps it's unusual for two users to have the same address.

If it is really about the email and you do not want to change the email addresses in LDAP permanently you can set 'ldap_user_email = noSuchAttr' in the [domain/...] section of sssd.conf (see man sssd-ldap for details). This will tell SSSD to not read the email attribute from the server.

(In reply to David Jones from comment #7)
> but perhaps it's unusual for two users to have the same address.
It is a little bit unusual that two different users has the same address.
Could you provide a reason or use-case?

As I said before, administrators have a separate user account for doing admin work. There was no reason to anticipate that giving both accounts the same email address would cause a problem. It's not a required attribute, and you're allowed to list more than one of them under contact info. 

Anyways, it doesn't matter in our case, as email addresses are all managed in postfix. So I removed the redundant addresses, which eliminated the problem. I suppose it does effect LDAP address lookup in Thunderbird, though. 

It does make the software rather fragile, and so, in my opinion, is definitely a bug. It's one of those hidden gotchas that is difficult to find information on and wastes a lot of time trying to troubleshoot. I'm not able to provide a patch or anything like that, but at least you know the bug is there now.

SSSD version is 1.14.0-43

Of course it is a bug if sssd crashed.
I just wanted to find a workaround for you and we are glad that removing duplicate email fixed that for you. Thank you very much for the report.

Upstream ticket:
https://fedorahosted.org/sssd/ticket/3293

ack for 7.5 development, but please note that fix might only include a clearer way to debug or spot the issue and an advise to work around it

QE: We're not totally sure what the scope of the fix will be, but testing the fix will require having a server with two accounts sharing the same e-mail address.

Log in as one user and then the other.

Even if the second login fails, there should be a clear indication why it did either in the syslog or the debug logs.

master: 39d6a3b

I wouldn't close this issue until the actual problem is fixed.

(In reply to Orion Poplawski from comment #19)
> I wouldn't close this issue until the actual problem is fixed.

I'm fine with opening a new bugzilla to track the actual solution.

(In reply to Jakub Hrozek from comment #20)
> (In reply to Orion Poplawski from comment #19)
> > I wouldn't close this issue until the actual problem is fixed.
> 
> I'm fine with opening a new bugzilla to track the actual solution.

https://pagure.io/SSSD/sssd/issue/3607

Verified on:

ipa-server-4.5.4-7.el7.x86_64
sssd-1.16.0-13.el7.x86_64

Created attachment 1382258 [details]
verification_steps

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://access.redhat.com/errata/RHEA-2018:0929