I am having a frustrating time trying to figure out what is going on with these Ubuntu servers. I have tried to use msktutil as some have suggested, but this hasn't worked for me. Every 7 days on the mark I lose my domain connection and have to run realm leave/realm join again. I ran msktutil the day before the ticket was about to expire, so it should have worked. This is only a problem on Ubuntu, CentOS works perfectly fine. I even have one Ubuntu server that works.
I also have the problem that the sssd init script, wherever that is now, sometimes thinks that sssd is still running and won't start again. I then have to run 'sssd -D' if I don't want to restart the server.
This is what I get running msktutil. msktutil --auto-update --verbose: -- init_password: Wiping the computer password structure -- generate_new_password: Generating a new, random password for the computer account -- generate_new_password: Characters read from /dev/udandom = 86 -- get_dc_host: Attempting to find a Domain Controller to use (DNS SRV RR TCP) -- get_dc_host: Found DC: udc05.ad.mydomain.com -- get_dc_host: Canonicalizing DC through forward/reverse lookup... -- get_dc_host: Found Domain Controller: udc05.ad.mydomain.com -- get_default_keytab: Obtaining the default keytab name: FILE:/etc/krb5.keytab -- create_fake_krb5_conf: Created a fake krb5.conf file: /tmp/.msktkrb5.conf-TSzpEQ -- reload: Reloading Kerberos Context -- get_short_hostname: Determined short hostname: myserver-domain-foo-com Error: The SAM name (myserver-domain-foo-com$) for this host is longer than the maximum of MAX_SAM_ACCOUNT_LEN characters You can specify a shorter name using --computer-name -- ~KRB5Context: Destroying Kerberos Context
This appears to have worked, but it didn't. msktutil --update --computer-name MYSERVER --verbose: -- init_password: Wiping the computer password structure -- generate_new_password: Generating a new, random password for the computer account -- generate_new_password: Characters read from /dev/udandom = 82 -- get_dc_host: Attempting to find a Domain Controller to use (DNS SRV RR TCP) -- get_dc_host: Found DC: udc05.ad.mydomain.com -- get_dc_host: Canonicalizing DC through forward/reverse lookup... -- get_dc_host: Found Domain Controller: udc05.ad.mydomain.com -- get_default_keytab: Obtaining the default keytab name: FILE:/etc/krb5.keytab -- create_fake_krb5_conf: Created a fake krb5.conf file: /tmp/.msktkrb5.conf-ozv4A6 -- reload: Reloading Kerberos Context -- finalize_exec: SAM Account Name is: MYSERVER$ -- try_machine_keytab_princ: Trying to authenticate for MYSERVER$ from local keytab... -- switch_default_ccache: Using the local credential cache: FILE:/tmp/.mskt_krb5_ccache-ewj6uW -- finalize_exec: Authenticated using method 1
-- ldap_connect: Connecting to LDAP server: udc05.ad.mydomain.com try_tls=YES -- ldap_connect: Connecting to LDAP server: udc05.ad.mydomain.com try_tls=NO SASL/GSSAPI authentication started SASL username: MYSERVER$@AD.MYDOMAIN.COM SASL SSF: 56 SASL data security layer installed. -- ldap_connect: LDAP_OPT_X_SASL_SSF=56
This is what I think is the pertinent portions of the logs from when the computer cant connect anymore. sssd_ad.mydomain.com.log: (Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.com]]] [sdap_get_tgt_recv] (0x0400): Child responded: 14 [Preauthentication failed], expired on [0] (Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.com]]] [sdap_kinit_done] (0x0100): Could not get TGT: 14 [Bad address] (Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.com]]] [sdap_cli_kinit_done] (0x0400): Cannot get a TGT: ret [1432158219](Authentication Failed) (Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.com]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'udc02.ad.mydomain.com' as 'not working' (Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.com]]] [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP (Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.com]]] [fo_set_port_status] (0x0400): Marking port 389 of duplicate server 'udc02.ad.mydomain.com' as 'not working'
syslog: Nov 4 15:26:09 myserver [sssd[ldap_child[25833]]]: Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection. Nov 4 15:26:09 myserver [sssd[ldap_child[25833]]]: Preauthentication failed
Any help is appreciated.
Hi Neil,
First of all, sorry for entering the discussion without having read all previous thread messages. I may duplicate some content.
Your first msktutil output is confusing to me, as is ends in an "Error" message. So I don't understand why you say that it has worked?
Does a klist -kt /etc/krb5.keytab show an updated keytab after msktutil --auto-update was run?
In our setup, we have a 30 day password expiry setting in the ad controller. A Cronjob runs msktutil --auto-update once a day (it actually updates the keytab only after it expires) and that is sufficient to keep our machines (Ubuntu 14, 15 + opensuse) in the domain without any further action.
-Joschi
Am 17.12.2015 um 18:40 schrieb Thackeray, Neil L <neilt@illinois.edumailto:neilt@illinois.edu>:
I am having a frustrating time trying to figure out what is going on with these Ubuntu servers. I have tried to use msktutil as some have suggested, but this hasn’t worked for me. Every 7 days on the mark I lose my domain connection and have to run realm leave/realm join again. I ran msktutil the day before the ticket was about to expire, so it should have worked. This is only a problem on Ubuntu, CentOS works perfectly fine. I even have one Ubuntu server that works.
I also have the problem that the sssd init script, wherever that is now, sometimes thinks that sssd is still running and won’t start again. I then have to run ‘sssd –D’ if I don’t want to restart the server.
This is what I get running msktutil. msktutil --auto-update --verbose: -- init_password: Wiping the computer password structure -- generate_new_password: Generating a new, random password for the computer account -- generate_new_password: Characters read from /dev/udandom = 86 -- get_dc_host: Attempting to find a Domain Controller to use (DNS SRV RR TCP) -- get_dc_host: Found DC: udc05.ad.mydomain.comhttp://udc05.ad.mydomain.com -- get_dc_host: Canonicalizing DC through forward/reverse lookup... -- get_dc_host: Found Domain Controller: udc05.ad.mydomain.comhttp://udc05.ad.mydomain.com -- get_default_keytab: Obtaining the default keytab name: FILE:/etc/krb5.keytab -- create_fake_krb5_conf: Created a fake krb5.conf file: /tmp/.msktkrb5.conf-TSzpEQ -- reload: Reloading Kerberos Context -- get_short_hostname: Determined short hostname: myserver-domain-foo-com Error: The SAM name (myserver-domain-foo-com$) for this host is longer than the maximum of MAX_SAM_ACCOUNT_LEN characters You can specify a shorter name using --computer-name -- ~KRB5Context: Destroying Kerberos Context
This appears to have worked, but it didn’t. msktutil --update --computer-name MYSERVER --verbose: -- init_password: Wiping the computer password structure -- generate_new_password: Generating a new, random password for the computer account -- generate_new_password: Characters read from /dev/udandom = 82 -- get_dc_host: Attempting to find a Domain Controller to use (DNS SRV RR TCP) -- get_dc_host: Found DC: udc05.ad.mydomain.comhttp://udc05.ad.mydomain.com -- get_dc_host: Canonicalizing DC through forward/reverse lookup... -- get_dc_host: Found Domain Controller: udc05.ad.mydomain.comhttp://udc05.ad.mydomain.com -- get_default_keytab: Obtaining the default keytab name: FILE:/etc/krb5.keytab -- create_fake_krb5_conf: Created a fake krb5.conf file: /tmp/.msktkrb5.conf-ozv4A6 -- reload: Reloading Kerberos Context -- finalize_exec: SAM Account Name is: MYSERVER$ -- try_machine_keytab_princ: Trying to authenticate for MYSERVER$ from local keytab... -- switch_default_ccache: Using the local credential cache: FILE:/tmp/.mskt_krb5_ccache-ewj6uW -- finalize_exec: Authenticated using method 1
-- ldap_connect: Connecting to LDAP server: udc05.ad.mydomain.comhttp://udc05.ad.mydomain.com try_tls=YES -- ldap_connect: Connecting to LDAP server: udc05.ad.mydomain.comhttp://udc05.ad.mydomain.com try_tls=NO SASL/GSSAPI authentication started SASL username: MYSERVER$@AD.MYDOMAIN.COMmailto:MYSERVER$@ad.mydomain.com SASL SSF: 56 SASL data security layer installed. -- ldap_connect: LDAP_OPT_X_SASL_SSF=56
This is what I think is the pertinent portions of the logs from when the computer cant connect anymore. sssd_ad.mydomain.com.log: (Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.comhttp://ad.mydomain.com]]] [sdap_get_tgt_recv] (0x0400): Child responded: 14 [Preauthentication failed], expired on [0] (Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.comhttp://ad.mydomain.com]]] [sdap_kinit_done] (0x0100): Could not get TGT: 14 [Bad address] (Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.comhttp://ad.mydomain.com]]] [sdap_cli_kinit_done] (0x0400): Cannot get a TGT: ret [1432158219](Authentication Failed) (Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.comhttp://ad.mydomain.com]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'udc02.ad.mydomain.comhttp://udc02.ad.mydomain.com' as 'not working' (Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.comhttp://ad.mydomain.com]]] [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP (Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.comhttp://ad.mydomain.com]]] [fo_set_port_status] (0x0400): Marking port 389 of duplicate server 'udc02.ad.mydomain.comhttp://udc02.ad.mydomain.com' as 'not working'
syslog: Nov 4 15:26:09 myserver [sssd[ldap_child[25833]]]: Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection. Nov 4 15:26:09 myserver [sssd[ldap_child[25833]]]: Preauthentication failed
Any help is appreciated. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
msktutil -auto-update is grabbing the DNS name for some reason and trying to use that. I have to specify -computer-name for it to seemingly work, which it doesn't.
When I do a klist -kt it doesn't show any updated entries in the keytab file.
From: Joschi Brauchle [mailto:joschi.brauchle@tum.de] Sent: Thursday, December 17, 2015 1:12 PM To: End-user discussions about the System Security Services Daemon sssd-users@lists.fedorahosted.org Subject: [SSSD-users] Re: Ticket expiring problems still
Hi Neil,
First of all, sorry for entering the discussion without having read all previous thread messages. I may duplicate some content.
Your first msktutil output is confusing to me, as is ends in an "Error" message. So I don't understand why you say that it has worked?
Does a klist -kt /etc/krb5.keytab show an updated keytab after msktutil --auto-update was run?
In our setup, we have a 30 day password expiry setting in the ad controller. A Cronjob runs msktutil --auto-update once a day (it actually updates the keytab only after it expires) and that is sufficient to keep our machines (Ubuntu 14, 15 + opensuse) in the domain without any further action.
-Joschi
Am 17.12.2015 um 18:40 schrieb Thackeray, Neil L <neilt@illinois.edumailto:neilt@illinois.edu>: I am having a frustrating time trying to figure out what is going on with these Ubuntu servers. I have tried to use msktutil as some have suggested, but this hasn't worked for me. Every 7 days on the mark I lose my domain connection and have to run realm leave/realm join again. I ran msktutil the day before the ticket was about to expire, so it should have worked. This is only a problem on Ubuntu, CentOS works perfectly fine. I even have one Ubuntu server that works.
I also have the problem that the sssd init script, wherever that is now, sometimes thinks that sssd is still running and won't start again. I then have to run 'sssd -D' if I don't want to restart the server.
This is what I get running msktutil. msktutil --auto-update --verbose: -- init_password: Wiping the computer password structure -- generate_new_password: Generating a new, random password for the computer account -- generate_new_password: Characters read from /dev/udandom = 86 -- get_dc_host: Attempting to find a Domain Controller to use (DNS SRV RR TCP) -- get_dc_host: Found DC: udc05.ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__udc05.ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=qTlkw1hgmA_n9I9okLFglcZD8555xAuTKXvxigNopdg&e= -- get_dc_host: Canonicalizing DC through forward/reverse lookup... -- get_dc_host: Found Domain Controller: udc05.ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__udc05.ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=qTlkw1hgmA_n9I9okLFglcZD8555xAuTKXvxigNopdg&e= -- get_default_keytab: Obtaining the default keytab name: FILE:/etc/krb5.keytab -- create_fake_krb5_conf: Created a fake krb5.conf file: /tmp/.msktkrb5.conf-TSzpEQ -- reload: Reloading Kerberos Context -- get_short_hostname: Determined short hostname: myserver-domain-foo-com Error: The SAM name (myserver-domain-foo-com$) for this host is longer than the maximum of MAX_SAM_ACCOUNT_LEN characters You can specify a shorter name using --computer-name -- ~KRB5Context: Destroying Kerberos Context
This appears to have worked, but it didn't. msktutil --update --computer-name MYSERVER --verbose: -- init_password: Wiping the computer password structure -- generate_new_password: Generating a new, random password for the computer account -- generate_new_password: Characters read from /dev/udandom = 82 -- get_dc_host: Attempting to find a Domain Controller to use (DNS SRV RR TCP) -- get_dc_host: Found DC: udc05.ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__udc05.ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=qTlkw1hgmA_n9I9okLFglcZD8555xAuTKXvxigNopdg&e= -- get_dc_host: Canonicalizing DC through forward/reverse lookup... -- get_dc_host: Found Domain Controller: udc05.ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__udc05.ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=qTlkw1hgmA_n9I9okLFglcZD8555xAuTKXvxigNopdg&e= -- get_default_keytab: Obtaining the default keytab name: FILE:/etc/krb5.keytab -- create_fake_krb5_conf: Created a fake krb5.conf file: /tmp/.msktkrb5.conf-ozv4A6 -- reload: Reloading Kerberos Context -- finalize_exec: SAM Account Name is: MYSERVER$ -- try_machine_keytab_princ: Trying to authenticate for MYSERVER$ from local keytab... -- switch_default_ccache: Using the local credential cache: FILE:/tmp/.mskt_krb5_ccache-ewj6uW -- finalize_exec: Authenticated using method 1
-- ldap_connect: Connecting to LDAP server: udc05.ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__udc05.ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=qTlkw1hgmA_n9I9okLFglcZD8555xAuTKXvxigNopdg&e= try_tls=YES -- ldap_connect: Connecting to LDAP server: udc05.ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__udc05.ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=qTlkw1hgmA_n9I9okLFglcZD8555xAuTKXvxigNopdg&e= try_tls=NO SASL/GSSAPI authentication started SASL username: MYSERVER$@AD.MYDOMAIN.COMmailto:MYSERVER$@ad.mydomain.com SASL SSF: 56 SASL data security layer installed. -- ldap_connect: LDAP_OPT_X_SASL_SSF=56
This is what I think is the pertinent portions of the logs from when the computer cant connect anymore. sssd_ad.mydomain.com.log: (Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=lHp3WJ7Bw0Wvt377k8g1H4JgdrM82FmTJoMmluWqTQE&e=]]] [sdap_get_tgt_recv] (0x0400): Child responded: 14 [Preauthentication failed], expired on [0] (Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=lHp3WJ7Bw0Wvt377k8g1H4JgdrM82FmTJoMmluWqTQE&e=]]] [sdap_kinit_done] (0x0100): Could not get TGT: 14 [Bad address] (Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=lHp3WJ7Bw0Wvt377k8g1H4JgdrM82FmTJoMmluWqTQE&e=]]] [sdap_cli_kinit_done] (0x0400): Cannot get a TGT: ret [1432158219](Authentication Failed) (Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=lHp3WJ7Bw0Wvt377k8g1H4JgdrM82FmTJoMmluWqTQE&e=]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'udc02.ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__udc02.ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=snoF_MvPwCM79eFbcPTZcLYKlg63XjLJwZAO0xR4Qvs&e=' as 'not working' (Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=lHp3WJ7Bw0Wvt377k8g1H4JgdrM82FmTJoMmluWqTQE&e=]]] [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP (Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=lHp3WJ7Bw0Wvt377k8g1H4JgdrM82FmTJoMmluWqTQE&e=]]] [fo_set_port_status] (0x0400): Marking port 389 of duplicate server 'udc02.ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__udc02.ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=snoF_MvPwCM79eFbcPTZcLYKlg63XjLJwZAO0xR4Qvs&e=' as 'not working'
syslog: Nov 4 15:26:09 myserver [sssd[ldap_child[25833]]]: Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection. Nov 4 15:26:09 myserver [sssd[ldap_child[25833]]]: Preauthentication failed
Any help is appreciated. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.orghttps://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.org_admin_lists_sssd-2Dusers-40lists.fedorahosted.org&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=2xj7MBN63EQQlXOVUffSey4fJsXx2jb4kKMUOKfsthk&e=
Hello,
I am getting the same errors in syslog on CentOS 6.7 and 7.1.
When I issue a plain 'klist /etc/krb5.keytab' I get the following:
klist: Bad format in credentials cache
However 'klist -ke' and the like are working, I was wondering if you are seeing the same Neil? Maybe because of this bad format, sssd cannot read it and thus it is an msktutil issue? Maybe we can circumvent this by using some option with msktutil?
Regards,
Andy
On 18 December 2015 at 01:06, Thackeray, Neil L neilt@illinois.edu wrote:
msktutil –auto-update is grabbing the DNS name for some reason and trying to use that. I have to specify –computer-name for it to seemingly work, which it doesn’t.
When I do a klist –kt it doesn’t show any updated entries in the keytab file.
*From:* Joschi Brauchle [mailto:joschi.brauchle@tum.de] *Sent:* Thursday, December 17, 2015 1:12 PM *To:* End-user discussions about the System Security Services Daemon < sssd-users@lists.fedorahosted.org> *Subject:* [SSSD-users] Re: Ticket expiring problems still
Hi Neil,
First of all, sorry for entering the discussion without having read all previous thread messages. I may duplicate some content.
Your first msktutil output is confusing to me, as is ends in an "Error" message. So I don't understand why you say that it has worked?
Does a
klist -kt /etc/krb5.keytab
show an updated keytab after msktutil --auto-update was run?
In our setup, we have a 30 day password expiry setting in the ad controller. A Cronjob runs msktutil --auto-update once a day (it actually updates the keytab only after it expires) and that is sufficient to keep our machines (Ubuntu 14, 15 + opensuse) in the domain without any further action.
-Joschi
Am 17.12.2015 um 18:40 schrieb Thackeray, Neil L neilt@illinois.edu:
I am having a frustrating time trying to figure out what is going on with these Ubuntu servers. I have tried to use msktutil as some have suggested, but this hasn’t worked for me. Every 7 days on the mark I lose my domain connection and have to run realm leave/realm join again. I ran msktutil the day before the ticket was about to expire, so it should have worked. This is only a problem on Ubuntu, CentOS works perfectly fine. I even have one Ubuntu server that works.
I also have the problem that the sssd init script, wherever that is now, sometimes thinks that sssd is still running and won’t start again. I then have to run ‘sssd –D’ if I don’t want to restart the server.
This is what I get running msktutil.
msktutil --auto-update --verbose:
-- init_password: Wiping the computer password structure
-- generate_new_password: Generating a new, random password for the computer account
-- generate_new_password: Characters read from /dev/udandom = 86
-- get_dc_host: Attempting to find a Domain Controller to use (DNS SRV RR TCP)
-- get_dc_host: Found DC: udc05.ad.mydomain.com https://urldefense.proofpoint.com/v2/url?u=http-3A__udc05.ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=qTlkw1hgmA_n9I9okLFglcZD8555xAuTKXvxigNopdg&e=
-- get_dc_host: Canonicalizing DC through forward/reverse lookup...
-- get_dc_host: Found Domain Controller: udc05.ad.mydomain.com https://urldefense.proofpoint.com/v2/url?u=http-3A__udc05.ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=qTlkw1hgmA_n9I9okLFglcZD8555xAuTKXvxigNopdg&e=
-- get_default_keytab: Obtaining the default keytab name: FILE:/etc/krb5.keytab
-- create_fake_krb5_conf: Created a fake krb5.conf file: /tmp/.msktkrb5.conf-TSzpEQ
-- reload: Reloading Kerberos Context
-- get_short_hostname: Determined short hostname: myserver-domain-foo-com
Error: The SAM name (myserver-domain-foo-com$) for this host is longer than the maximum of MAX_SAM_ACCOUNT_LEN characters
You can specify a shorter name using --computer-name
-- ~KRB5Context: Destroying Kerberos Context
This appears to have worked, but it didn’t.
msktutil --update --computer-name MYSERVER --verbose:
-- init_password: Wiping the computer password structure
-- generate_new_password: Generating a new, random password for the computer account
-- generate_new_password: Characters read from /dev/udandom = 82
-- get_dc_host: Attempting to find a Domain Controller to use (DNS SRV RR TCP)
-- get_dc_host: Found DC: udc05.ad.mydomain.com https://urldefense.proofpoint.com/v2/url?u=http-3A__udc05.ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=qTlkw1hgmA_n9I9okLFglcZD8555xAuTKXvxigNopdg&e=
-- get_dc_host: Canonicalizing DC through forward/reverse lookup...
-- get_dc_host: Found Domain Controller: udc05.ad.mydomain.com https://urldefense.proofpoint.com/v2/url?u=http-3A__udc05.ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=qTlkw1hgmA_n9I9okLFglcZD8555xAuTKXvxigNopdg&e=
-- get_default_keytab: Obtaining the default keytab name: FILE:/etc/krb5.keytab
-- create_fake_krb5_conf: Created a fake krb5.conf file: /tmp/.msktkrb5.conf-ozv4A6
-- reload: Reloading Kerberos Context
-- finalize_exec: SAM Account Name is: MYSERVER$
-- try_machine_keytab_princ: Trying to authenticate for MYSERVER$ from local keytab...
-- switch_default_ccache: Using the local credential cache: FILE:/tmp/.mskt_krb5_ccache-ewj6uW
-- finalize_exec: Authenticated using method 1
-- ldap_connect: Connecting to LDAP server: udc05.ad.mydomain.com https://urldefense.proofpoint.com/v2/url?u=http-3A__udc05.ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=qTlkw1hgmA_n9I9okLFglcZD8555xAuTKXvxigNopdg&e= try_tls=YES
-- ldap_connect: Connecting to LDAP server: udc05.ad.mydomain.com https://urldefense.proofpoint.com/v2/url?u=http-3A__udc05.ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=qTlkw1hgmA_n9I9okLFglcZD8555xAuTKXvxigNopdg&e= try_tls=NO
SASL/GSSAPI authentication started
SASL username: MYSERVER$@AD.MYDOMAIN.COM MYSERVER$@ad.mydomain.com
SASL SSF: 56
SASL data security layer installed.
-- ldap_connect: LDAP_OPT_X_SASL_SSF=56
This is what I think is the pertinent portions of the logs from when the computer cant connect anymore.
sssd_ad.mydomain.com.log:
(Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.com https://urldefense.proofpoint.com/v2/url?u=http-3A__ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=lHp3WJ7Bw0Wvt377k8g1H4JgdrM82FmTJoMmluWqTQE&e=]]] [sdap_get_tgt_recv] (0x0400): Child responded: 14 [Preauthentication failed], expired on [0]
(Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.com https://urldefense.proofpoint.com/v2/url?u=http-3A__ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=lHp3WJ7Bw0Wvt377k8g1H4JgdrM82FmTJoMmluWqTQE&e=]]] [sdap_kinit_done] (0x0100): Could not get TGT: 14 [Bad address]
(Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.com https://urldefense.proofpoint.com/v2/url?u=http-3A__ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=lHp3WJ7Bw0Wvt377k8g1H4JgdrM82FmTJoMmluWqTQE&e=]]] [sdap_cli_kinit_done] (0x0400): Cannot get a TGT: ret [1432158219](Authentication Failed)
(Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.com https://urldefense.proofpoint.com/v2/url?u=http-3A__ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=lHp3WJ7Bw0Wvt377k8g1H4JgdrM82FmTJoMmluWqTQE&e=]]] [fo_set_port_status] (0x0100): Marking port 389 of server ' udc02.ad.mydomain.com https://urldefense.proofpoint.com/v2/url?u=http-3A__udc02.ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=snoF_MvPwCM79eFbcPTZcLYKlg63XjLJwZAO0xR4Qvs&e=' as 'not working'
(Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.com https://urldefense.proofpoint.com/v2/url?u=http-3A__ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=lHp3WJ7Bw0Wvt377k8g1H4JgdrM82FmTJoMmluWqTQE&e=]]] [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP
(Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.com https://urldefense.proofpoint.com/v2/url?u=http-3A__ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=lHp3WJ7Bw0Wvt377k8g1H4JgdrM82FmTJoMmluWqTQE&e=]]] [fo_set_port_status] (0x0400): Marking port 389 of duplicate server ' udc02.ad.mydomain.com https://urldefense.proofpoint.com/v2/url?u=http-3A__udc02.ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=snoF_MvPwCM79eFbcPTZcLYKlg63XjLJwZAO0xR4Qvs&e=' as 'not working'
syslog:
Nov 4 15:26:09 myserver [sssd[ldap_child[25833]]]: Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection.
Nov 4 15:26:09 myserver [sssd[ldap_child[25833]]]: Preauthentication failed
Any help is appreciated.
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.org_admin_lists_sssd-2Dusers-40lists.fedorahosted.org&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=2xj7MBN63EQQlXOVUffSey4fJsXx2jb4kKMUOKfsthk&e=
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
On Tue, 5 Jan 2016, Andy Airey wrote:
Hello,
I am getting the same errors in syslog on CentOS 6.7 and 7.1.
When I issue a plain 'klist /etc/krb5.keytab' I get the following:
klist: Bad format in credentials cache
However 'klist -ke' and the like are working, I was wondering if you are seeing the same Neil? Maybe because of this bad format, sssd cannot read it and thus it is an msktutil issue? Maybe we can circumvent this by using some option with msktutil?
That's not in any way broken, surely?
klist -k some.keytab klist some.keycache klist -c some.keycache
The output of kinit is a cache, the contents of a keytab are not.
jh
I'm sorry, but it looks like SSSD is having trouble reading /etc/krb5.keytab when msktutil has been run.
On a machine with a good keytab you get the following when issuing klist '/etc/krb5.keytab'
klist: End of credential cache reached
Regards,
Andy
On 5 January 2016 at 11:24, John Hodrien J.H.Hodrien@leeds.ac.uk wrote:
On Tue, 5 Jan 2016, Andy Airey wrote:
Hello,
I am getting the same errors in syslog on CentOS 6.7 and 7.1.
When I issue a plain 'klist /etc/krb5.keytab' I get the following:
klist: Bad format in credentials cache
However 'klist -ke' and the like are working, I was wondering if you are seeing the same Neil? Maybe because of this bad format, sssd cannot read it and thus it is an msktutil issue? Maybe we can circumvent this by using some option with msktutil?
That's not in any way broken, surely?
klist -k some.keytab klist some.keycache klist -c some.keycache
The output of kinit is a cache, the contents of a keytab are not.
jh
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
On Tue, Jan 05, 2016 at 11:40:50AM +0100, Andy Airey wrote:
I'm sorry, but it looks like SSSD is having trouble reading /etc/krb5.keytab when msktutil has been run.
On a machine with a good keytab you get the following when issuing klist '/etc/krb5.keytab'
While it is of course possible that SSSD has issues reading the keytab[1] it is as John said. If you want to read a keytab you have to use 'klist -k' because by default klist expects a credential cache (a storage for tickets) and not a keytab (a storage for keys).
[1] Do you see any evidence in the SSSD logs that there a issues reading the keytab? If any I would expect that SSSD picks the wrong key for some operations. This might happen in an environment like AD with multiple different domains and realms. Here SSSD might not be able to find a key for given realm and might pick the first or last entry from the keytab and try this. Since msktutil might add the new keys in a different order it might be possible that it might work for some time and fails after msktutil is run. But as said before, to be sure the SSSD logs must be inspected.
bye, Sumit
klist: End of credential cache reached
Regards,
Andy
On 5 January 2016 at 11:24, John Hodrien J.H.Hodrien@leeds.ac.uk wrote:
On Tue, 5 Jan 2016, Andy Airey wrote:
Hello,
I am getting the same errors in syslog on CentOS 6.7 and 7.1.
When I issue a plain 'klist /etc/krb5.keytab' I get the following:
klist: Bad format in credentials cache
However 'klist -ke' and the like are working, I was wondering if you are seeing the same Neil? Maybe because of this bad format, sssd cannot read it and thus it is an msktutil issue? Maybe we can circumvent this by using some option with msktutil?
That's not in any way broken, surely?
klist -k some.keytab klist some.keycache klist -c some.keycache
The output of kinit is a cache, the contents of a keytab are not.
jh
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
On Tue, 5 Jan 2016, Andy Airey wrote:
I'm sorry, but it looks like SSSD is having trouble reading /etc/krb5.keytab when msktutil has been run.
On a machine with a good keytab you get the following when issuing klist '/etc/krb5.keytab'
klist: End of credential cache reached
I don't think you're diagnosing this right. /etc/krb5.keytab is *not* a credential cache, it's a keytab. These are different things.
This is correct:
klist -k /etc/krb5.keytab
This is correct:
klist -c /tmp/krb5cc_87233
These are incorrect:
klist /etc/krb5.keytab klist -c /etc/krb5.keytab klist -k /tmp/krb5cc_87233
jh
Hey Joschi,
I was away on holiday so I wasn’t able to get back to this. msktutil –auto-update doesn’t work because it’s getting the wrong name. It’s trying to use the dns name which when msktutil tries to use it ends up being in the format myserver-domain-foo-com$. This is the output: Error: The SAM name (myserver-domain-foo-com$) for this host is longer than the maximum of MAX_SAM_ACCOUNT_LEN characters So I use ‘msktutil --update --computer-name MYSERVER –verbose’, which seems to run if you look below, but doesn’t seem to really update the actual keytab. It does not update the keytab after it is run, all the dates stay the same. The last time I tried running msktutil before the password expired it was a day before expiration, and it didn’t work. I don’t have it in a cron running daily. I’m stuck with a 7 day renewal, since I don’t run the AD.
Neil
From: Joschi Brauchle [mailto:joschi.brauchle@tum.demailto:joschi.brauchle@tum.de] Sent: Thursday, December 17, 2015 1:12 PM To: End-user discussions about the System Security Services Daemon <sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org> Subject: [SSSD-users] Re: Ticket expiring problems still
Hi Neil,
First of all, sorry for entering the discussion without having read all previous thread messages. I may duplicate some content.
Your first msktutil output is confusing to me, as is ends in an "Error" message. So I don't understand why you say that it has worked?
Does a klist -kt /etc/krb5.keytab show an updated keytab after msktutil --auto-update was run?
In our setup, we have a 30 day password expiry setting in the ad controller. A Cronjob runs msktutil --auto-update once a day (it actually updates the keytab only after it expires) and that is sufficient to keep our machines (Ubuntu 14, 15 + opensuse) in the domain without any further action.
-Joschi
Am 17.12.2015 um 18:40 schrieb Thackeray, Neil L <neilt@illinois.edumailto:neilt@illinois.edu>: I am having a frustrating time trying to figure out what is going on with these Ubuntu servers. I have tried to use msktutil as some have suggested, but this hasn’t worked for me. Every 7 days on the mark I lose my domain connection and have to run realm leave/realm join again. I ran msktutil the day before the ticket was about to expire, so it should have worked. This is only a problem on Ubuntu, CentOS works perfectly fine. I even have one Ubuntu server that works.
I also have the problem that the sssd init script, wherever that is now, sometimes thinks that sssd is still running and won’t start again. I then have to run ‘sssd –D’ if I don’t want to restart the server.
This is what I get running msktutil. msktutil --auto-update --verbose: -- init_password: Wiping the computer password structure -- generate_new_password: Generating a new, random password for the computer account -- generate_new_password: Characters read from /dev/udandom = 86 -- get_dc_host: Attempting to find a Domain Controller to use (DNS SRV RR TCP) -- get_dc_host: Found DC: udc05.ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__udc05.ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=qTlkw1hgmA_n9I9okLFglcZD8555xAuTKXvxigNopdg&e= -- get_dc_host: Canonicalizing DC through forward/reverse lookup... -- get_dc_host: Found Domain Controller: udc05.ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__udc05.ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=qTlkw1hgmA_n9I9okLFglcZD8555xAuTKXvxigNopdg&e= -- get_default_keytab: Obtaining the default keytab name: FILE:/etc/krb5.keytab -- create_fake_krb5_conf: Created a fake krb5.conf file: /tmp/.msktkrb5.conf-TSzpEQ -- reload: Reloading Kerberos Context -- get_short_hostname: Determined short hostname: myserver-domain-foo-com Error: The SAM name (myserver-domain-foo-com$) for this host is longer than the maximum of MAX_SAM_ACCOUNT_LEN characters You can specify a shorter name using --computer-name -- ~KRB5Context: Destroying Kerberos Context
This appears to have worked, but it didn’t. msktutil --update --computer-name MYSERVER --verbose: -- init_password: Wiping the computer password structure -- generate_new_password: Generating a new, random password for the computer account -- generate_new_password: Characters read from /dev/udandom = 82 -- get_dc_host: Attempting to find a Domain Controller to use (DNS SRV RR TCP) -- get_dc_host: Found DC: udc05.ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__udc05.ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=qTlkw1hgmA_n9I9okLFglcZD8555xAuTKXvxigNopdg&e= -- get_dc_host: Canonicalizing DC through forward/reverse lookup... -- get_dc_host: Found Domain Controller: udc05.ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__udc05.ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=qTlkw1hgmA_n9I9okLFglcZD8555xAuTKXvxigNopdg&e= -- get_default_keytab: Obtaining the default keytab name: FILE:/etc/krb5.keytab -- create_fake_krb5_conf: Created a fake krb5.conf file: /tmp/.msktkrb5.conf-ozv4A6 -- reload: Reloading Kerberos Context -- finalize_exec: SAM Account Name is: MYSERVER$ -- try_machine_keytab_princ: Trying to authenticate for MYSERVER$ from local keytab... -- switch_default_ccache: Using the local credential cache: FILE:/tmp/.mskt_krb5_ccache-ewj6uW -- finalize_exec: Authenticated using method 1
-- ldap_connect: Connecting to LDAP server: udc05.ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__udc05.ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=qTlkw1hgmA_n9I9okLFglcZD8555xAuTKXvxigNopdg&e= try_tls=YES -- ldap_connect: Connecting to LDAP server: udc05.ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__udc05.ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=qTlkw1hgmA_n9I9okLFglcZD8555xAuTKXvxigNopdg&e= try_tls=NO SASL/GSSAPI authentication started SASL username: MYSERVER$@AD.MYDOMAIN.COMmailto:MYSERVER$@ad.mydomain.com SASL SSF: 56 SASL data security layer installed. -- ldap_connect: LDAP_OPT_X_SASL_SSF=56
This is what I think is the pertinent portions of the logs from when the computer cant connect anymore. sssd_ad.mydomain.com.log: (Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=lHp3WJ7Bw0Wvt377k8g1H4JgdrM82FmTJoMmluWqTQE&e=]]] [sdap_get_tgt_recv] (0x0400): Child responded: 14 [Preauthentication failed], expired on [0] (Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=lHp3WJ7Bw0Wvt377k8g1H4JgdrM82FmTJoMmluWqTQE&e=]]] [sdap_kinit_done] (0x0100): Could not get TGT: 14 [Bad address] (Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=lHp3WJ7Bw0Wvt377k8g1H4JgdrM82FmTJoMmluWqTQE&e=]]] [sdap_cli_kinit_done] (0x0400): Cannot get a TGT: ret [1432158219](Authentication Failed) (Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=lHp3WJ7Bw0Wvt377k8g1H4JgdrM82FmTJoMmluWqTQE&e=]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'udc02.ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__udc02.ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=snoF_MvPwCM79eFbcPTZcLYKlg63XjLJwZAO0xR4Qvs&e=' as 'not working' (Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=lHp3WJ7Bw0Wvt377k8g1H4JgdrM82FmTJoMmluWqTQE&e=]]] [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP (Wed Nov 4 15:26:09 2015) [sssd[be[ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=lHp3WJ7Bw0Wvt377k8g1H4JgdrM82FmTJoMmluWqTQE&e=]]] [fo_set_port_status] (0x0400): Marking port 389 of duplicate server 'udc02.ad.mydomain.comhttps://urldefense.proofpoint.com/v2/url?u=http-3A__udc02.ad.mydomain.com&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=snoF_MvPwCM79eFbcPTZcLYKlg63XjLJwZAO0xR4Qvs&e=' as 'not working'
syslog: Nov 4 15:26:09 myserver [sssd[ldap_child[25833]]]: Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Preauthentication failed. Unable to create GSSAPI-encrypted LDAP connection. Nov 4 15:26:09 myserver [sssd[ldap_child[25833]]]: Preauthentication failed
Any help is appreciated. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.orghttps://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.org_admin_lists_sssd-2Dusers-40lists.fedorahosted.org&d=BQMF-g&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=zkNHhN52-zwRT7x8kkfGmAeFJxxAD8j2jvMB7yh9miE&s=2xj7MBN63EQQlXOVUffSey4fJsXx2jb4kKMUOKfsthk&e=
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.orgmailto:sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.orghttps://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.org_admin_lists_sssd-2Dusers-40lists.fedorahosted.org&d=BQMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=s5tDmtNCDZl57cCxwg2KM4xI8Zqq9x-22CrUmJI7h7M&m=xGgS-18qxUa3nbhUcrTQLNRnKOqZi77DQ8HPAyHlnis&s=oNVI6YZJ6ApAanbVaqFTQ7W-JZAMbF-9aa_WjGOujPQ&e=
sssd-users@lists.fedorahosted.org
-
Andy Airey -
John Hodrien -
Joschi Brauchle -
Sumit Bose -
Thackeray, Neil L