> Looking at your email again. You say your hostname is > 3msydproxy01.example.local including the domain. So it should have worked. > > I think the problem is that ou don't use the -s HTTP switch for the auto > update as I see msktutils tries to authenticate as host/<fqdn> instead of > HTTP/<fqdn> and get correctly the reply there is not client with that UPN. > Because I reset the account in AD doesn't that mean the only method that would work is the try_machine_password method? (Sorry about the line wrap, it's a gmail thing you cannot disable in plain text... grr) # hostname -f 3msydproxy01.example.local ## Create account command using computer name 3MSYDPROXY01-HTTP # msktutil -c -b "ou=MEMBER SERVERS,ou=EXAMPLE" -s HTTP/3msydproxy01.example.local -k /etc/squid3/PROXY.keytab \ --computer-name 3MSYDPROXY01-HTTP --upn HTTP/3msydproxy01.example.local --server dc1.example.local --verbose --enctypes 28 ## auto update command after account reset in AD (and kdestroy) # msktutil --auto-update --verbose --computer-name 3msydproxy01-http --server dc1.example.local -s HTTP/3msydproxy01.example.local ... -- try_machine_password: Trying to authenticate for 3msydproxy01-http$ with password. -- try_machine_password: Error: krb5_get_init_creds_keytab failed (Preauthentication failed) -- try_machine_password: Authentication with password failed ... Whereas, if I create the computer name to match the machines hostname msktutil --auto-update works. ## Create account command using computer name 3MSYDPROXY01 # msktutil -c -b "ou=MEMBER SERVERS,ou=EXAMPLE" -s HTTP/3msydproxy01.example.local -k /etc/squid3/PROXY.keytab \ --computer-name 3MSYDPROXY01 --upn HTTP/3msydproxy01.example.local --server dc1.example.local --verbose --enctypes 28 ## auto update command after account reset in AD (and kdestroy) # msktutil --auto-update --verbose --computer-name 3msydproxy01 --server dc1.example.local -s HTTP/3msydproxy01.example.local ... -- try_machine_password: Trying to authenticate for 3msydproxy01$ with password. -- switch_default_ccache: Using the local credential cache: FILE:/tmp/.mskt_krb5_ccache-aSNdFw -- finalize_exec: Authenticated using method 3 -- ldap_connect: Connecting to LDAP server: dc1.example.local try_tls=YES -- ldap_connect: Connecting to LDAP server: dc1.example.local try_tls=NO SASL/GSSAPI authentication started SASL username: 3msydproxy01$@example.local SASL SSF: 56 SASL data security layer installed. ... Perhaps this is a bug in msktutil?