> > You should use two different computer accounts. For Kerberos the machine > name does not matter only the user- and service-principalname is of > importance. So use net ads join <computername> and for msktutil use > something like <computername>-HTTP as computername. > > The issue with using the same name is that samba runs a daemon which > regularly changes the computer account password and thereby also changes the > Kerberos key making the keytab with the extracted Kerberos key invalid. Many > people use user accounts instead of computer accounts because they use thw > MS ktpass tool which only works with user accounts, whereas msktutil can > work with computer accounts. I dislike user accounts as you may have to > create exceptions to your domain password policy for users (e.g. don't > expire password). > I have tried to create a separate account for Kerberos using msktutil but I am having some problems. If I use a computer account name 3MSYDPROXY01-HTTP (where the hostname of the proxy is 3msydproxy01.example.local) I can never get msktutil --autoupdate to work after resetting the account in AD because the try_machine_password step in msktutil always fails. If the computer account name matches the hostname it works fine. I have been doing the following for testing: Check no existing tickets exist # kdestroy Remove the existing keytab to start fresh (this is the location referenced in /etc/krb5.conf) # rm /etc/squid3/PROXY.keytab Delete the account on the domain using dc1.example.local Obtain a new ticket using administrator account # kinit administrator Add the proxy to the domain with the name "3MSYDPROXY01-HTTP" (SPN and UPN are based on the hostname) - the process works to add the computer account. # msktutil -c -b "ou=MEMBER SERVERS,ou=EXAMPLE" -s HTTP -k /etc/squid3/PROXY.keytab --computer-name 3MSYDPROXY01-HTTP \ --upn HTTP/3msydproxy01.example.local --server dc1.example.local --verbose --enctypes 28 Destroy the administrator ticket # kdestroy Reset the computer account in AD using dc1.example.local Run msktutil --auto-update and show output # msktutil --auto-update --verbose --computer-name 3msydproxy01-http --server dc1.example.local -- init_password: Wiping the computer password structure -- get_default_keytab: Obtaining the default keytab name: /etc/squid3/PROXY.keytab -- create_fake_krb5_conf: Created a fake krb5.conf file: /tmp/.msktkrb5.conf-VHa0ko -- reload: Reloading Kerberos Context -- finalize_exec: SAM Account Name is: 3msydproxy01-http$ -- try_machine_keytab_princ: Trying to authenticate for 3msydproxy01-http$ from local keytab... -- try_machine_keytab_princ: Error: krb5_get_init_creds_keytab failed (Preauthentication failed) -- try_machine_keytab_princ: Authentication with keytab failed -- try_machine_keytab_princ: Trying to authenticate for host/3msydproxy01.example.local from local keytab... -- try_machine_keytab_princ: Error: krb5_get_init_creds_keytab failed (Client not found in Kerberos database) -- try_machine_keytab_princ: Authentication with keytab failed -- 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 -- try_user_creds: Checking if default ticket cache has tickets... -- try_user_creds: Error: krb5_cc_get_principal failed (No credentials cache found) -- try_user_creds: User ticket cache was not valid. Error: could not find any credentials to authenticate with. Neither keytab, default machine password, nor calling user's tickets worked. Try "kinit"ing yourself some tickets with permission to create computer objects, or pre-creating the computer object in AD and selecting 'reset account'. -- ~KRB5Context: Destroying Kerberos Context I would make one point here: When using the proxy's hostname for kerberos i.e. 3msydproxy01 instead of 3msydproxy01-http it works fine and the try_machine_password step works as long as the --computer-name is lower case (I can ommit the --computer-name option and it works also obviously). I tried adding 3msydproxy01-http in upper case and lower case to AD and upper and lower case in the msktutil command and neither method works. I also tried with the SPN and UPN as 3msydproxy01-http.example.local but this made no difference (and from my understanding would have nothing to do with the try_machine_password msktutil step anyway). I am using msktutil from here http://fuhm.net/software/msktutil/releases/ This may not be a problem as long as the computer account is never reset but I need to cover all possible outcomes.