David,

The easiest solution to this problem is to use the ktpass which was
shipped with Windows 2003, and not the one with SP1.

Alternatively, you can use one of the many tools available that replace
the need for ktpass, and use computer accounts for key storage. These
tools do not suffer from the same issues as ktpass.

It seems that the sp1 version of ktpass stores a key with a specific
kvno in the keytab file, and the kvno in the domain controller for the
same principal is different. This is why you cannot use the keytab file
to authenticate.

Thanks, Tim 

-----Original Message-----
From: kerberos-bounces@mit.edu [mailto:kerberos-bounces@mit.edu] On
Behalf Of David Telfer
Sent: 22 March 2006 17:09
To: kerberos@mit.edu
Subject: kinit request on keytab fails using 2K3sp1 KDC

Hello,

I am testing a keytab obtained from a Windows 2003 Server (sp1) prior to

configuring mod_auth_kerb.  I have used the following command to 
generate a keytab on the KDC;
ktpass -mapuser intsvcuser@smg.plc.uk -princ 
HTTP/connect.smg.plc.uk@SMG.PLC.UK +DesOnly -pass userspassword -ptype 
KRB5_NT_PRINCIPAL -crypto DES-CBC-MD5 -out "c:\krb5.keytab"

The *nix server is running Solaris 9 with MIT krb5-1.4.3.  I have 
transfered the keytab to /etc/krb5.keytab.  When I run ;
#/usr/local/bin/kinit -k -t /etc/krb5.keytab 
HTTP/connect.smg.plc.uk@SMG.PLC.UK

I get the following error;
kinit(v5): Preauthentication failed while getting initial credentials

I am able to obtain a ticket directly from the kdc using #./kinit 
DavidTelfer@SMG.PLC.UK which would indicate that the problem wasn't a 
clock slew error (I haven't seen an error of this nature appear with 
this version of krb so I'm not sure whether it would explicitly state
this).

 From reading a few mailing list posts I have discovered some people 
having issues with ktpass on service pack 1.  One such post;
http://groups.google.com/group/comp.protocols.kerberos/browse_thread/thr
ead/1c991fa1b6ea4ef8/3da9428688c66d72%233da9428688c66d72
details a similar problem  I have followed the advice given, ensuring 
that the kvno's match and changing the system users password prior to 
generating the keytab but to no avail.

My /etc/krb5.conf file is as follows (I've removed every non-essential 
entry to ensure that it isn't the issue);

[libdefaults]
        default_realm = SMG.PLC.UK
[domain_realm]
        connect.smg.plc.uk = SMG.PLC.UK
[realms]
        SMG.PLC.UK = {
                kdc = pqdomc01.smg.plc.uk
                admin_server = pqdomc01.smg.plc.uk
                default_domain = smg.plc.uk
        }

Has anyone experienced a similar problem to this?  I have to assume 
there is a problem with the keytab but I'm at a loss as to what the 
problem could be.

David Telfer
david@2fluid.co.uk




________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

>>>>> "TA" == "Tim Alsop" <Tim.Alsop@cybersafe.com> writes:

    TA> It seems that the sp1 version of ktpass stores a key with a
    TA> specific kvno in the keytab file, and the kvno in the domain
    TA> controller for the same principal is different. This is why you
    TA> cannot use the keytab file to authenticate.

Yes; it always sets the kvno in the keytab it writes to 1, regardless of
the value in the KDB (which of course changes each time the key is
extracted).  So, you can only use the keytab the first time you extract
it.  If you have to do it again, just delete the principal and re-create
it.

-- 
  Richard Silverman
  res@qoxp.net

On Wednesday 22 March 2006 18:19, Tim Alsop wrote:

> Alternatively, you can use one of the many tools available that replace
> the need for ktpass, and use computer accounts for key storage. These
> tools do not suffer from the same issues as ktpass.

What are that tools?
Can you send searchkeywords or pointers so I can find and use them?

Thank you,
Achim
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Richard E. Silverman wrote:
>>>>>> "TA" == "Tim Alsop" <Tim.Alsop@cybersafe.com> writes:
> 
>     TA> It seems that the sp1 version of ktpass stores a key with a
>     TA> specific kvno in the keytab file, and the kvno in the domain
>     TA> controller for the same principal is different. This is why you
>     TA> cannot use the keytab file to authenticate.
> 
> Yes; it always sets the kvno in the keytab it writes to 1, regardless of
> the value in the KDB (which of course changes each time the key is
> extracted).  So, you can only use the keytab the first time you extract
> it.  If you have to do it again, just delete the principal and re-create
> it.

ktpass allows you to specify the kvno on the command line.
You can obtain the kvno for the service principal with the MIT kvno utility.

Jeffrey Altman

>>>>> "JA" == Jeffrey Altman <jaltman2@nyc.rr.com> writes:

    JA> Richard E. Silverman wrote:
    >>>>>>> "TA" == "Tim Alsop" <Tim.Alsop@cybersafe.com> writes:
    >>
    TA> It seems that the sp1 version of ktpass stores a key with a
    TA> specific kvno in the keytab file, and the kvno in the domain
    TA> controller for the same principal is different. This is why you
    TA> cannot use the keytab file to authenticate.
    >>  Yes; it always sets the kvno in the keytab it writes to 1,
    >> regardless of the value in the KDB (which of course changes each
    >> time the key is extracted).  So, you can only use the keytab the
    >> first time you extract it.  If you have to do it again, just delete
    >> the principal and re-create it.

    JA> ktpass allows you to specify the kvno on the command line.  You
    JA> can obtain the kvno for the service principal with the MIT kvno
    JA> utility.

Somehow I never noticed that, probably because I couldn't imagine why
you'd need such a thing.  :)  Thanks.

    JA> Jeffrey Altman

-- 
  Richard Silverman
  res@qoxp.net

Achim Grolms wrote:

> On Wednesday 22 March 2006 18:19, Tim Alsop wrote:
> 
> 
>>Alternatively, you can use one of the many tools available that replace
>>the need for ktpass, and use computer accounts for key storage. These
>>tools do not suffer from the same issues as ktpass.
> 
> 
> What are that tools?
> Can you send searchkeywords or pointers so I can find and use them?

Google for msktutil  which will get you to
http://www.pppl.gov/~dperry/mskturil-0.3.16.tar.gz
We are using this.

Goolge for netjoin
This is an update of the MS netjoin.

Samba has some tools, but adds too many principal in many cases.



Something else that can be very helpfull is to use
the Windows mmc with the ADSI edit to lok at the registry.
You can look at the account that was created, and look at the KVNO
as the ms-DS-KeyVersionNumber.
Other interesting fields are the userPrincipalName,
and servicePrincipalName.

Keep in mind that the Windows has a single password that
is used to generate the keys on the fly for each of the
principals (userPrincipalName and servicePrincipalName)
asociated with the account.

Kerberos uses a seperate key for each principal created when the
kettrab is created. So if you change the password on the account,
you have to change the keys in the keytab at the same time for
all the principal assiciated with that account.

Msktutil tries to do this for your.



> 
> Thank you,
> Achim
> ________________________________________________
> Kerberos mailing list           Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 
> 

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos