Problem with Kerberos

[Ken Raeburn]

On May 24, 2006, at 17:07, Marcus Watts wrote:
> "Krishna Venigalla" <krishna.venigalla at gmail.com> writes:
>>  We are using MIT Kerberos V4 release 9 in our production system.  
>> The OS we
>> are using is UNIX-MPRAS which runs on NCR-5100 machines. This  
>> configuration

Oh, wow, that's old....

> I believe MIT has dropped support of Kerberos V4.  You might ask
> them specifically for more support but since they've not responded
> yet I doubt you'll get much help.

Yeah, the V4 releases haven't been touched in a long time.

> I'm not sure what's happening in your exact case, but I remember
> vaguely that there were some issues with ancient vendor versions
> of libdbm - where certain keys could not be used on account
> of running out of hash buckets.  If that is the case, you
> should probably not expect the "bad" principal to ever work with your
> current software.  It should work once you convert over to MIT k5  
> 1.4.3.

Yup.  At my last job, I ran into this problem at a (potential?)  
customer site.  They had lots of entries in the database, and the  
names were structured.  Many entries wound up with the same hash  
value, and the overflow code in that version of NDBM didn't work  
properly.  (I later pored over the NDBM code for a while, and played  
the "I can trash that database with N records" game.  I forget just  
how "good" I was, but I'm pretty sure 10 or 12 records with the same  
key hash value were plenty to corrupt the database.  The failure  
modes varied, including missing records and infinite loops in the  
dump.  And the hash function wasn't that great; it was easy to  
generate collisions with structured names.)

> Assuming you've been making regular backups of things, you will  
> probably
> want to restore your last known good backup of the V4 database.

Agreed.  If this bug is causing dumps to fail, then a slave server  
may be a good option; otherwise, look to your system backups.

If you can't move to krb5 right away, I'd suggest getting a dump file  
out of your krb4 code, rebuilding it with gdbm (from ftp.gnu.org) or  
maybe Berkeley DB (I've never tried that combination), load the dump  
file in the new binaries, then test the new database by dumping it  
and comparing it against the previous dump (after sorting both).

> If you've not been making regular backups or for some reason they're
> not adequate, you'll have to resort to more custom tools to recover
> your kerberos data out of the dbm file.  This will most likely require
> a reasonably clever programmer; somebody who can figure out the .dbm
> file format and write tools to crawl through it, recover the data, and
> deal with master key issues, encrypting/decrypting stuff, and other
> kerberos specific stuff.  This will not be a trivial effort.

Well, if the problem-causing new record is explicitly omitted in this  
process, you can probably construct a new database file which will  
work well enough to run the regular dump code, so the master key and  
crypto stuff shouldn't have to be done.  The only Kerberos-related  
bits you ought to need would be code for recognizing valid database  
entries (e.g., does the key actually look like a principal name?),  
and maybe recognizing the problem entry so it can be skipped.

Ken