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 <[email protected]> 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 > [email protected] > www.kerberos-buch.de > > ________________________________________________ > Kerberos mailing list [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
