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

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.

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

"Markus Moeller" <huaraz_at_moeller.plus.com> wrote in message
news:je4600$4bd$1_at_dough.gmane.org...
> It could be because of the wrong use of msktutil. The -s option require
> HTP/<fqdn>.
>
> msktutil --help shows:
>
> -s, --service <name> Adds the service <name> for the current host.
> The service is of the form <service>/<hostname>.
> If the hostname is omitted, assumes current
> hostname.
> Markus
>
> "James Robertson" <j_at_mesrobertson.com> wrote in message
> news:CAMALoy_r0Me_7HXCYs0-oKTowDMp-7JgD+fARGv4RNmO60QS7A_at_mail.gmail.com...
>> >
>>> 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 - 13:23:33 MST