I noticed that on one of our test systems running sssd we have about 150 /tmp/adcli-krb5-* files (they already take up about 600K after a few days) and have contents similar to a krb5.conf file snippet
# cat /tmp/adcli-krb5-a1klQy/krb5.d/adcli-krb5-conf-sM7Ia1 [realms] VWQA.LOCAL = { kdc = vwqadc02.vwqa.local:88 master_kdc = vwqadc02.vwqa.local:88 kpasswd_server = vwqadc02.vwqa.local } [domain_realm] vwqadc02.vwqa.local = VWQA.LOCAL vwqadc02.vwqa.local = VWQA.LOCAL
Any idea why there are so many of them - and what keeps creating them?
On Wed, Jan 25, 2017 at 10:48:32PM -0000, smfrench@gmail.com wrote:
I noticed that on one of our test systems running sssd we have about 150 /tmp/adcli-krb5-* files (they already take up about 600K after a few days) and have contents similar to a krb5.conf file snippet
SSSD calls adcli in a regular basis to check if the host key in AD should be renewed and renew it if needed. I guess that adcli fails for some reason and does not clean up temporary files to allow debugging later. Please check the SSSD domain log if there are any messages about failed attempts to renew the key, maybe you have to increase the debug_level.
If you do not have a strict requirement to renew the host key on a regular basis in your environment you can disable the renewal completely by setting 'ad_maximum_machine_account_password_age = 0', see man sssd-ad for more details.
HTH
bye, Sumit
# cat /tmp/adcli-krb5-a1klQy/krb5.d/adcli-krb5-conf-sM7Ia1 [realms] VWQA.LOCAL = { kdc = vwqadc02.vwqa.local:88 master_kdc = vwqadc02.vwqa.local:88 kpasswd_server = vwqadc02.vwqa.local } [domain_realm] vwqadc02.vwqa.local = VWQA.LOCAL vwqadc02.vwqa.local = VWQA.LOCAL
Any idea why there are so many of them - and what keeps creating them? _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
We do see errors in the log, although not clear yet if the large number of them were due to sssd service not being restarted (we fixed that and still saw the same two errors in the logs - just not sure if as often)
"(Wed Jan 25 21:50:20 2017) [sssd[nss]] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.sssd.Error.DataProvider.Offline]" in the sssd log and about 7000 occurrences in the ldap log of [[sssd[ldap_child[7916]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Preauthentication failed
On Thu, Jan 26, 2017 at 09:12:06PM -0000, smfrench@gmail.com wrote:
We do see errors in the log, although not clear yet if the large number of them were due to sssd service not being restarted (we fixed that and still saw the same two errors in the logs - just not sure if as often)
"(Wed Jan 25 21:50:20 2017) [sssd[nss]] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.sssd.Error.DataProvider.Offline]" in the sssd log and about 7000 occurrences in the ldap log of [[sssd[ldap_child[7916]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Preauthentication failed
This looks like the keytab with the hostkey used by SSSD to authenticate against AD is broken.
You can check the keytab content with
klist -k
there should be an entry looking like 'NAME$@AD.REALM', please try if
kinit -k 'NAME$@AD.REALM'
works or if it returns a 'Preauthentication failed' error as well. In this case you should try to join the AD domain again. If you use realmd to join the keytab will be updated automatically. If you use 'net ads join' you might have to call 'net ads keytab create' afterwards as well.
HTH
bye, Sumit
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users@lists.fedorahosted.org