Bug 1429843 - sssd-1.15.0-4 does not allow system login using KRB password
Summary: sssd-1.15.0-4 does not allow system login using KRB password
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: sssd
Version: 30
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Michal Zidek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-03-07 09:37 UTC by Vít Ondruch
Modified: 2019-02-28 08:09 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)

Description Vít Ondruch 2017-03-07 09:37:15 UTC
Description of problem:
Update of sssd from 1.15.0-3 to 1.15.0-4 breaks my system (the same applies for 1.15.1). I cannot login anymore using my Kerberos password.


Version-Release number of selected component (if applicable):
$ rpm -q sssd
sssd-1.15.0-4.fc26.x86_64

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:
Can't login using Kerberos password.


Expected results:
I can use Kerberos password.


Additional info:
# cat /etc/sysconfig/authconfig
CACHECREDENTIALS=yes
FORCELEGACY=no
FORCESMARTCARD=no
PASSWDALGORITHM=sha512
USEECRYPTFS=no
USEFPRINTD=yes
USEKERBEROS=no
USELDAP=no
USELDAPAUTH=no
USELOCAUTHORIZE=yes
USEMKHOMEDIR=no
USENIS=yes
USEPAMACCESS=no
USEPASSWDQC=no
USEPWQUALITY=yes
USESHADOW=yes
USESMARTCARD=no
USESSSD=yes
USESSSDAUTH=yes
USESYSNETAUTH=no
USEWINBIND=no
USEWINBINDAUTH=no
WINBINDKRB5=no

# cat /etc/nsswitch.conf
#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Valid entries include:
#
#	nisplus			Use NIS+ (NIS version 3)
#	nis			Use NIS (NIS version 2), also called YP
#	dns			Use DNS (Domain Name Service)
#	files			Use the local files
#	db			Use the local database (.db) files
#	compat			Use NIS on compat mode
#	hesiod			Use Hesiod for user lookups
#	[NOTFOUND=return]	Stop searching if not found so far
#

# To use db, put the "db" in front of "files" for entries you want to be
# looked up first in the databases
#
# Example:
#passwd:    db files nisplus nis
#shadow:    db files nisplus nis
#group:     db files nisplus nis

passwd:    
shadow:    
group:     

#hosts:     db files nisplus nis dns
hosts:      files nis dns

# Example - obey only what nisplus tells us...
#services:   nisplus [NOTFOUND=return] files
#networks:   nisplus [NOTFOUND=return] files
#protocols:  nisplus [NOTFOUND=return] files
#rpc:        nisplus [NOTFOUND=return] files
#ethers:     nisplus [NOTFOUND=return] files
#netmasks:   nisplus [NOTFOUND=return] files

bootparams: nisplus [NOTFOUND=return] files

ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files sss

netgroup:   files nis sss

publickey:  nisplus

automount:  files nis sss
aliases:    files nisplus

# cat /etc/pam.d/system-auth-ac
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_fprintd.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_sss.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so sha512 shadow nis nullok try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_sss.so

Comment 2 Jakub Hrozek 2017-03-07 09:46:46 UTC
Please follow https://fedorahosted.org/sssd/wiki/Troubleshooting and provide SSSD logs.

Comment 3 Sumit Bose 2017-03-07 10:39:28 UTC
The empty 'passwd' and 'group' lines in /etc/nsswitch.conf are a bit odd. Does it help to add 'files sss' here?

