Re: Segfaults after receiving invalid AS-REQ
On 8/30/2017 4:38 AM, Sergio Gelato wrote: >>>> Yes. Saw in on 2017-06-14, filed an encrypted bug report to >>>> heimdal-bugs the next day with the attached patch. No reaction. Not >>>> to my status query the other day either. jalt...@secure-endpoints.com: >>> I diagnosed this problem as well and there is a patch waiting to be >>> included in a subsequent release. On 8/31/2017 5:54 AM, Lars-Johan Liman wrote: >> Just curious: is this patch available in the Github repository or does >> "waiting" mean somewhere else? jalt...@secure-endpoints.com: > Its not in the repository. Ack. Thanks. Cheers, /Liman
Re: Segfaults after receiving invalid AS-REQ
On 8/30/2017 4:38 AM, Sergio Gelato wrote: >> Yes. Saw in on 2017-06-14, filed an encrypted bug report to heimdal-bugs >> the next day with the attached patch. No reaction. Not to my status query >> the other day either. jalt...@secure-endpoints.com: > I diagnosed this problem as well and there is a patch waiting to be > included in a subsequent release. Just curious: is this patch available in the Github repository or does "waiting" mean somewhere else? Cheers, /Liman #---------- # Lars-Johan Liman, M.Sc. ! E-mail: li...@netnod.se # Senior Systems Specialist ! Tel: +46 8 - 562 860 12 # Netnod Internet Exchange, Stockholm ! http://www.netnod.se/ #--
Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"
All (pun intended!), On Mon, Jun 26, 2017 at 11:18:28AM +0200, Andreas Haupt wrote: >> Heimdal 7.3 seems to suffer from a bug in privilege checking. A prinicipal >> having all rights on the database is unable to extract keytabs: n...@cryptonector.com: > This is on purpose. > We decided that it was never a good idea for "all" to have meant > "extract keys", because in general that's not desirable. I very seldom raise my voice on this mailing list, but here I must, on sheer principal grounds. Chosen names must have obvious meanings. To have a status called "all" which isn't *ALL* is confusing at best. It will confuse the h-ll out of sysadmins over the globe for years to come, wasting time and money for no good purpose at all. I would have spent hours upon hours not understanding what the problem was, had I run into this trap. The "keep it simple" principle and the principle of least surprise are two fundamental principles for successful system management. Please fix this, either by changing the name "all" to "most" (or preferrably to somthing better), or by changing the behaviour to be *ALL*. Either is fine, but having "all" not mean *ALL* is not a good way forward. Best regards, /Lars-Johan Liman #-- # Lars-Johan Liman, M.Sc. ! E-mail: li...@netnod.se # Senior Systems Specialist ! Tel: +46 8 - 562 860 12 # Netnod Internet Exchange, Stockholm ! http://www.netnod.se/ #--
Re: Re-encrypt on change of master key
Hi! This whole thread contains a lot of really good information. Is this all documented in a good way (preferrably with examples) somewhere? If so, pointer please. If not, can it please be? Cheers, /Liman #-- # Lars-Johan Liman, M.Sc. ! E-mail: li...@netnod.se # Senior Systems Specialist ! Tel: +46 8 - 562 860 12 # Netnod Internet Exchange, Stockholm ! http://www.netnod.se/ #-- ada...@stanford.edu: > On 3/14/2017 3:57 PM, Nico Williams wrote: >> On Tue, Mar 14, 2017 at 03:54:36PM -0700, Adam Lewenberg wrote: >>> If you use a master key and you back up all your files _except_ the master >>> key to some remote location, wouldn't that suffice to protect the database >>> in that remote location? >> >> No. The problem is that the master key is not used to bind principal >> keys to principal records. This means that a backup operator could give >> you back a dump where a user's keys are pasted into the krbtgt >> principal(s), and if you load this dump that user will now be able to >> mint tickets for any service as any user. (You might notice this >> attack, but probably not in time to stop it.) >> >> Nico > I see. > If I trust the backup operator (e.g., it's me), then it still might be > useful as at the very least it makes it harder for anyone who runs > across the database file to guess the passwords. On the other hand, > encrypting the entire file before backup, as you suggest, accomplishes > this _and_ removes the concern of getting back a compromised database. > Thanks for the enlightenment. > Adam Lewenberg
Re: Copying principals to another realm
Hi!
v...@mpeks.tomsk.su:
> This won't work withing a multi-realm KDC because I need to copy, not
> rename.
Hmm What if you
1) "export" the existing ones to an xfr file (as described)
2) Rename the ones that are still in the database to the new realm name.
(This gives you the new realm name, but you loose the old one.)
3) Then import from the xfr file and _don't_ change the realm in there.
(This gives you back the old realm name.)
You should now have two entries for each such user - one with the old
realm name, and one with the new.
Of am I, as usual, totally off the mark? ;-)
Best regards,
/Lars-Johan Liman
#----------
# Lars-Johan Liman, M.Sc. ! E-mail: li...@netnod.se
# Senior Systems Specialist ! Tel: +46 8 - 562 860 12
# Netnod Internet Exchange, Stockholm ! http://www.netnod.se/
#--
