(Sorry for the long delay.  I somehow didn't see this in the krb5-
bugs moderation queue until today.)

What you are asking for is called "optimistic pre-authentication."  
The problem with doing it usefully for this scenario is that the 
PREAUTH_REQUIRED error doesn't just convey a need to do preauth; it 
also conveys:

1. The types of pre-authentication supported by the KDC.
2. The encryption type of at least one password-derived key that the 
KDC can validate.
3. The salt to be used for the string-to-key operation.
4. (Rarely) any other string-to-key parameters which should affect 
the password-derived key.

I think for user accounts in a Windows domain which don't use PKINIT 
it might generally work to try with the first requested enctype 
(assuming that would be aes256-sha1 and the server is reasonably 
modern) and the default salt, and then retry if we get back an error 
indicating the wrong key.  But it could easily make things worse if 
any of the assumptions change.

The ideal implementation of optimistic encrypted timestamp would 
cache the preauth type and etype-info parameters (items 2-4 above) 
per client principal name, so that a retry is only needed if one of 
those parameters changes.  We could perhaps keep such a cache in the 
user home directory if configuration explicitly requests it (doing it 
by default would create problems for NFS-mounted home directories and 
has privacy implications), but it would add a non-trivial amount of 
code complexity.

We haven't gotten many requests to implement optimistic preauth, so I 
will leave this open as an enhancement request in case that changes.