Comment 4 Vít Ondruch 2017-03-07 11:14:12 UTC
(In reply to Sumit Bose from comment #3)
> The empty 'passwd' and 'group' lines in /etc/nsswitch.conf are a bit odd.
> Does it help to add 'files sss' here?

You are right. I got this nsswitch this way:

~~~
# mv /etc/nsswitch.conf{,.bak}
# dnf reinstall glibc

... snip ...


# cat /etc/nsswitch.conf
#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Valid entries include:
#
#	nisplus			Use NIS+ (NIS version 3)
#	nis			Use NIS (NIS version 2), also called YP
#	dns			Use DNS (Domain Name Service)
#	files			Use the local files
#	db			Use the local database (.db) files
#	compat			Use NIS on compat mode
#	hesiod			Use Hesiod for user lookups
#	[NOTFOUND=return]	Stop searching if not found so far
#

# To use db, put the "db" in front of "files" for entries you want to be
# looked up first in the databases
#
# Example:
#passwd:    db files nisplus nis
#shadow:    db files nisplus nis
#group:     db files nisplus nis

passwd:     sss files
shadow:     files sss
group:      sss files

#hosts:     db files nisplus nis dns
hosts:      files dns

# Example - obey only what nisplus tells us...
#services:   nisplus [NOTFOUND=return] files
#networks:   nisplus [NOTFOUND=return] files
#protocols:  nisplus [NOTFOUND=return] files
#rpc:        nisplus [NOTFOUND=return] files
#ethers:     nisplus [NOTFOUND=return] files
#netmasks:   nisplus [NOTFOUND=return] files

bootparams: nisplus [NOTFOUND=return] files

ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files sss

netgroup:   nisplus sss

publickey:  nisplus

automount:  files nisplus
aliases:    files nisplus


# authconfig --updateall


# cat /etc/nsswitch.conf
#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Valid entries include:
#
#	nisplus			Use NIS+ (NIS version 3)
#	nis			Use NIS (NIS version 2), also called YP
#	dns			Use DNS (Domain Name Service)
#	files			Use the local files
#	db			Use the local database (.db) files
#	compat			Use NIS on compat mode
#	hesiod			Use Hesiod for user lookups
#	[NOTFOUND=return]	Stop searching if not found so far
#

# To use db, put the "db" in front of "files" for entries you want to be
# looked up first in the databases
#
# Example:
#passwd:    db files nisplus nis
#shadow:    db files nisplus nis
#group:     db files nisplus nis

passwd:    
shadow:    
group:     

#hosts:     db files nisplus nis dns
hosts:      files nis dns

# Example - obey only what nisplus tells us...
#services:   nisplus [NOTFOUND=return] files
#networks:   nisplus [NOTFOUND=return] files
#protocols:  nisplus [NOTFOUND=return] files
#rpc:        nisplus [NOTFOUND=return] files
#ethers:     nisplus [NOTFOUND=return] files
#netmasks:   nisplus [NOTFOUND=return] files

bootparams: nisplus [NOTFOUND=return] files

ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files sss

netgroup:   files nis sss

publickey:  nisplus

automount:  files nis sss
aliases:    files nisplus
~~~

But neither the original glibc bersion nor the one after authconfig call helps ...

Comment 6 Vít Ondruch 2017-03-07 11:32:36 UTC
I should probably mention version of glibc and authconfig as well:

$ rpm -q glibc
glibc-2.25.90-1.fc27.x86_64
glibc-2.25.90-1.fc27.i686

$ rpm -q authconfig
authconfig-7.0.0-1.fc26.x86_64

Comment 7 Lukas Slebodnik 2017-03-07 11:39:27 UTC
I would bet it is caused by enabled inplicit files provider.
Because you have the same user in /etc/passwd and in LDAP.

You can try workaround ro disable files provides which is enabled by fdefault in f26+.

Put "enable_files_domain = false" into "sssd" section in /etc/sssd/sssd.conf
I let other fellow developers to check log files.

Comment 8 Vít Ondruch 2017-03-07 13:52:33 UTC
(In reply to Lukas Slebodnik from comment #7)
> Put "enable_files_domain = false" into "sssd" section in /etc/sssd/sssd.conf

This helped, although I have no idea what it actually means. The man page description is not really helpful ...

Comment 9 Simo Sorce 2017-03-07 15:09:31 UTC
SSSD is going to start handling also local users in F26+, this means that it finds a conflict between the local user and the ldap user because they have the same name. SSSD always give precedence to the user of the first domain (which is the local domain) and does not "fall back" on duplicates like the PAM stack does (this is to avoid leaking passwords to all backends and potentially causing user lockups).

So if you want to keep local users that have the same name as remote user (a bad idea in the common case) you'll have to disable SSSD's handling of local users, or change the order in which domains are searched (remote first).

HTH.

Comment 10 Jakub Hrozek 2017-03-07 19:55:17 UTC
OK, so I think there are two issues here:
1) authconfig has fubared the nsswitch. I expect the 'vanilla' nsswitch in f-26 to have the order of groups and passwd modules to be set to 'sss files'. I don't expect running authconfig --updateall to break this.

2) Your PAM configuration is strange, pam_unix is called always and not only for local users which triggers the issue Simo talked about. Because starting with F-26 sssd also handles local users, but you also have a local user with the same name as the remote user, the request eventually goes to pam_sss, but because the files domain is always consulted first, the Kerberos password doesn't reach the remote server.

