Re: [modauthkerb] Keytab not readable? Can't authenticate workstation for SSO

[Douglas E. E. <dee...@an...>]

On 11/1/2013 10:56 AM, Martin Yves wrote:
>    Hello Douglas,
>
> Personally, the "service account" I created for SPN and keytab
> generation is also used to authenticate LDAP queries...
> As far as password does not expire and is correct, I discover no
> troubles about it.
>
> To sum up for Jim, here are some tasks I think about:
>
> - if the "user account" holding the SPN and used to generate
>    keytab is not a specific service account,
>    it is worth to delete it and create it again...
>
> - create a dedicated "service account" (standard account but
>    dedicated to Kerberos SSO) in AD and create keytab
>
> - check and clean duplicates SPN
>
> - do not use default location /etc/krb5.keytab but (for instance)
>    /etc/apache2/http-arecord.keytab

Yes. Check ownership, only readable by apache server.
>
> - validates SPN with kinit/kvno:
>
> $ kinit MeMyselfI
> $ kvno HTTP/arecord.mysite.com
>
> $ kdestroy
> $ kinit HTTP/arecord.mysite.com
>   => check password authentication with "service account" password
>
> $ kdestroy
> $ kinit -k -t /etc/apache2/http-arecord.keytab HTTP/arecord.mysite.com
>   => is equivalent to the previous one but password comes from keytab
>
>
> If all that diagnostic steps pass, there is no reason Apache2 cannot
> accept your token from your browser... Or else you have a big trouble
> in Apache2/mod_auth_kerb. You should provide use with details about it.
>
>
> For a reason I have not found yet, few months ago, with Debian Wheezy
> mod_auth_kerb 5.4-2 and DC AD 2008, I had to explicitly set
> "KrbServiceName HTTP/arecord.mysite.com" instead of default "HTTP"
> to get my system to load keytab. It no longer "guess" expected SPN
> probably because our network was in a migration from one domain to
> another. I just checked and that trick is no longer required, defaults
> works.
>

A few years ago, there was a problem with a version of ktpass. Make sure you have
the latest.

If you are running 2008R2 it could be the DC is generating a service ticket with
with AES-256 key, but the key table does not have one.

The AD attribute to look at is msDS-SupportedEncryptionTypes
http://msdn.microsoft.com/en-us/library/cc223853.aspx

http://blogs.msdn.com/b/openspecification/archive/2011/05/31/windows-configurations-for-kerberos-supported-encryption-type.aspx


If you change the service account paassword, you must also change the keytab.
You must also destroy any cached service tickets for the service.
If the  test client is Windows you will need to logoff an back on again.


>
> Hope this helps
>

-- 

  Douglas E. Engert  <DEE...@an...>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444