parsing dump format...

[Mitchell E Berger]

The good news
=============
In the dump format specified by the code segment you're looking at, you
can get the last_pwd_change easily.  It's the 16th tab-delimited field.  The
last line in your snippet of code is the line that fills in the mod_date and
mod_princ.  Then about 20 lines down, a call to krb5_dbe_lookup_last_pwd_change
fills in last_pwd_change.  Further down, the tabbed output format is specified.
The last_pwd_change field is in the second batch of things outputted.  It is
recorded as a unix time (i.e. number of seconds since the epoch).

The bad news
============
You're looking at the really old dump format, version 2.0.  You want to
(probably) be looking at the current dump format, version 5.  The last
password change time isn't explicitly stored in the principal record in a
field reserved for specifically that purpose (we're talking about in the
database, not the dump file here).  It is stored as something called TL_DATA
(type length data), which is sort of a hack to allow generic types of new
data to be stored in the principal's record without having to change the
struct that represents a principal.  One type of TL_DATA is
KRB5_TL_LAST_PWD_CHANGE, which is what you're after.  Another is
KRB5_TL_MOD_PRINC, which is the other related type to the code snippet you
sent.  The old dump format treated these particular TL_DATA types as special
cases and extracted them and placed them in reliable fields of the dump file.
Newer dump formats treat all TL_DATA equally, as hex blobs, which is what you
feared, and each record may have a different number of TL_DATA entries, and
the order in which such entries appear cannot be relied upon.

Essentially, you could try decoding the hex blob, but it would likely be
more trouble than it's worth.  You can get kdb5_util to use the old format
(with 'kdb5_util dump -old') if what you're really after is the password
change dates, but be aware that older formats lack some of the data reported
by newer formats (including, for example, policy data).  So  I'd recommend
getting an old format dump just to lookup those dates, but only performing
changes or imports from a current format dump.

Hope that clears things up and is useful...

Mitch

> Is there any quick and easy way to get the last-pw-change date from a dump? It looked to me like the other parameters, such as expiration, etc. are all in there, but I couldn't find the last-pw-change, or last-modified time in there, unless it is embedded in one of the hex blobs. 
> 
> Looks like this might be why it isn't in there:
> 
>     /*
>      * If we don't have any match strings, or if our name matches, then
>      * proceed with the dump, otherwise, just forget about it.
>      */
>     if (!arg->nnames || name_matches(name, arg)) {
>         /*
>          * Deserialize the modifier record.
>          */
>         mod_name = (char *) NULL;
>         mod_princ = NULL;
>         last_pwd_change = mod_date = 0;
>         pkey = akey = (krb5_key_data *) NULL;
>         if (!(retval = krb5_dbe_lookup_mod_princ_data(arg->kcontext,
> 
> Why are those params set to zero for the dump?
> 
> -- Nathan
> 
> ------------------------------------------------------------
> Nathan Neulinger                       EMail:  nneul at umr.edu
> University of Missouri - Rolla         Phone: (573) 341-4841
> Computing Services                       Fax: (573) 341-4216
> _______________________________________________
> krbdev mailing list
> krbdev at mit.edu
> http://mailman.mit.edu/mailman/listinfo/krbdev