Re: iprop problem

["Henry B. Hotz" <hotz@jpl.nasa.gov>]

On Nov 2, 2006, at 12:34 AM, Juha Jäykkä wrote:

>> Don't know about 64-bit issues, but seems like it should be OK.  You
>> can check it with kinit --keytab=/var/heimdal/<iprop-keytab> iprop/
>> <machine>.
>
> If you are referring whether this gives me a ticket, it does. BTW, is
> there a strong reason not to keep iprop keys in /etc/krb5.keytab? Of
> course, iprop then needs to be root, but at least Debian iprop runs as
> root out-of-the-box, so changing that may prove troublesome.

If you can do the kinit, then the keytab has a functional copy of the  
right key and you probably don't have to worry about any 32/64 bit  
issues.

As to where you keep the keytab, it's just a matter of how many  
people do you want to access it?  Your ssh daemon has no business  
seeing the key for the iprop service and vice versa.

>> I suggest you delete the relevant files from /var/heimdal (excepting
>> the keytab that I assume you put there), and start from scratch.
>> Could you give us a step-by-step of what you're trying and when it
>> fails?
>
> Here goes. First, I scapped the whole heimdal-kdc from the machine.
> (For Debianists: aptitude purge heimdal-kdc.) After that, reinstall  
> the
> beast (and config files), start kdc and start iprop slave. The first
> indication of trouble is in heimdal-krb5lib.log:
>
> 2006-11-02T09:41:09 kadm5_log_replay: 25: Decrypt integrity check  
> failed

Did you delete the /var/heimdal/heimdal.log file as part of the  
reset?  A new slave should not have any log file to replay.  It  
should simply download a complete fresh copy of the DB, and  
initialize the log file to 24 bytes, containing a no-op with the  
current DB version number.  In other words, even after a real init, a  
replay should only consist of a single operation that could fail.

> After that, there are many, many messages like that and even some  
> "Entry
> already exists in database" -messages. (Is iprop slave trying to  
> get the
> same entry more than once from the master? Why?)
>
> After the db is in sync (which takes horribly long, presumably due  
> to the
> aforementioned errors), I try to kinit:
>
> kelvin:/var/lib/heimdal-kdc# kinit
> juhaj/admin@TFY.UTU.FI's Password:
> kinit: krb5_get_init_creds: Client (juhaj/admin@TFY.UTU.FI) unknown
>
> Simultaneously kdc.log says (I sanitised it a bit):
>
> AS-REQ juhaj/admin@TFY.UTU.FI from IPv4:X for krbtgt/ 
> TFY.UTU.FI@TFY.UTU.FI
> UNKNOWN -- juhaj/admin@TFY.UTU.FI: Decrypt integrity check failed

Is this error on the master or the slave?  This looks like an  
ordinary user bad password error.  Iprop would be using iprop/*  
principals, not juhaj/* principals.

> I know that "Decrypt integrity check failed" is almost synonymous to
> "incorrect password", but I can vouch for that: I even tried copy &  
> paste
> the password.
>
> Can there be something wrong with the database itself? (It works fine,
> though.) Would it help, if I did the initial sync with kadmin dump on
> master and kadmin load on slave? How would I encrypt the db on the  
> slave
> in that case?

Sounds like at least the master DB is fine.  Do you have a copy of  
the master key file on the slave?  The slave needs to be able to  
decrypt the DB to use it, just as the master does.

No you don't want to just copy the DB over because there's other  
stuff that iprop needs initialized.  Even if you switch to hprop it's  
still a good test to see if hprop can do the initial copy.  If you  
wind up with an unencrypted copy of the DB you can encrypt it by  
doing hprop | hpropd on the machine with the right options.

> -Juha
------------------------------------------------------------------------ 
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu