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 <mark at mproehl.net> 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 at 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 at 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 at 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
> mark at mproehl.net
> www.kerberos-buch.de
>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>