ktutil - problems generating AES keys (salt?)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

ktutil - problems generating AES keys (salt?)

Ben H
I expect this is probably a known issue, though I can't really find any
definitive source:

I am integrating with an AD domain.

If using RC4 encryption I am able to generate a keytab file using either
window's ktpass or via ktutil on the Linux side (assuming the account's
password is known)
However when using AES, the keytab generated using ktutil appears to create
the wrong key.

My guess is that ktutil is using an improper salt (or none at all).
 According to MS-KILE section 3.1.1.2 when creating a key for a computer
account to use the following salt:

----
Computer accounts: < DNS name of the realm, converted to upper case > |
"host" | < computer
name, converted to lower case with trailing "$" stripped off > | "." | <
DNS name of the realm,
converted to lower case >
---

The document is worded poorly as it can be interpreted that this salt is
used for all enctypes, but I believe that only AES is salted in this way
and based on my testing RC4 doesn't get salted.

This would make sense that ktutil can properly generate a compatible RC4
key if no salt is required, but fails in the AES key.

I see no way to feed ktutil a salt when generating the key.

Is there another supported method to create keytabs using the kerberos
tools while providing a salt?
I don't want to resort to samba or something similar, and not sure I even
can since I've actually need to support *only* AES within the AD domain
(i.e. no RC4).

I have a semi-workaround in that if I generate a key using ktpass I can
simply take the key (without having to transfer the entire keytab) and use:

addent -key -p principal -k kvno -e aes256-cts

and then provide the key generated on the windows side...however this still
involves work done on the windows system.

Can someone confirm my findings are accurate, and if there is a better
solution?

I have found a tool called msktutil which I have built and it generates
keytabs properly, I would prefer a method I know will exist with every krb5
distribution.

Thanks!
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: ktutil - problems generating AES keys (salt?)

Greg Hudson
On 08/02/2014 02:19 AM, Ben H wrote:
> The document is worded poorly as it can be interpreted that this salt is
> used for all enctypes, but I believe that only AES is salted in this way
> and based on my testing RC4 doesn't get salted.

The RC4 enctype completely ignores the salt, so it doesn't matter if
ktutil picks the wrong one.

> I see no way to feed ktutil a salt when generating the key.

I think that's correct.  We would like ktutil (or perhaps a successor
program) to be able to make an AS request to get the actual salt from
the KDC, but this hasn't been implemented.  Being able to manually
specify a salt could also be useful in some cases.

> I have found a tool called msktutil which I have built and it generates
> keytabs properly, I would prefer a method I know will exist with every krb5
> distribution.

I don't have personal experience generating keytabs for an AD domain.  I
think msktutil may be the most common way of doing it, but I'm not certain.

The salt you described from the Microsoft documentation matches the
default RFC 4120 salt for a host/fqdn@REALM principal, so if you specify
the principal in exactly the right form (with the correct case), I would
expect ktutil to use the correct salt.  So I'm not sure why it isn't
working for you.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: ktutil - problems generating AES keys (salt?)

Mark Pröhl
On 02.08.2014 17:03, Greg Hudson wrote:
> On 08/02/2014 02:19 AM, Ben H wrote:
>> The document is worded poorly as it can be interpreted that this salt is
>> used for all enctypes, but I believe that only AES is salted in this way
>> and based on my testing RC4 doesn't get salted.

DES was too salted in this way.

>
> The RC4 enctype completely ignores the salt, so it doesn't matter if
> ktutil picks the wrong one.
>
>> I see no way to feed ktutil a salt when generating the key.
>
> I think that's correct.  We would like ktutil (or perhaps a successor
> program) to be able to make an AS request to get the actual salt from
> the KDC, but this hasn't been implemented.  Being able to manually
> specify a salt could also be useful in some cases.

You cannot specify the salt when using ktutil. What you need to do
instead is to specify exactly the same principal that AD uses as salt.

For machine accounts this salting principal is
host/sAMAccountname.domain_name@DOMAIN_NAME

   sAMAccountname := the machines samaccountname without "$"
   domain_name := name of AD domain name in lowercase
   DOMAIN_NAME := name of AD domain name in uppercase

For user accounts this salting principal is username@DOMAIN_NAME

   username := first component of userPrincipalname or sAMAccountName
               if userPrincipalname attribute is not set

