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 lslebodn@redhat.com Sent: 18 June 2020 12:04 To: End-user discussions about the System Security Services Daemon sssd-users@lists.fedorahosted.org 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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org 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/sssd-users@lists.fedorahosted.o...
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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org 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/sssd-users@lists.fedorahosted.o...
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 striker@terranforge.com Sent: 22 June 2020 16:12 To: sssd-users@lists.fedorahosted.org 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 lslebodn@redhat.commailto:lslebodn@redhat.com
Sent: 18 June 2020 12:04
To: End-user discussions about the System Security Services Daemon sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org
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 -- sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.orgmailto:sssd-users-leave@lists.fedorahosted.org
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/sssd-users@lists.fedorahosted.o...
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 -- sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.orgmailto:sssd-users-leave@lists.fedorahosted.org
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/sssd-users@lists.fedorahosted.o...
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@lists.fedorahosted.org
-
Sangster, Mark -
Striker Leggette