First, thank you for this confirmation, I enabled the debug.

Now I have the log however I see some things that maybe considered “sensitive”.

Would it be best I open a call via RH for support rather than try to sanitise 
the log to share here?

Thanks
Mark

From: Striker Leggette <[email protected]>
Sent: 22 June 2020 16:12
To: [email protected]
Subject: [SSSD-users] Re: SSH user fails system error 4

CAUTION: External email. Ensure this message is from a trusted source before 
clicking links/attachments.

Debugging itself adds very little processing usage overhead with SSSD.

Depending on how many connections you are receiving in any given time will 
ultimately determine how large the debugging grows on the system.

Logging does not cause a large amount of space consumption. I would advise 
adding 'debug_level = 9' to all sections of sssd.conf, restart SSSD and simply 
keep an eye on the storage usage to make sure it doesn't use up all space until 
the issue can be reproduced.
On 6/22/20 11:06 AM, Sangster, Mark wrote:

Hello,



My difficult lies with being able to debug this. The need to leave the debug on 
for ~3-4 days on a production system, is something that I would not be 
comfortable doing.



We are using Active Directory, Domain/Functional forest level Windows Server 
2012 R2.



We are in the midst of switching us stuff to be the AD provider but this is 
still KRB5/LDAP.



[sssd]

config_file_version = 2

domains = DOMAIN

services = nss, pam

 [domain/DOMAIN]

ldap_referrals = false

cache_credentials = true

enumerate = false

id_provider = ldap

auth_provider = krb5

ldap_uri = ldap://LDAP1.DOMAIN, ldap://LDAP2.DOMAIN

ldap_sasl_mech = GSSAPI

ldap_sasl_authid = SERVER$@DOMAIN

ldap_schema = rfc2307bis

ldap_user_search_base = DC=DOMAIN,DC=BASE

ldap_user_object_class = user

ldap_group_search_base = DC=DOMAIN,DC=BASE

ldap_group_object_class = group

ldap_account_expire_policy = ad

ldap_force_upper_case_realm = true

krb5_server = LDAP1.DOMAIN, LDAP2.DOMAIN

krb5_realm = DOMAIN

krb5_canonicalize = false

ldap_user_home_directory = unixHomeDirectory

ldap_user_name = sAMAccountName

ldap_user_principal = None

access_provider = simple

simple_allow_groups = USERS_GROUP



I re-joined the machine to the domain to ensure that wasn't the source of 
issues.



If there is an appropriate debug level which wouldn't be negative to a 
production system, I can try that out.



Cheers

Mark





-----Original Message-----

From: Lukas Slebodnik <[email protected]><mailto:[email protected]>

Sent: 18 June 2020 12:04

To: End-user discussions about the System Security Services Daemon 
<[email protected]><mailto:[email protected]>

Subject: [SSSD-users] Re: SSH user fails system error 4



CAUTION: External email. Ensure this message is from a trusted source before 
clicking links/attachments.





On (18/06/20 09:11), Sangster, Mark wrote:

Hello,



We are experiencing an issue with a user when they attempt to login. Other 
users can continue to login. It does seem to repeat on this specific user.



If I blitz the SSSD cache and restart it, then they find they can login again.



They indicated that just prior to the event, they were forced to reboot their 
machine (i.e. unclean disconnect) and it was after that they couldn’t login.



This was the successful session just before:



Jun 17 08:00:58 server sshd[11882]: pam_sss(sshd:auth): authentication

success; logname= uid=0 euid=0 tty=ssh ruser= rhost=<CLIENTIP>

user=username Jun 17 08:00:58 server sshd[11882]: Accepted password for

username from <CLIENTIP> port 59680 ssh2 Jun 17 08:00:59 server

sshd[11882]: pam_unix(sshd:session): session opened for user username

by (uid=0) Jun 17 13:22:17 server sshd[11882]: pam_unix(sshd:session):

session closed for user username



The next session which failed:



Jun 17 13:33:13 server sshd[13210]: pam_sss(sshd:auth): authentication

success; logname= uid=0 euid=0 tty=ssh ruser= rhost=<CLIENTIP>

user=username Jun 17 13:33:13 server sshd[13210]:

pam_sss(sshd:account): Access denied for user username: 4 (System

error) Jun 17 13:33:13 server sshd[13210]: Failed password for username

>from <CLIENTIP> port 50114 ssh2 Jun 17 13:33:13 server sshd[13210]:

fatal: Access denied for user username by PAM account configuration

[preauth]



There does not look to be any additional log information in SSSD representing 
the error. The troubleshooting suggested I follow up here for “system error 4”.



It would be tricky to run debug on this, as this took 4 days until the failure 
reappeared and we might fill our log space very quickly.





Pam return code 4 (System error) means some unexpected situation in sssd 
(usually in backend)



I would recomment to follow following guide 
https://sssd.io/docs/users/troubleshooting.html



It would be good to also provide more details about your configuration 
type/version of directory server, ...



LS

_______________________________________________

sssd-users mailing list -- 
[email protected]<mailto:[email protected]> To 
unsubscribe send an email to 
[email protected]<mailto:[email protected]>

Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

List Archives: 
https://lists.fedorahosted.org/archives/list/[email protected]





The University of Aberdeen is a charity registered in Scotland, No SC013683.

Tha Oilthigh Obar Dheathain na charthannas clàraichte ann an Alba, Àir. 
SC013683.

_______________________________________________

sssd-users mailing list -- 
[email protected]<mailto:[email protected]>

To unsubscribe send an email to 
[email protected]<mailto:[email protected]>

Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

List Archives: 
https://lists.fedorahosted.org/archives/list/[email protected]



The University of Aberdeen is a charity registered in Scotland, No SC013683.
Tha Oilthigh Obar Dheathain na charthannas clàraichte ann an Alba, Àir. 
SC013683.
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/[email protected]

Reply via email to