Use that principal with ktutil's "addent -password ...". Afterwards you
can read out the key with ktutil's "list -k" and use this key together
with "addent -key ..." to create keytab entries for other principals
that are associated to the same AD account.


>
>> I have found a tool called msktutil which I have built and it generates
>> keytabs properly, I would prefer a method I know will exist with every krb5
>> distribution.
>
> I don't have personal experience generating keytabs for an AD domain.  I
> think msktutil may be the most common way of doing it, but I'm not certain.

msktutil is definitively the better tool to generate keytabs for AD.

>
> The salt you described from the Microsoft documentation matches the
> default RFC 4120 salt for a host/fqdn@REALM principal, so if you specify
> the principal in exactly the right form (with the correct case), I would
> expect ktutil to use the correct salt.  So I'm not sure why it isn't
> working for you.

Not fqdn but samaccountmane + domain_name. So if AD domain_name != DNS
domain name, the fqdn will not work.

--
Mark Pröhl
[hidden email]
www.kerberos-buch.de

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: ktutil - problems generating AES keys (salt?)

Ben H
Thanks guys...as I was reading Greg's response I thought of the exact same
solution that Mark is suggesting (generate with full SPN, then read key and
re-add).

FYI, I am going to add this here for posterity in case anyone else is
referencing this for the creation of Keytabs for AD compatibility:

I have noticed that when using ktpass on a windows machine if you use
"/pass *" to set the password interactively rather than "/pass password" to
enter it on the command line that the wrong key is generated.
IOW, don't use the "/pass *" options.  I have submitted this to the MS open
doc team as a possible bug, but I know many people have issues using ktpass
and I think this maybe one (of the several) reasons it gives people a hard
time.


On Sun, Aug 3, 2014 at 11:28 AM, Mark Pröhl <[hidden email]> wrote:

> On 02.08.2014 17:03, Greg Hudson wrote:
> > On 08/02/2014 02:19 AM, Ben H wrote:
> >> The document is worded poorly as it can be interpreted that this salt is
> >> used for all enctypes, but I believe that only AES is salted in this way
> >> and based on my testing RC4 doesn't get salted.
>
> DES was too salted in this way.
>
> >
> > The RC4 enctype completely ignores the salt, so it doesn't matter if
> > ktutil picks the wrong one.
> >
> >> I see no way to feed ktutil a salt when generating the key.
> >
> > I think that's correct.  We would like ktutil (or perhaps a successor
> > program) to be able to make an AS request to get the actual salt from
> > the KDC, but this hasn't been implemented.  Being able to manually
> > specify a salt could also be useful in some cases.
>
> You cannot specify the salt when using ktutil. What you need to do
> instead is to specify exactly the same principal that AD uses as salt.
>
> For machine accounts this salting principal is
> host/sAMAccountname.domain_name@DOMAIN_NAME
>
>    sAMAccountname := the machines samaccountname without "$"
>    domain_name := name of AD domain name in lowercase
>    DOMAIN_NAME := name of AD domain name in uppercase
>
> For user accounts this salting principal is username@DOMAIN_NAME
>
>    username := first component of userPrincipalname or sAMAccountName
>                if userPrincipalname attribute is not set
>
> Use that principal with ktutil's "addent -password ...". Afterwards you
> can read out the key with ktutil's "list -k" and use this key together
> with "addent -key ..." to create keytab entries for other principals
> that are associated to the same AD account.
>
>
> >
> >> I have found a tool called msktutil which I have built and it generates
> >> keytabs properly, I would prefer a method I know will exist with every
> krb5
> >> distribution.
> >
> > I don't have personal experience generating keytabs for an AD domain.  I
> > think msktutil may be the most common way of doing it, but I'm not
> certain.
>
> msktutil is definitively the better tool to generate keytabs for AD.
>
> >
> > The salt you described from the Microsoft documentation matches the
> > default RFC 4120 salt for a host/fqdn@REALM principal, so if you specify
> > the principal in exactly the right form (with the correct case), I would
> > expect ktutil to use the correct salt.  So I'm not sure why it isn't
> > working for you.
>
> Not fqdn but samaccountmane + domain_name. So if AD domain_name != DNS
> domain name, the fqdn will not work.
>
> --
> Mark Pröhl
> [hidden email]
> www.kerberos-buch.de
>
> ________________________________________________
> Kerberos mailing list           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos