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

-- 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.

_______________________________________________
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org