kinit request on keytab fails using 2K3sp1 KDC
David Telfer
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 intsv...@smg.plc.uk -princ
HTTP/connect.s...@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.s...@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
David...@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/thread/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
da...@2fluid.co.uk
________________________________________________
Kerberos mailing list Kerb...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Tim Alsop
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
Richard E. Silverman
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
r...@qoxp.net
Achim Grolms
> 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
Jeffrey Altman
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
Richard E. Silverman
JA> Richard E. Silverman wrote:
>>>>>>> "TA" == "Tim Alsop" <Tim....@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
r...@qoxp.net
David Telfer
>
> 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.
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.s...@SMG.PLC.UK
--->prompted for system user password
#./kvno HTTP/connect.s...@SMG.PLC.UK
HTTP/connect.s...@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.s...@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
Tim Alsop
Like yourself we spent many days/weeks trying to get the sp1 version of
ktpass to work, but we could not, so we have developed our own
replacement product that uses computer accounts instead.
Cheers, Tim
-----Original Message-----
From: kerberos...@mit.edu [mailto:kerberos...@mit.edu] On
Behalf Of David Telfer
David Telfer
> To determine the keytab kvno;
>
> # /usr/local/sbin/ktutil
> ktutil: rkt /etc/krb5.keytab
> ktutil: list
> slot KVNO Principal
> ---- ----
> ---------------------------------------------------------------------
> 1 3 HTTP/connect.s...@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?
>
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.s...@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?
Tim Alsop
>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?
We found that even if we start again, we could not get the pre-auth to
work.
Jeffrey Altman
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.s...@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.s...@SMG.PLC.UK and that the
enctype of that ticket matches the contents of the keytab entry.
Jeffrey Altman
Jeffrey Altman
>>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?
>
> We found that even if we start again, we could not get the pre-auth to
> work.
The most important new functionality in the W2K SP1 version of KTPASS is
that it allows you to export RC4-based keys instead of DES. Did you try
using RC4 keys or were you only interested in using single DES?
Jeffrey Altman
Douglas E. Engert
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 Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
--
Douglas E. Engert <DEEn...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
David Telfer
> Why do you need the kvno to be 1?
> 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.s...@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.s...@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.s...@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
Tim Alsop
I have seen this problem before. It does not occur with the pre-SP1
version of ktpass. Conclusion : If you want to create keytable files
which have correct kvno's and which work correctly with des, then you
must use the pre-SP1 version of ktpass.
Thanks, Tim
-----Original Message-----
From: kerberos...@mit.edu [mailto:kerberos...@mit.edu] On
Behalf Of David Telfer
Sent: 23 March 2006 17:39
To: kerb...@mit.edu
Subject: Re: kinit request on keytab fails using 2K3sp1 KDC
Jeffrey Altman
> David,
>
> I have seen this problem before. It does not occur with the pre-SP1
> version of ktpass. Conclusion : If you want to create keytable files
> which have correct kvno's and which work correctly with des, then you
> must use the pre-SP1 version of ktpass.
>
> Thanks, Tim
To which I once again ask, why would you use DES when you can use
RC4?
RC4 is a strong enctype and is the enctype that Windows wants to
use. I seem to remember that if you want to be able to "Use DES only"
then you must set the flag in AD and then change the password on
the account before it will take effect.
Jeffrey Altman
Achim Grolms
> 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
Douglas E. Engert
David Telfer 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.aspx?scid=kb;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.s...@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.s...@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 Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
--
Douglas E. Engert <DEEn...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
david telfer
>
> 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.aspx?scid=kb;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.s...@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.
Douglas E. Engert
david telfer wrote:
> On 3/23/06, Douglas E. Engert <deen...@anl.gov> 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.aspx?scid=kb;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.s...@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 Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
--
Douglas E. Engert <DEEn...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444