Bug 1364559

There appear to be no log entries referring to authentication failures.  All of the files under /var/log/sssd/ are 0 bites.

journalctl -u sssd just shows the service starting and stopping that that's it.

I guess I need to investigate how to up the logging level and see if that helps.

Here are some log entries for sshd that I found in the journal.  I substituted the literal string values for hostname, domainname, and ipaddress with {datatype} entries:

Aug 05 11:28:24 {hostname}.{domanname} sshd[18144]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost={ipaddress} user=b22r163
Aug 05 11:28:24 {hostname}.{domanname} audit[18144]: USER_AUTH pid=18144 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_succeed_if,pam_sss acct="b22r163" exe="/usr/sbin/sshd" hostname={ipaddress} addr={ipaddress} terminal=ssh res=success'
Aug 05 11:28:24 {hostname}.{domanname} sshd[18144]: pam_sss(sshd:account): Access denied for user b22r163: 4 (System error)
Aug 05 11:28:24 {hostname}.{domanname} audit[18144]: USER_ACCT pid=18144 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=? acct="b22r163" exe="/usr/sbin/sshd" hostname={ipaddress} addr={ipaddress} terminal=ssh res=failed'
Aug 05 11:28:24 {hostname}.{domanname} sshd[18144]: Failed password for b22r163 from {ipaddress} port 58438 ssh2
Aug 05 11:28:24 {hostname}.{domanname} audit[18144]: USER_AUTH pid=18144 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=password acct="b22r163" exe="/usr/sbin/sshd" hostname=? addr={ipaddress} terminal=ssh res=failed'
Aug 05 11:28:24 {hostname}.{domanname} sshd[18144]: fatal: Access denied for user b22r163 by PAM account configuration [preauth]
Aug 05 11:28:24 {hostname}.{domanname} audit[18144]: USER_LOGIN pid=18144 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="b22r163" exe="/usr/sbin/sshd" hostname=? addr={ipaddress} terminal=ssh res=failed'

Hello Scott,

to turn on debugging on highest level open /etc/sssd/sssd.conf
and put option

debug_level = 10

to the section you want to debug. In your case the domain section, that has format [domain/DOMAIN_NAME] and pam section [pam]. Then restart sssd

$ systemctl restart sssd
or
$ service sssd restart

Try to login and you will see debug logs in /var/log/sssd/

For more information see manual page for sssd.conf.
$ man sssd.conf

HTH

Michal

I see the following statement on one of the sssd troubleshooting pages: (https://fedorahosted.org/sssd/wiki/Troubleshooting)

"Where XXXXXX is a number larger than 200000, then check the ldap_idmap_range_size option. You'll likely want to increase its value. Keep in mind the largest ID value on a POSIX system is 232."

...but it doesn't say what file to put that in (/etc/sssd/sssd.conf) nor the exact syntax it takes.  I'll give it a try and see what happens.

Michal Zidek, thanks for the info.  I did that... and now it is logging a ton... and I see my AD username shown in several of the logs... but nothing is standing out as an error.  If someone could give me some guidance on what type of information from the logs might be useful for the bug report, I will provide such.

Could you attach domain log file (+krb5_child.log)?

Hmmm, according to the sssd-ad(5) man page in the "Advanced Configuration" section there are a number of ldap_idmap_* values and it looks like the defaults should be good enough even for the large UID/GID I mentioned above... but I'm not really familiar with the specific details so perhaps I'm wrong.

Created attachment 1187998 [details]
domain log file

This contains an entry for a failed ssh login.

Created attachment 1188000 [details]
krb2_child.log file

Contains at least one ssh login attempt.

I can also try to authenticate via graphical login manager and text console an provide log information with those if there isn't enough information contained in two attached files so far.

According to log file you hit an upstream bug
https://fedorahosted.org/sssd/ticket/2751

(Fri Aug  5 12:14:46 2016) [sssd[be[msu.montana.edu]]] [ad_gpo_cse_done] (0x0400): gpo_guid: {AC2A20AF-CCA9-4F11-AB74-66A62CB5F651}
(Fri Aug  5 12:14:46 2016) [sssd[be[msu.montana.edu]]] [ad_gpo_store_policy_settings] (0x0020): [/var/lib/sss/gpo_cache/msu.montana.edu/Policies/{AC2A20AF-CCA9-4F11-AB74-66A62CB5F651}/Machine/Microsoft/Windows NT/SecEdit/GptTmpl.inf]: ini_config_parse failed [5][Input/output error]
(Fri Aug  5 12:14:46 2016) [sssd[be[msu.montana.edu]]] [ad_gpo_store_policy_settings] (0x0020): Error (5) on line 7: Equal sign is missing.
(Fri Aug  5 12:14:46 2016) [sssd[be[msu.montana.edu]]] [ad_gpo_store_policy_settings] (0x0020): Error encountered: 5.
(Fri Aug  5 12:14:46 2016) [sssd[be[msu.montana.edu]]] [ad_gpo_cse_done] (0x0040): ad_gpo_store_policy_settings failed: [5](Input/output error)
(Fri Aug  5 12:14:46 2016) [sssd[be[msu.montana.edu]]] [ad_gpo_access_done] (0x0040): GPO-based access control failed.
(Fri Aug  5 12:14:46 2016) [sssd[be[msu.montana.edu]]] [be_pam_handler_callback] (0x0100): Backend returned: (3, 4, Input/output error) [Internal Error]
(Fri Aug  5 12:14:46 2016) [sssd[be[msu.montana.edu]]] [be_pam_handler_callback] (0x0100): Sending result [4][msu.montana.edu]
(Fri Aug  5 12:14:46 2016) [sssd[be[msu.montana.edu]]] [be_pam_handler_callback] (0x0100): Sent result [4][msu.montana.edu]

There are few possible solutions
a) If you do not plant to use GPO for access control.
then you can disable it in domain section of sssd.conf
@see man sssd-ad-> ad_gpo_access_control
b) you can edit GPO in Active Directory. The problematic gpo file should contain equal sign (key = value) or you can comment out problematic line (# at the beginning of line.
c) I can backport fix for ticket #2751

