RE: kinit request on keytab fails using 2K3sp1 KDC - Kerberos

This is a discussion on RE: kinit request on keytab fails using 2K3sp1 KDC - Kerberos ; 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, ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: RE: kinit request on keytab fails using 2K3sp1 KDC

  1. RE: kinit request on keytab fails using 2K3sp1 KDC

    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....wse_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


  2. Re: kinit request on keytab fails using 2K3sp1 KDC

    >>>>> "TA" == "Tim Alsop" 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



  3. Re: kinit request on keytab fails using 2K3sp1 KDC

    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


  4. Re: kinit request on keytab fails using 2K3sp1 KDC

    Richard E. Silverman wrote:
    >>>>>> "TA" == "Tim Alsop" 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

  5. Re: kinit request on keytab fails using 2K3sp1 KDC

    >>>>> "JA" == Jeffrey Altman writes:

    JA> Richard E. Silverman wrote:
    >>>>>>> "TA" == "Tim Alsop" 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


  6. Re: kinit request on keytab fails using 2K3sp1 KDC

    Richard E. Silverman wrote:
    >
    > 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.

    I am not sure whether this is the issue or not, I may be doing something
    wrong but I have used the following procedure to determine the kvno of
    both the keytab and the service principal.

    To determine the KDC principal kvno;

    #./kinit HTTP/connect.smg.plc.uk@SMG.PLC.UK
    --->prompted for system user password
    #./kvno HTTP/connect.smg.plc.uk@SMG.PLC.UK
    HTTP/connect.smg.plc.uk@SMG.PLC.UK: kvno = 3

    To determine the keytab kvno;

    # /usr/local/sbin/ktutil
    ktutil: rkt /etc/krb5.keytab
    ktutil: list
    slot KVNO Principal
    ---- ----
    ---------------------------------------------------------------------
    1 3 HTTP/connect.smg.plc.uk@SMG.PLC.UK

    This is the step I am unsure of, but I believe it indicates that the
    keytab also has a KVNO of 3. Is this correct?

    Also, for each creation of the keytab I am deleting the system user and
    service principal first before creation. Should this not reset the kvno
    back to the initial value?

    Thanks,
    David Telfer


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


  7. Re: kinit request on keytab fails using 2K3sp1 KDC

    David Telfer wrote:
    > To determine the keytab kvno;
    >
    > # /usr/local/sbin/ktutil
    > ktutil: rkt /etc/krb5.keytab
    > ktutil: list
    > slot KVNO Principal
    > ---- ----
    > ---------------------------------------------------------------------
    > 1 3 HTTP/connect.smg.plc.uk@SMG.PLC.UK
    >
    > This is the step I am unsure of, but I believe it indicates that the
    > keytab also has a KVNO of 3. Is this correct?
    >

    To clarify this, I have realised that I was jumping through too many
    hoops to determine the kvno of the keytab file.

    I should have used;
    #./klist -k /etc/krb5.keytab

    This returns;

    Keytab name: FILE:/etc/krb5.keytab
    KVNO Principal
    ----
    --------------------------------------------------------------------------
    3 HTTP/connect.smg.plc.uk@SMG.PLC.UK

    Indicating that both the Service Principal and keytab kvno's match. I
    think it would be wise for me to restart the process so I can be sure
    that the kvnos are starting at 1.

    From the determined kvno information, I am worried that starting again
    will not resolve my issue. Assuming that the kvno is reset to 1, using
    kvno and klist to determine the version number should return similar
    results to above, but showing the number to be 1. What would the
    difference be and would it resolve the pre-authentication issue?



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


  8. Re: kinit request on keytab fails using 2K3sp1 KDC

    David Telfer wrote:
    > David Telfer wrote:
    >> To determine the keytab kvno;
    >>
    >> # /usr/local/sbin/ktutil
    >> ktutil: rkt /etc/krb5.keytab
    >> ktutil: list
    >> slot KVNO Principal
    >> ---- ----
    >> ---------------------------------------------------------------------
    >> 1 3 HTTP/connect.smg.plc.uk@SMG.PLC.UK
    >>
    >> This is the step I am unsure of, but I believe it indicates that the
    >> keytab also has a KVNO of 3. Is this correct?
    >>

    > To clarify this, I have realised that I was jumping through too many
    > hoops to determine the kvno of the keytab file.
    >
    > I should have used;
    > #./klist -k /etc/krb5.keytab
    >
    > This returns;
    >
    > Keytab name: FILE:/etc/krb5.keytab
    > KVNO Principal
    > ----
    > --------------------------------------------------------------------------
    > 3 HTTP/connect.smg.plc.uk@SMG.PLC.UK
    >
    > Indicating that both the Service Principal and keytab kvno's match. I
    > think it would be wise for me to restart the process so I can be sure
    > that the kvnos are starting at 1.
    >
    > From the determined kvno information, I am worried that starting again
    > will not resolve my issue. Assuming that the kvno is reset to 1, using
    > kvno and klist to determine the version number should return similar
    > results to above, but showing the number to be 1. What would the
    > difference be and would it resolve the pre-authentication issue?


    Why do you need the kvno to be 1? the requirement is that the kvno of
    the service ticket issued by the KDC must match the kvno of the service
    principal entry in the keytab. As the kvnos match, your problem must be
    somewhere else.

    For example, what is the enctype of the service ticket issued by the
    KDC? Does that match the enctype of the keytab entry you are using?

    What do the following commands output?

    klist -e -k /etc/krb5.keytab

    kvno HTTP/connect.smg.plc.uk@SMG.PLC.UK
    klist -e

    If the enctypes and output of those commands match, then you must
    double check that the browser client is obtaining service tickets
    with the name HTTP/connect.smg.plc.uk@SMG.PLC.UK and that the
    enctype of that ticket matches the contents of the keytab entry.

    Jeffrey Altman

  9. Re: kinit request on keytab fails using 2K3sp1 KDC



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


  10. Re: kinit request on keytab fails using 2K3sp1 KDC

    Jeffrey Altman wrote:
    > Why do you need the kvno to be 1?

    It wasn't so much that they needed to match, more to tidy up the situation I had on the KDC.

    > For example, what is the enctype of the service ticket issued by the
    > KDC? Does that match the enctype of the keytab entry you are using?
    >
    > What do the following commands output?
    >
    > klist -e -k /etc/krb5.keytab
    >
    > kvno HTTP/connect.smg.plc.uk@SMG.PLC.UK
    > klist -e
    >

    This appears to be the problem, the keytab is being generated with DES
    CBD MD5, the service principal is sending an ArcFour encrypted tgt.

    The reason this never occured to me is that the user account has the
    'use DES encryption for this account' setting ticked. I have tried the
    following process to force the service principal to be DES;

    1 - create account
    2 - run ktpass util with -mapop set +DesOnly and -crypto DES-CBC-MD5
    options set.
    3 - view account properites and ensure that 'use DES encryption for this
    account' is checked
    4 - change password of account (with the intention of forcing the DES
    change from the ktpass step above)
    5 - re-run identical ktpass line and use this as the final keytab

    Even with these steps, the encryption type of the ServicePrincipal tgt
    stays as ArcFour.

    Unfortunately I am not the AD administrator, I have access to an admin
    member of staff who has been applying the changes for me. Due to this I
    cannot be sure of every setting their kdc controller has. Specifically
    I would be keen to find out whether there is a global setting which
    forces all user and service principals to be created as ArcFour. Has
    anyone experienced somehing like this, or do they know of a way to hard
    force the enc type of the service principal.
    > If the enctypes and output of those commands match, then you must
    > double check that the browser client is obtaining service tickets
    > with the name HTTP/connect.smg.plc.uk@SMG.PLC.UK and that the
    > enctype of that ticket matches the contents of the keytab entry.
    >

    I haven't got to the stage of attempting to use mod_auth_kerb yet. I am
    still trying to get past the `#./kinit -k -t /etc/krb5.keytab
    HTTP/connect.smg.plc.uk@SMG.PLC.UK` stage. I may look into the
    potential for using ArcFour for both the keytab and ServicePrincipal but
    I'm sure this will open another can of worms as well.

    Thanks,
    David




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


  11. Re: kinit request on keytab fails using 2K3sp1 KDC

    On Thursday 23 March 2006 18:39, David Telfer wrote:
    > I may look into the
    > potential for using ArcFour for both the keytab and ServicePrincipal


    In general that works, I've some mails of people in my inbox
    who run their mod_auth_kerb with RC4.

    > but
    > I'm sure this will open another can of worms as well.


    right! :-D


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


  12. Re: kinit request on keytab fails using 2K3sp1 KDC



    David Telfer wrote:

    > Jeffrey Altman wrote:
    >
    >>Why do you need the kvno to be 1?

    >
    > It wasn't so much that they needed to match, more to tidy up the situation I had on the KDC.
    >
    >
    >>For example, what is the enctype of the service ticket issued by the
    >>KDC? Does that match the enctype of the keytab entry you are using?
    >>
    >>What do the following commands output?
    >>
    >> klist -e -k /etc/krb5.keytab
    >>
    >> kvno HTTP/connect.smg.plc.uk@SMG.PLC.UK
    >> klist -e
    >>

    >
    > This appears to be the problem, the keytab is being generated with DES
    > CBD MD5, the service principal is sending an ArcFour encrypted tgt.
    >
    > The reason this never occured to me is that the user account has the
    > 'use DES encryption for this account' setting ticked. I have tried the
    > following process to force the service principal to be DES;
    >
    > 1 - create account
    > 2 - run ktpass util with -mapop set +DesOnly and -crypto DES-CBC-MD5
    > options set.
    > 3 - view account properites and ensure that 'use DES encryption for this
    > account' is checked
    > 4 - change password of account (with the intention of forcing the DES
    > change from the ktpass step above)
    > 5 - re-run identical ktpass line and use this as the final keytab
    >
    > Even with these steps, the encryption type of the ServicePrincipal tgt
    > stays as ArcFour.
    >
    > Unfortunately I am not the AD administrator, I have access to an admin
    > member of staff who has been applying the changes for me.


    They could look at the userAccountControl field of the account which shows
    an an integer. Convert it to hex and look for the DesOnly bit0x200000
    See http://support.microsoft.com/default...b;en-us;305144

    You as a user might be able to see this as well using ldap or one of the
    Windows tools.

    > Due to this I
    > cannot be sure of every setting their kdc controller has. Specifically
    > I would be keen to find out whether there is a global setting which
    > forces all user and service principals to be created as ArcFour. Has
    > anyone experienced somehing like this, or do they know of a way to hard
    > force the enc type of the service principal.
    >


    See the USE_DES_KEY_ONLY bit from above.

    >>If the enctypes and output of those commands match, then you must
    >>double check that the browser client is obtaining service tickets
    >>with the name HTTP/connect.smg.plc.uk@SMG.PLC.UK and that the
    >>enctype of that ticket matches the contents of the keytab entry.
    >>

    >
    > I haven't got to the stage of attempting to use mod_auth_kerb yet. I am
    > still trying to get past the `#./kinit -k -t /etc/krb5.keytab
    > HTTP/connect.smg.plc.uk@SMG.PLC.UK` stage. I may look into the
    > potential for using ArcFour for both the keytab and ServicePrincipal but
    > I'm sure this will open another can of worms as well.
    >
    > Thanks,
    > David
    >
    >
    >
    >
    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos
    >
    >


    --

    Douglas E. Engert
    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


  13. Re: kinit request on keytab fails using 2K3sp1 KDC

    On 3/23/06, Douglas E. Engert wrote:
    >
    > They could look at the userAccountControl field of the account which shows
    > an an integer. Convert it to hex and look for the DesOnly bit0x200000
    > See http://support.microsoft.com/default...b;en-us;305144
    >
    > You as a user might be able to see this as well using ldap or one of the
    > Windows tools.
    >


    I have ldap access to the DC and have checked this, the
    userAccountControl field has a decimal value of 2163200 (0x210200).
    The USE_DES_KEY_ONLY bit is definitely set which causes me quite a bit
    of confusion!

    To make sure I wasn't making any silly mistakes I cleared all krb
    caches for all users on my Solaris box and started again. I ran kinit
    on HTTP/connect.smg.plc.uk@SMG.PLC.UK then checked the encryption type
    with klist -e. It is still RC4.

    One thing that has caught my attention is the changing kvno numbers.
    They match between the keytab and the Service principal which is as
    required, however I have deleted the user account then recreated it.

    The kvno values are still going up sequentially indicating that the
    kdc is aware of the previous service principals. Is it possible that
    the enctype of the initial principal is being maintained even though
    the system account has been deleted? Is there any way to delete the
    service principal when deleting the system account (possibly with
    setspn -D, although I can't seem to find the principal using this
    utility)?

    p.s. sorry for the change in email address, I am unable to access my
    office e-mail from home at present.

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


  14. Re: kinit request on keytab fails using 2K3sp1 KDC



    david telfer wrote:

    > On 3/23/06, Douglas E. Engert wrote:
    >
    >>They could look at the userAccountControl field of the account which shows
    >>an an integer. Convert it to hex and look for the DesOnly bit0x200000
    >>See http://support.microsoft.com/default...b;en-us;305144
    >>
    >>You as a user might be able to see this as well using ldap or one of the
    >>Windows tools.
    >>

    >
    >
    > I have ldap access to the DC and have checked this, the
    > userAccountControl field has a decimal value of 2163200 (0x210200).
    > The USE_DES_KEY_ONLY bit is definitely set which causes me quite a bit
    > of confusion!
    >
    > To make sure I wasn't making any silly mistakes I cleared all krb
    > caches for all users on my Solaris box and started again. I ran kinit
    > on HTTP/then checked the encryption type
    > with klist -e. It is still RC4.
    >
    > One thing that has caught my attention is the changing kvno numbers.
    > They match between the keytab and the Service principal which is as
    > required, however I have deleted the user account then recreated it.
    >
    > The kvno values are still going up sequentially indicating that the
    > kdc is aware of the previous service principals.




    You can do ldapsearchs for dnshostanme=connect.smg.plc.uk
    whihc should show all records asociated with this dnsname.
    (I know msktutil will set this, not sure if ktpass will.)

    and search for combinations of servicePrincipalName= or userPrincipalName=
    HTTP/connect.smg.plc.uk or HTTP/connect.smg.plc.uk@SMG.PLC.UK


    > Is it possible that
    > the enctype of the initial principal is being maintained even though
    > the system account has been deleted?


    It could be the service principal in on a different account then you
    thought!

    I believe once ktpass did the mapuser the first time, it will continue
    to use this same account, but give you the warning message.
    The admin might have to use the setspn -D to get rid of the spn mapping,
    or the account.

    And there are replication timing issues between DCs. This may take a few
    minutes for any change or delete to propagate.


    > Is there any way to delete the
    > service principal when deleting the system account


    I have always seen the SPN deleted when the account was deleted.

    (possibly with
    > setspn -D, although I can't seem to find the principal using this
    > utility)?


    With setspn -L computername
    the computername is the cn of the account which would be the account
    name. i.e. the same name used in the ktpass -mapuser xxxx

    Try the setspn -L xxxx

    >
    > p.s. sorry for the change in email address, I am unable to access my
    > office e-mail from home at present.
    >
    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos
    >
    >


    --

    Douglas E. Engert
    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


+ Reply to Thread