I wonder how you generated the PAM stack, was it also authconfig?

Comment 11 Vít Ondruch 2017-03-08 08:54:53 UTC
(In reply to Jakub Hrozek from comment #10)
> I wonder how you generated the PAM stack, was it also authconfig?

When I discovered that I can't login using my kerberos password anymore, I certainly tried:

~~~
# mv /etc/sysconfig/authconfig{,.bak}
~~~

and then enabling several options via `authconfig --enable` call, such as:

~~~
# autoconfig --enablesysnetauth
# authconfig --enablesssd
# authconfig --enablesssdauth
# authconfig --enablesssdauthprompting
~~~

Not sure if I enabled anything else, probably not.

I also tried revert from authconfig-7.0.0-1.fc26 to authconfig-6.2.10-16.fc26 at some point, but it did not appeared to help, so I am back to the latest.

I am not aware of any other modification I would do by some other means.

Comment 12 Lukas Slebodnik 2017-03-08 20:06:31 UTC
(In reply to Jakub Hrozek from comment #10)
> OK, so I think there are two issues here:
> 1) authconfig has fubared the nsswitch. I expect the 'vanilla' nsswitch in
> f-26 to have the order of groups and passwd modules to be set to 'sss
> files'. I don't expect running authconfig --updateall to break this.
> 
Yes, but IIUC it did not work with default nsswitch from glibc either.

> 2) Your PAM configuration is strange, pam_unix is called always and not only
> for local users which triggers the issue Simo talked about. Because starting
> with F-26 sssd also handles local users, but you also have a local user with
> the same name as the remote user, the request eventually goes to pam_sss,
> but because the files domain is always consulted first, the Kerberos
> password doesn't reach the remote server.
> 
sssd handle local users; but IIRC pam_sss.so cannot handle passwords from /etc/shadow. Therefore it does not make a sense to contact domain implicit_files
from pam responder.

