Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1364559 - Can not login with Active Directory accounts
Summary: Can not login with Active Directory accounts
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: sssd
Version: 24
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Jakub Hrozek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-05 17:30 UTC by Scott Dowdle
Modified: 2016-08-07 19:32 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-08-07 19:32:03 UTC


Attachments (Terms of Use)
domain log file (deleted)
2016-08-05 18:32 UTC, Scott Dowdle
no flags Details
krb2_child.log file (deleted)
2016-08-05 18:34 UTC, Scott Dowdle
no flags Details

Description Scott Dowdle 2016-08-05 17:30:47 UTC
Description of problem:

Joined host to Active Directory domain.  getent works just fine... but graphical login (LightDM), console login, and ssh login does not work.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Join host to Active Directory domain with realm command
2. Verify AD authentication functionality with getent passwd {adusername}
3. Try to login via lightdm, ssh, or text console

Actual results:

Steps 1 & 2 work.  Step 3 fails... and I can not authenticate with AD credentials.


Expected results:

I should be able to login with AD credentials.


Additional info:

Here's the output from getent:

# getent passwd b22r163
b22r163:*:608472194:608400513:Dowdle, Scott:/students/b22r163@msu.montana.edu:/bin/bash

I note that the UID and GID are very big... and if that has something to do with the failure and can be overcome with config changes to some subsystem configurations, please let me know.

When trying to login from the console, the words "System error" are shown and the login fails.

When trying to ssh in, it gives the following error:
Connection to {hostname} closed by remote host.
Connection to {hostname} closed.

Comment 1 Scott Dowdle 2016-08-05 17:47:25 UTC
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.

Comment 2 Scott Dowdle 2016-08-05 18:01:05 UTC
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'

Comment 3 Michal Zidek 2016-08-05 18:07:08 UTC
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

Comment 4 Scott Dowdle 2016-08-05 18:11:55 UTC
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.

Comment 5 Scott Dowdle 2016-08-05 18:21:17 UTC
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.

Comment 6 Lukas Slebodnik 2016-08-05 18:27:01 UTC
Could you attach domain log file (+krb5_child.log)?

Comment 7 Scott Dowdle 2016-08-05 18:30:14 UTC
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.

Comment 8 Scott Dowdle 2016-08-05 18:32:22 UTC
Created attachment 1187998 [details]
domain log file

This contains an entry for a failed ssh login.

Comment 9 Scott Dowdle 2016-08-05 18:34:13 UTC
Created attachment 1188000 [details]
krb2_child.log file

Contains at least one ssh login attempt.

Comment 10 Scott Dowdle 2016-08-05 18:35:31 UTC
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.

Comment 11 Lukas Slebodnik 2016-08-05 18:41:56 UTC
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]

Comment 12 Lukas Slebodnik 2016-08-05 18:45:53 UTC
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

Comment 13 Scott Dowdle 2016-08-05 18:58:35 UTC
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?

Comment 14 Scott Dowdle 2016-08-05 19:02:21 UTC
Fix "a" is working for me.  Thanks.

Comment 15 Scott Dowdle 2016-08-05 19:16:43 UTC
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@msu.montana.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.

Comment 16 Lukas Slebodnik 2016-08-05 19:18:02 UTC
(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.

Comment 17 Lukas Slebodnik 2016-08-05 19:19:41 UTC
(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@msu.montana.edu
> 
sssd neither creates home directories nor changes permissions.

Comment 18 Scott Dowdle 2016-08-05 19:49:18 UTC
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.

Comment 19 Jakub Hrozek 2016-08-07 19:19:28 UTC
(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?

Comment 20 Jakub Hrozek 2016-08-07 19:19:51 UTC
(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?

Comment 21 Scott Dowdle 2016-08-07 19:32:03 UTC
Sure.


Note You need to log in before you can comment on or make changes to this bug.