Windows 2008R2 USER/root preauthentication failure

[David Thompson]

On 9/26/13 9:45 PM, Benjamin Kaduk wrote:
>> I have a working kerberos environment, with Windows 2008R2 acting as
>> KDC, serving a mix of OS X and Linux (think RHEL 6) clients.
>>
>> I am trying to add ksu ability, with principals of the form USER/root,
>> and cannot authenticate those principals.
>>
 >
> The remarks at
> http://technet.microsoft.com/en-us/library/cc782155(v=ws.10).aspx
> "Ktpass Remarks" make me wonder if ktpass is supposed to work the way
> you are trying to use it.  For instance, what happens when you type the
> 'dt' user's password at the 'kinit dt/root' password prompt?

Same thing.  Preauth failure if I have preauth enabled; otherwise 
password incorrect.

Thanks for the link.  There is an abundance of documentation on the web 
for creating multipart service principals, and I've used that 
successfully.  In general, you use ktpass to attach as additional krb5 
multipart principal to an existing AD object (usually a host, but I 
don't believe there would be any impediment to attaching a service 
principal to any AD object), and optionally write out a keytab.  I have 
not been able to find any help creating multi-part *user* principals 
(KRB5_NT_PRINCIPAL), so I thought I'd try here and see if there were any 
Windows krb5 admins that know the secret sauce.

> The unix utility which is a rough analog of ktpass (ktutil) does not do
> any verification of the password, it just applies the string-to-key
> operations; I would not be terribly surprised if ktpass.exe was doing
> the same sort of thing.

What else (besides the matching key) would be needed for kinit to obtain 
a tgt for the principal in question?

In the network trace (without preauth), I'm getting an AS-REQ followed 
by the AS-REP from the server, with the right principal names 
everywhere.  The AS_REP has as salt the realm (KECK.WAISMAN.WISC.EDU) 
and it looks like it might be appending "dtroot" onto the end.  I saw 
some discussion on this list about the salt being important, but it's 
there in plain text in the AS-REP, so it seems like kinit should be able 
to deal with whatever salt the KDC wants to give it (right?).  Of 
course, I'd like to run with preauth, but apparently the MIT kinit and 
the win KDC aren't playing nicely (or the AS-REP is just borken).

In the preauth case, kinit still sends the AS-REQ before getting the 
password, which the KDC rejects with 'preauth required.'  After the 
password is entered, the reply to the subsequent AS-REQ is KRB-ERROR 
(KRB5KDC_ERR_PREAUTH_FAILED).  Either the KDC is looking for some kind 
of preauth that kinit isn't providing, or this is actually a 
manifestation of the failure in the no-preauth case.

Anyway, looks like I'm stymied on this one.  Thanks for the reply. 
Anyone else have any ideas?

-- 
David Thompson
Waisman Center Brain Imaging and Behavior Lab
1500 Highland Ave. Room T133
Madison, WI  53705-2280
(608) 265-6608
dthompson (at) waisman (dot) wisc (dot) edu