On Thu, Oct 18, 2012 at 01:43:30PM +0000, Joshua C. Endries wrote:
Hi Jakub,
Thanks for the response! I'm using Outlook so the quoting is manual, sorry for that.
> Yep, pam_sss claims it doesn't know the user.
>
> Is "sss" included on the "passwd" and "group" lines of
/etc/nsswitch.conf?
So does this mean that sssd is talking to PAM, which is then talking to NSS? Yes,
"sss" is in nsswitch.conf:
Yes, pretty much. The PAM responder of the SSSD depends on the user entry
being available via the SSSD.
passwd: files sss
shadow: files
group: files sss
> Does "getent passwd -s sss jce54" work?
Nope. I tested this after Googling, and it just returns without any output. IIRC, the
return code was 2, but I'd have to re-test it (which means dismantling the working
auth, starting my sessions, re-enabling sssd)...
OK, this seems to be the problem. The return code 2 would be expected as
it means ENOENT (No such file or directory).
Let's try to get to the root of the problem:
1. can you try raising the debug_level of the [nss] responder and
also the domain? Put:
debug_level = 7
into the [nss] and [domain/DEFAULT] sections, restart the SSSD and
re-run getent passwd -s sss jce54. Can you then paste the contents
of /var/log/sssd/sssd_nss.log and /var/log/sssd/sssd_DEFAULT.log ?
2. If there is nothing relevant especially in the sssd_nss.log, can
you try checking if getent opens the NSS module at all? Run:
strace -e open getent passwd -s sss jce54
3. Are there any AVC denials?