On 03/17/2017 11:27 AM, Kilborn, Jim wrote:
Jakub,

Thanks for the response...

I already had the selinux_provider=none in the sssd.conf
Tthe sssd.conf is identical on both clients, with the exception of ipa_hostname


[domain/ipa.mydomain.org]
selinux_provider = none
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = ipa.mydomain.org
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ldap_tls_cacert = /etc/ipa/ca.crt
ipa_hostname = darkjedi-master01.div18.swri.edu
chpass_provider = ipa
ipa_server = _srv_, div18auth1.ipa.mydomain.org, div18auth2.ipa.mydomain.org
dns_discovery_domain = ipa.mydomain.org
[sssd]
services = nss, sudo, pam, ssh
config_file_version = 2
domains = ipa.mydomain.org
[nss]
homedir_substring = /home
[pam]
[sudo]
[autofs]
[ssh]
[pac]
[ifp]

I verified the all the files in /etc/pam.d are the same on both clients using 
the checksum of the files.

I turned logging up to 8 on both clients, and everything is fine until this 
part appears. Can't figure out why the slow host receives an extra request. The 
sssd_be client process is getting this request from where?

It is expected for the login process to make a call into pam_acct_mgmt() which should trigger pam_sss in the 'account' section of the PAM stack for IPA users. This behavior is dependent on the PAM stack configuration, I would say the system that never calls SSS_PAM_ACCT_MGMT is the non-working one in this case.

I understand you said they are the exact same, but I would suggest checking closely the 'account' section in /etc/pam.d/sshd and /etc/pam.d/password-auth.

In the version you are running, the password-auth account section should look similar to:

    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

After it finished up the SSS_PAM_ACCT_MGMT request, the slow client runs the 
SSS_PAM_OPEN_SESSION, which is fast, just like the fast client. Its wasting 
time in the SSS_PAM_ACCT_MGMT request, and I don't understand why that request 
is being received  by sssd_be.

Is it possible a local user exists with the same name that you are trying to login as? In this case that may cause the pam_sss line entry in the PAM stack to never be reached(they would 'succeed' the account section in one of the previous modules).


Slow Client
(Fri Mar 17 09:17:33 2017) [sssd[be[ipa.div18.swri.org]]] [dp_pam_handler] 
(0x0100): Got request with the following data
(Fri Mar 17 09:17:33 2017) [sssd[be[ipa.div18.swri.org]]] [pam_print_data] 
(0x0100): command: SSS_PAM_ACCT_MGMT   <- Why does the slow client get this 
request first?

Fast Client
(Fri Mar 17 09:16:34 2017) [sssd[be[ipa.div18.swri.org]]] [dp_pam_handler] 
(0x0100): Got request with the following data
(Fri Mar 17 09:16:34 2017) [sssd[be[ipa.div18.swri.org]]] [pam_print_data] 
(0x0100): command: SSS_PAM_OPEN_SESSION


Also ipa version is 4.4.0


Regards,
Jim

Greetings,

My first post to the forum.

We are running centos7 with freeipa. Syncing from AD, with one linux replica.
The ipa clients are getting installed by puppet. All the clients are performing 
fine, except one. I am getting slow ssh logins to one host, as well as slow 
'id' and 'who', etc.

I turned up the sss-debuglevel to 6, and compared the slow client to
another, and I am seeing a section in the logs that is unique to the slow 
system, basically its doing a SSS_PAM_ACCT_MGMT, and I don't have any clue why. 
Same user logging in to both clients, one client does the SSS_PAM_ACCT_MGMT, 
followed by the SSS_PAM_OPEN_SESSION. While the other client only does 
SSS_PAM_OPEN_SESSION, and is much faster. (1 second vs 2-8 seconds) It seems 
the SSS_PAM_ACCT_MGMT is the slow culprit, and I don't know why its running.

Any idea what would cause this or where I should look?

The timestamps from the logs are missing, so it's not clear which call is 
taking long. No server lookups should be performed in the account phase, 
though, so I can only think of the selinux label setting in libselinux, which 
is also done in the account phase to be taking long.

can you try to disable the selinux provider for a test?
    selinux_provider=none
btw why is the 'fast' client not running the account phase at all? Is pam_sss 
in the account stack in the PAM configuration? Is the access_provider set to 
anything else than IPA in the sssd.conf file?

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to