We do not have any AD Group Policies specific to Linux systems at the current time so solution a will work for me.  I'll give it a try.

I would expect the fix to land as an sssd update in Fedora at some time in the not too distant future, eh?

Fix "a" is working for me.  Thanks.

Looking at the default permissions on the home directory created for the user who logged in they are:

drwxr-xr-x.  5 b22r163 domain users  4096 Aug  4 13:22 b22r163.edu

Is there a setting somewhere to set the desired permissions because I would like them to be more restrictive.  In the past when I've run into this issue with NIS authentication, I just had a cron job that chowned everything under /home/ (or in this case /students/) to be 700... but yeah that is a very sloppy way to do it.

Secondly, I have a bug filed against oddjob-mkhomedir (https://bugzilla.redhat.com/show_bug.cgi?id=1292617) that is is not copying stuff from /etc/skel/ into the new user's home dir... and a setting for that (copy or not copy) would be very handy.

Those two issues are not directly related to this bug but I thought it didn't hurt to ask since I'm guessing you are probably very familiar with these related packages.

(In reply to Scott Dowdle from comment #13)
> We do not have any AD Group Policies specific to Linux systems at the
> current time so solution a will work for me.  I'll give it a try.
> 
> I would expect the fix to land as an sssd update in Fedora at some time in
> the not too distant future, eh?

I will be part of sssd-1.14.x. Which we plan to release approximately in two weeks.

(In reply to Scott Dowdle from comment #15)
> Looking at the default permissions on the home directory created for the
> user who logged in they are:
> 
> drwxr-xr-x.  5 b22r163 domain users  4096 Aug  4 13:22
> b22r163.edu
> 
sssd neither creates home directories nor changes permissions.

Yeah, the creation and permissions are done by oddjob-mkhomedir and I found a fix for it in https://bugzilla.redhat.com/show_bug.cgi?id=836174 which was... /etc/skel/ was 755 so homedirs were the same.  Changed /etc/skel to the desired 700 and new homedirs have the desired permissions of 700.

(In reply to Scott Dowdle from comment #4)
> I see the following statement on one of the sssd troubleshooting pages:
> (https://fedorahosted.org/sssd/wiki/Troubleshooting)
> 
> "Where XXXXXX is a number larger than 200000, then check the
> ldap_idmap_range_size option. You'll likely want to increase its value. Keep
> in mind the largest ID value on a POSIX system is 232."
> 

I think we should change this sentence in the troubleshooting guide to make sure users don't munge the ranges with new releases that can already extend the ranged on their own.

Lukas/Michal do you agree?

(In reply to Scott Dowdle from comment #18)
> Yeah, the creation and permissions are done by oddjob-mkhomedir and I found
> a fix for it in https://bugzilla.redhat.com/show_bug.cgi?id=836174 which
> was... /etc/skel/ was 755 so homedirs were the same.  Changed /etc/skel to
> the desired 700 and new homedirs have the desired permissions of 700.

Thank you, can we close this bug now?

Sure.