Re: [squid-users] Re: Re: Kerberos with LDAP authentication failover and iTunes auth problems

>
> 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.
Received on Thu Jan 05 2012 - 00:23:12 MST