[sssd[pam]] [get_client_cred] (0x4000): Client creds: euid[0] egid[16025] pid[24568].
[sssd[pam]] [setup_client_idle_timer] (0x4000): Idle timer re-set for client [0x55ae39048630][24]
[sssd[pam]] [accept_fd_handler] (0x0400): Client connected!
[sssd[pam]] [sss_cmd_get_version] (0x0200): Received client version [3].
[sssd[pam]] [sss_cmd_get_version] (0x0200): Offered version [3].
[sssd[pam]] [pam_cmd_authenticate] (0x0100): entering pam_cmd_authenticate
[sssd[pam]] [sss_domain_get_state] (0x1000): Domain redhat.com is Active
[sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'vondruch' matched without domain, user is vondruch
[sssd[pam]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE
[sssd[pam]] [pam_print_data] (0x0100): domain: not set
[sssd[pam]] [pam_print_data] (0x0100): user: vondruch
[sssd[pam]] [pam_print_data] (0x0100): service: sudo
[sssd[pam]] [pam_print_data] (0x0100): tty: /dev/pts/10
[sssd[pam]] [pam_print_data] (0x0100): ruser: vondruch
[sssd[pam]] [pam_print_data] (0x0100): rhost: not set
[sssd[pam]] [pam_print_data] (0x0100): authtok type: 1
[sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0
[sssd[pam]] [pam_print_data] (0x0100): priv: 0
[sssd[pam]] [pam_print_data] (0x0100): cli_pid: 24568
[sssd[pam]] [pam_print_data] (0x0100): logon name: vondruch
[sssd[pam]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/implicit_files/vondruch@implicit_files]
[sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [vondruch@implicit_files]
[sssd[pam]] [pam_check_user_search] (0x0400): Returning info for user [vondruch@implicit_files@implicit_files]
[sssd[pam]] [pd_set_primary_name] (0x0400): User's primary name is vondruch@implicit_files
[sssd[pam]] [LOCAL_pam_handler] (0x0100): LOCAL pam handler.
[sssd[pam]] [LOCAL_pam_handler] (0x0020): No password stored.
[sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [4]: Systémová chyba.
[sssd[pam]] [filter_responses] (0x0100): [pam_response_filter] not available, not fatal.
[sssd[pam]] [pam_reply] (0x0200): blen: 31

Comment 13 Jakub Hrozek 2017-03-08 20:26:37 UTC
(In reply to Lukas Slebodnik from comment #12)
> (In reply to Jakub Hrozek from comment #10)
> > OK, so I think there are two issues here:
> > 1) authconfig has fubared the nsswitch. I expect the 'vanilla' nsswitch in
> > f-26 to have the order of groups and passwd modules to be set to 'sss
> > files'. I don't expect running authconfig --updateall to break this.
> > 
> Yes, but IIUC it did not work with default nsswitch from glibc either.
> 
> > 2) Your PAM configuration is strange, pam_unix is called always and not only
> > for local users which triggers the issue Simo talked about. Because starting
> > with F-26 sssd also handles local users, but you also have a local user with
> > the same name as the remote user, the request eventually goes to pam_sss,
> > but because the files domain is always consulted first, the Kerberos
> > password doesn't reach the remote server.
> > 
> sssd handle local users; 
> but IIRC pam_sss.so cannot handle passwords from
> /etc/shadow. Therefore it does not make a sense to contact domain
> implicit_files
> from pam responder.

OK, for now we could return an error that would iterate to the other domain. But when our files provider supports auth as well, we need our users to migrate..

Comment 14 Lukas Slebodnik 2017-03-16 08:01:17 UTC
Upstream ticket:
https://pagure.io/SSSD/sssd/issue/3341

Comment 15 Jan Kurik 2017-08-15 09:02:57 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

Comment 16 louisgtwo 2017-08-17 23:26:10 UTC
I think I'm hitting this bug. I am not able to login to my kerberos realm. I kept the logs. kinit after login works. Yes, I have the same user/passwd for local account and kerberos. But f26 always uses the local account. How can I change the order in which domains are searched so the my rdc is first? After reading this bug that might solve my issue.

/etc/sssd/sssd.conf
[sssd]
domains = files
services = nss, pam

[pam]
debug_level = 9

[domain/files]
id_provider = files
auth_provider = krb5
debug_level = 9

krb5_server = panther.montclaire.local
krb5_realm = MONTCLAIRE.LOCAL


/etc/nsswitch.conf
#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Valid entries include:
#
#	nisplus			Use NIS+ (NIS version 3)
#	nis			Use NIS (NIS version 2), also called YP
#	dns			Use DNS (Domain Name Service)
#	files			Use the local files
#	db			Use the local database (.db) files
#	compat			Use NIS on compat mode
#	hesiod			Use Hesiod for user lookups
#	[NOTFOUND=return]	Stop searching if not found so far
#

# To use db, put the "db" in front of "files" for entries you want to be
# looked up first in the databases
#
# Example:
#passwd:    db files nisplus nis
#shadow:    db files nisplus nis
#group:     db files nisplus nis

passwd:    files sss
shadow:    files sss
group:     files sss

#hosts:     db files nisplus nis dns
hosts:     files mdns4_minimal [NOTFOUND=return] dns myhostname

# Example - obey only what nisplus tells us...
#services:   nisplus [NOTFOUND=return] files
#networks:   nisplus [NOTFOUND=return] files
#protocols:  nisplus [NOTFOUND=return] files
#rpc:        nisplus [NOTFOUND=return] files
#ethers:     nisplus [NOTFOUND=return] files
#netmasks:   nisplus [NOTFOUND=return] files

bootparams: nisplus [NOTFOUND=return] files

ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:  files sss

netgroup:  files sss

publickey:  nisplus

automount: files
aliases:    files nisplus

Comment 17 Lukas Slebodnik 2017-08-18 06:43:37 UTC
(In reply to louisgtwo from comment #16)
> I think I'm hitting this bug. I am not able to login to my kerberos realm. I
> kept the logs. kinit after login works. Yes, I have the same user/passwd for
> local account and kerberos. But f26 always uses the local account. How can I
> change the order in which domains are searched so the my rdc is first? After
> reading this bug that might solve my issue.
> 
> /etc/sssd/sssd.conf
> [sssd]
> domains = files
> services = nss, pam
> 
> [pam]
> debug_level = 9
> 
> [domain/files]
> id_provider = files
> auth_provider = krb5
> debug_level = 9
> 
> krb5_server = panther.montclaire.local
> krb5_realm = MONTCLAIRE.LOCAL
> 
> 
> /etc/nsswitch.conf
> #
> # /etc/nsswitch.conf
> #
> # An example Name Service Switch config file. This file should be
> # sorted with the most-used services at the beginning.
> #
> # The entry '[NOTFOUND=return]' means that the search for an
> # entry should stop if the search in the previous entry turned
> # up nothing. Note that if the search failed due to some other reason
> # (like no NIS server responding) then the search continues with the
> # next entry.
> #
> # Valid entries include:
> #
> #	nisplus			Use NIS+ (NIS version 3)
> #	nis			Use NIS (NIS version 2), also called YP
> #	dns			Use DNS (Domain Name Service)
> #	files			Use the local files
> #	db			Use the local database (.db) files
> #	compat			Use NIS on compat mode
> #	hesiod			Use Hesiod for user lookups
> #	[NOTFOUND=return]	Stop searching if not found so far
> #
> 
> # To use db, put the "db" in front of "files" for entries you want to be
> # looked up first in the databases
> #
> # Example:
> #passwd:    db files nisplus nis
> #shadow:    db files nisplus nis
> #group:     db files nisplus nis
> 
> passwd:    files sss
> shadow:    files sss
> group:     files sss
> 
> #hosts:     db files nisplus nis dns
> hosts:     files mdns4_minimal [NOTFOUND=return] dns myhostname
> 
> # Example - obey only what nisplus tells us...
> #services:   nisplus [NOTFOUND=return] files
> #networks:   nisplus [NOTFOUND=return] files
> #protocols:  nisplus [NOTFOUND=return] files
> #rpc:        nisplus [NOTFOUND=return] files
> #ethers:     nisplus [NOTFOUND=return] files
> #netmasks:   nisplus [NOTFOUND=return] files
> 
> bootparams: nisplus [NOTFOUND=return] files
> 
> ethers:     files
> netmasks:   files
> networks:   files
> protocols:  files
> rpc:        files
> services:  files sss
> 
> netgroup:  files sss
> 
> publickey:  nisplus
> 
> automount: files
> aliases:    files nisplus

Your case is different because you use id_provider files.
And I already replied to your mail on sssd-users.

Comment 18 Scott Dowdle 2017-12-21 23:00:04 UTC
I have a lab of computers running Fedora 26 (fully updated as of today).  I just did a simple realm join and ding, AD login works for our students.

With Fedora 27 (fully updated as of today) it joins ok, but authentication fails.

My / partition got full (I do not have /var as a separate partition) because /var/log/sssd/sssd_kcm.log was 50G+.  I see a ton of these.

(Thu Dec 21 15:37:44 2017) [sssd[kcm]] [kcm_recv] (0x0010): Failed to parse data (74, Bad message), aborting client 

They are trigger upon an attempted login with an AD account

Here's what I see in the journal (I replaced the real username with USERNAME):

 ---- SSH login
Dec 21 15:43:00 bz-cs-cslab1l.msu.montana.edu sshd[1846]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=127.0.0.1 user=USERNAME
Dec 21 15:43:00 bz-cs-cslab1l.msu.montana.edu audit[1846]: USER_AUTH pid=1846 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=? acct="USERNAME" exe="/usr/sbin/sshd" hostname=127.0.0.1 addr=127.0.0.1 terminal=ssh res=failed'
Dec 21 15:43:00 bz-cs-cslab1l.msu.montana.edu sshd[1846]: pam_sss(sshd:auth): received for user USERNAME: 6 (Permission denied)
Dec 21 15:43:01 bz-cs-cslab1l.msu.montana.edu sshd[1846]: Failed password for USERNAME from 127.0.0.1 port 60790 ssh2
Dec 21 15:43:01 bz-cs-cslab1l.msu.montana.edu audit[1846]: USER_AUTH pid=1846 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=password acct="USERNAME" exe="/usr/sbin/sshd" hostname=? addr=127.0.0.1 terminal=ssh res=failed'
Dec 21 15:43:36 bz-cs-cslab1l.msu.montana.edu audit[1846]: CRYPTO_KEY_USER pid=1846 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=session fp=? direction=both spid=1847 suid=74 rport=60790 laddr=127.0.0.1 lport=22  exe="/usr/sbin/sshd" hostname=? addr=127.
Dec 21 15:43:36 bz-cs-cslab1l.msu.montana.edu sshd[1846]: Connection closed by authenticating user USERNAME 127.0.0.1 port 60790 [preauth]
Dec 21 15:43:36 bz-cs-cslab1l.msu.montana.edu audit[1846]: USER_LOGIN pid=1846 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="USERNAME" exe="/usr/sbin/sshd" hostname=? addr=127.0.0.1 terminal=ssh res=failed'

 ---- CONSOLE login
Dec 21 15:48:56 bz-cs-cslab1l.msu.montana.edu login[3614]: pam_sss(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost= user=USERNAME
Dec 21 15:48:56 bz-cs-cslab1l.msu.montana.edu audit[3614]: USER_AUTH pid=3614 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=? acct="USERNAME" exe="/usr/bin/login" hostname=bz-cs-cslab1l.msu.montana.edu addr=? terminal=tty2 res=failed'
Dec 21 15:48:56 bz-cs-cslab1l.msu.montana.edu login[3614]: pam_sss(login:auth): received for user USERNAME: 6 (Permission denied)
Dec 21 15:48:59 bz-cs-cslab1l.msu.montana.edu login[3614]: FAILED LOGIN 1 FROM tty2 FOR USERNAME, Authentication failure
Dec 21 15:48:59 bz-cs-cslab1l.msu.montana.edu audit[3614]: USER_LOGIN pid=3614 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=login id=608472194 exe="/usr/bin/login" hostname=bz-cs-cslab1l.msu.montana.edu addr=? terminal=tty2 res=failed'

 ---- LightDM login
Dec 21 15:48:42 bz-cs-cslab1l.msu.montana.edu lightdm[3507]: pam_sss(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=USERNAME
Dec 21 15:48:42 bz-cs-cslab1l.msu.montana.edu lightdm[3507]: pam_sss(lightdm:auth): received for user USERNAME: 6 (Permission denied)
Dec 21 15:48:42 bz-cs-cslab1l.msu.montana.edu lightdm[3507]: pam_kwallet5(lightdm:auth): (null): pam_sm_authenticate

After trying those 3 login attempts the /var/log/sssd/sssd_kcm.log file went from 0 bytes (I had cat /dev/null > /var/log/sssd/ssd_kcm.log a minute prior) to 15GB.  Not quote a DoS attack, but close.  A few more logins and my hard drive will be full again.

HELP!

I only have a short winter break before the Spring semester starts and if I can't get this solved, I'll have to stick with Fedora 26.

Comment 19 Scott Dowdle 2017-12-21 23:19:24 UTC
Hmm, it seems the logging issue was caused by the only config edit I made to try to remedy the issue (I edited /etc/sysconfig/authconfig and changed FORCELEGACY=no to FORCELEGACY=yes).  I have reverted that change and rebooted and the disk filling logging has ceased.

The login failures for AD accounts continue though.

Comment 20 Jakub Hrozek 2017-12-22 14:05:28 UTC
(In reply to Scott Dowdle from comment #19)
> Hmm, it seems the logging issue was caused by the only config edit I made to
> try to remedy the issue (I edited /etc/sysconfig/authconfig and changed
> FORCELEGACY=no to FORCELEGACY=yes).  I have reverted that change and
> rebooted and the disk filling logging has ceased.
> 

FORCELEGACY=YES IIRC configures pam_krb5 (you could confirm or deny this with e.g. cat /etc/pam.d/system-auth) so but I'm stumped as how this would help since the ticket itself would still be stored in sssd-kcm UNLESS pam_krb5 overrides the KRB5CCNAME. When you login with this workaround and run 'klist', does the ccache start with FILE or KCM?

> The login failures for AD accounts continue though.

Could you post the sssd logs please?

btw I'm sorry if the comments are delayed, but most of the SSSD developers already started their Christmas break..

Comment 21 Scott Dowdle 2017-12-22 16:09:25 UTC
Understood about the holidays.  I'm taking 5 days off myself... but I'll get those logs posted when I get back to work.

Regarding the change to the /etc/sysconfig/authconfig file... I must admit I don't know how the various authentication methods work nor their mechanics.  I tried that changed just because I found that as a possible solution in a web search.  It didn't work, so I reverted it.  In this case the change had the obvious negative side-effect of making the logs blow up.  If it had worked, I would have mentioned it and asked why.  I definitely don't like to do monkey-see-monkey-do fixes without understanding why especially when many config changes come with security implications.  Not every solution is an acceptable fix.

Comment 22 Scott Dowdle 2017-12-27 23:09:20 UTC
Looking at the various contents of /var/log/sssd/* nothing is jumping out at me. Mostly just a lot of SIGTERM killing children from the shutting down of the service at reboot.

I was doing a journald -f when logging in from the console, ssh, and from lightdm-gtk and provided the entries in comment # 18.

getent passwd {adusername} is returning good info.

I would really like to help you help me but I'm not sure what else to provide.

Comment 23 Jakub Hrozek 2018-01-04 10:16:38 UTC
I would like to help you, but without more logs, it will be difficult.

I think you are more likely to be hitting https://bugzilla.redhat.com/show_bug.cgi?id=1494843 than the original issue in this BZ, because this BZ is about local accounts using Kerberos authentication.

In https://bugzilla.redhat.com/show_bug.cgi?id=1494843 there are some instructions how to get log files as well as a possible workaround that might allow you to get along with F-27 without KCM credential cache - the workaround is in the opening comment.

Comment 24 Scott Dowdle 2018-01-24 16:33:38 UTC
Thanks for the info Jakub.  I ended up nuking the F27 system I was working with to make an image and just keeping F26 on the systems... which continues to work fine.

I'm not really doing anything out of the ordinary so I'm guessing the bug I'm having (which as you mention doesn't map to this particular bug report very well) should be easily reproducible... unless of course there is something out-of-the-ordinary with the AD we have on campus... that I do not manage.

All I can say is that it works great in F26 but not F27.

Comment 25 Ben Cotton 2018-11-27 17:22:23 UTC
This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 26 Ben Cotton 2019-02-19 17:11:30 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 30 development cycle.
Changing version to '30.


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