Re: Keytab, service and contacts with the KDC/AD

2018-10-06 Thread Henry B (Hank) Hotz, CISSP
Not to beat a dead horse, but yes. That’s actually a pretty good description of what happens. Good luck. > On Oct 4, 2018, at 9:11 AM, Ken Hornstein wrote: > >> Since the service ticket contains the session key encrypted with the >> service key, and the service knows its key via the keytab fil

Re: kadmin: failing dump/load

2017-11-12 Thread Henry B (Hank) Hotz, CISSP
+1 > On Nov 7, 2017, at 1:55 AM, Patrik Lundin wrote: > > This means that you can not inspect the database > (short of dumping it with kadmin -l dump) without possibly altering it > which might not be expected (though I do see the helpful side of being > able to easily prune keys on demand). Pe

Re: iprop: Problem forcing complete database sync

2017-10-07 Thread Henry B (Hank) Hotz, CISSP
On thing that’s conspicuously missing from this discussion is any historical context for how the version numbers are *supposed* to be handled. It seems like most of these problems are recent, or at least recent-ish. IIUC the deal is (should be? used to be? Please correct!): 1) On initial creati

Re: Getting "Connection refused" when runing hprop from master

2017-09-12 Thread Henry B (Hank) Hotz, CISSP
Why are you using hprop instead of iprop? It will automatically download the whole DB if the slave doesn’t have one (or it doesn’t have the binary log file that says what version of the DB it has). > On Sep 12, 2017, at 10:40 AM, Adam Lewenberg wrote: > > I trying to replicate the database fro

Tangent from: [kitten] Checking the transited list . . .

2017-08-21 Thread Henry B (Hank) Hotz, CISSP
> On Aug 21, 2017, at 7:05 AM, Greg Hudson wrote: > > I'm not sure about "any KDC in the trust chain trusts the next hop." > RFC 4120 doesn't think about cross-realm relationships in terms of > trust. Simply having cross-realm keys with another realm doesn't > necessarily imply that the other r

Re: How to disable DNS lookups?

2017-07-27 Thread Henry B (Hank) Hotz, CISSP
> On Jul 26, 2017, at 4:12 PM, Viktor Dukhovni > wrote: > >> The RR is guaranteed to return a name which has an A/ record. > > It is not. SRV RRs can and sometimes do reference names that don't exist. > Ditto with MX records, ... Even when the name exists a lookup can > time out. Per RF

Re: How to disable DNS lookups?

2017-07-26 Thread Henry B (Hank) Hotz, CISSP
I disagree. While you are technically correct, in my experience most SAs know very well what services are provided and where, but don’t know enough about DNS to know what a RR is. For that level of knowledge, having /etc/hosts take precedence is exactly the “least surprise” behavior. > On Jul

Re: How to disable DNS lookups?

2017-07-26 Thread Henry B (Hank) Hotz, CISSP
> On Jul 26, 2017, at 10:29 AM, u-hd-p...@aetey.se wrote: > > On Wed, Jul 26, 2017 at 08:45:17AM -0700, Russ Allbery wrote: >> Viktor Dukhovni writes: >>> 2. Look up same name in DNS, return address(es) if found >> >>> instead, in step 2, we may get undesirable, incorrect and/or costly >>>

Re: How to disable DNS lookups?

2017-07-26 Thread Henry B (Hank) Hotz, CISSP
> On Jul 25, 2017, at 6:30 PM, Roland C. Dowdeswell > wrote: > > And there are no KDCs configured in /etc/krb5.conf for the realm that > you are querying, you will use DNS SRV RRs. And, we think that once you > have retrieved hostnames from DNS SRV RRs that they should be looked up > only in D

Re: How to disable DNS lookups?

2017-07-25 Thread Henry B (Hank) Hotz, CISSP
I’m with Russ on this one, too. I’ve done /etc/hosts based deployments for robustness against DNS-failure scenarios. POXIX getaddrinfo() does not require DNS. It’s an interface to the system and whatever it uses. The system should be configurable to use whatever name resolution is appropriate w

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

2017-06-29 Thread Henry B (Hank) Hotz, CISSP
> On Jun 29, 2017, at 1:42 PM, Jeffrey Hutzelman wrote: > > > >>> That would not have had the desired effect of confronting sites >>> with the >>> insecurity of extracting keys. We can't force them to stop >>> depending on >>> that in one fell swoop. >> If you create, then require, then event

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege" (Corrected)

2017-06-29 Thread Henry B (Hank) Hotz, CISSP
> On Jun 29, 2017, at 12:45 PM, Nico Williams wrote: > > On Thu, Jun 29, 2017 at 11:41:41AM -0700, Henry B (Hank) Hotz, CISSP wrote: >>> On Jun 28, 2017, at 8:11 AM, Nico Williams wrote: >>> On Wed, Jun 28, 2017 at 07:28:59AM +0200, Lars-Johan Liman wrote: >

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

2017-06-29 Thread Henry B (Hank) Hotz, CISSP
> On Jun 29, 2017, at 12:45 PM, Nico Williams wrote: > > On Thu, Jun 29, 2017 at 11:41:41AM -0700, Henry B (Hank) Hotz, CISSP wrote: >>> On Jun 28, 2017, at 8:11 AM, Nico Williams wrote: >>> On Wed, Jun 28, 2017 at 07:28:59AM +0200, Lars-Johan Liman wrote: >

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

2017-06-29 Thread Henry B (Hank) Hotz, CISSP
> On Jun 28, 2017, at 8:11 AM, Nico Williams wrote: > > On Wed, Jun 28, 2017 at 07:28:59AM +0200, Lars-Johan Liman wrote: >> 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

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

2017-06-27 Thread Henry B (Hank) Hotz, CISSP
> On Jun 27, 2017, at 4:23 PM, Nico Williams wrote: > > We decided that it was never a good idea for "all" to have meant > "extract keys", because in general that's not desirable. How is extracting keys different from extracting a keytab (with the keys inside it)? Personal email. hbh...@oxy.

Re: Heimdal 7.3: ext_keytab fails with "Operation requires `get-keys' privilege"

2017-06-27 Thread Henry B (Hank) Hotz, CISSP
I’m with Love’s comment. Sounds like we did something different for some reason? Sounds like the current behavior is confusing, and therefore wrong, but I’ll have to make sure I understand it. I don’t think being able to get passwords is a different privilege from getting keys. Getting keytabs

Re: Does pre-authentication help against "insider" attacks?

2017-05-26 Thread Henry B (Hank) Hotz, CISSP
> On May 26, 2017, at 11:44 AM, Viktor Dukhovni wrote: > > And in particular, "service accounts" (service principals) generally have > random keys generated by cryptographically strong PRNG. They are typically > (on Unix systems) not and should not be "password based". > > Now it is true that

Git Issues

2017-04-11 Thread Henry B (Hank) Hotz, CISSP
I was setting up a source tree on a new VM and was reminded of some problems with git and our instructions on . First of all the form given for doing a read-only clone of the repository doesn’t work (and AFAICR never has). If you’re not logging in with your own

Re: Can ipropd-master service not do reverse DNS lookups?

2017-04-09 Thread Henry B (Hank) Hotz, CISSP
updates. > On Apr 7, 2017, at 8:13 PM, Adam Lewenberg wrote: > > > On 4/7/2017 2:01 PM, Henry B (Hank) Hotz, CISSP wrote: >> I thought there was already a command-line option to do that. >> >> Yes, there is. Do an iptopd-slave —help. The option is —hostname=>

Re: Can ipropd-master service not do reverse DNS lookups?

2017-04-07 Thread Henry B (Hank) Hotz, CISSP
I thought there was already a command-line option to do that. Yes, there is. Do an iptopd-slave —help. The option is —hostname=. ipropd-master has the same option. I’m looking at 7.0.1. > On Apr 7, 2017, at 1:47 PM, Jeffrey Hutzelman wrote: > > On Fri, 2017-04-07 at 13:41 -0700, Adam Lewenber

Re: How to quickly get a snapshot of the Heimdal DB file

2017-04-02 Thread Henry B (Hank) Hotz, CISSP
This is the one I’ve always used. You can grep out specific entries and hand-edit them if you need to make changes not otherwise supported by the admin interface. Also you can use this method to move full-strength cross-realm keys between installations. It’s also a great way to undo an otherwi

Re: ipropd question

2017-03-24 Thread Henry B (Hank) Hotz, CISSP
> On Mar 24, 2017, at 8:09 AM, Adam Lewenberg wrote: > > > > On 3/24/2017 7:21 AM, Thomas M. Payerle wrote: >> My experience is that ipropd-slave will try to apply the change log >> sent from the master, but if it cannot for some reason, it will ignore >> the change but bump the database versi

Re: ipropd question

2017-03-24 Thread Henry B (Hank) Hotz, CISSP
> On Mar 24, 2017, at 1:57 PM, Nico Williams wrote: > > To force a full prop with Heimdal 7.1 and up use > > $ iprop-log truncate —reset Ah! Personal email. hbh...@oxy.edu

Re: Re-encrypt on change of master key

2017-03-16 Thread Henry B (Hank) Hotz, CISSP
ote: > > > On 3/16/2017 12:03 PM, Henry B (Hank) Hotz, CISSP wrote: >> +1 >> >>> On Mar 15, 2017, at 5:51 AM, Jeffrey Altman >>> wrote: >>> >>> On 3/15/2017 5:17 AM, Lars-Johan Liman wrote: >>>> Hi! >>>> >>>&g

Re: Re-encrypt on change of master key

2017-03-16 Thread Henry B (Hank) Hotz, CISSP
+1 > On Mar 15, 2017, at 5:51 AM, Jeffrey Altman > wrote: > > On 3/15/2017 5:17 AM, Lars-Johan Liman wrote: >> 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,

Re: Re-encrypt on change of master key

2017-03-14 Thread Henry B (Hank) Hotz, CISSP
> On Mar 14, 2017, at 12:54 PM, Nico Williams wrote: > > On Tue, Mar 14, 2017 at 12:32:10PM -0700, Russ Allbery wrote: >> "Henry B (Hank) Hotz, CISSP" writes: >>> Shut down all daemons on the master. >> >>> hprop --decrypt --stdout | hprop

Re: Re-encrypt on change of master key

2017-03-14 Thread Henry B (Hank) Hotz, CISSP
https://www.mail-archive.com/heimdal-discuss@sics.se/msg00334.html There’s also a long, historically-interesting, thread on migrating from MIT that includes an example. > On Mar 14, 2017, at 11:51 AM, Henry B (Hank) Hotz, CISSP > wrote: > >> On Mar 14, 2017, at 9:43 AM, Adam L

Re: Re-encrypt on change of master key

2017-03-14 Thread Henry B (Hank) Hotz, CISSP
How’s the contract coming? > On Mar 14, 2017, at 9:43 AM, Adam Lewenberg wrote: > > How do I re-encrypt the entries of the Heimdal KDC database if I want to > change its master key? Shut down all daemons on the master. hprop --decrypt --stdout | hpropd --stdin Restart all daemons. That’s fr

Re: Documentation of principal attributes

2017-02-18 Thread Henry B (Hank) Hotz, CISSP
AFAIK no. Most are obvious-ish: disallow all, the client and server ones. The hardware preauth one is just a placeholder for unimplemented functionality. JPL never made much use of them. The ok as delegate one could be important for AD interoperability if you do a HTTP-Negotiate with web server

Re: Heimdal 7.1 and the sqlite backend

2016-12-23 Thread Henry B (Hank) Hotz, CISSP
> On Dec 22, 2016, at 8:53 AM, Jeffrey Hutzelman wrote: [. . .] > kadmin -l is not a kdc and probably does not read kdc.conf. I've not looked > at the current code to see how much of this was resolved, but we used to have > to patch a bunch of places to get kadmin -l and a bunch of the serve

Re: Heimdal 7 Release candidate 1 (7.0.1) available

2016-11-30 Thread Henry B (Hank) Hotz, CISSP
So it’s no longer possible to have non-numeric version numbers? Please understand, I don’t really care. The new system is logical enough, even if unconventional. Just wondering what the actual reason was. > On Nov 30, 2016, at 12:02 PM, Quanah Gibson-Mount wrote: > > --On Wednesday, November 3

Re: Heimdal 7 Release candidate 1 (7.0.1) available

2016-11-30 Thread Henry B (Hank) Hotz, CISSP
+1 > On Nov 30, 2016, at 12:09 PM, Harald Barth wrote: > > >>> While I’m asking, why are we renaming 1.7 as 7.x? > > I am more exited that there is work going on on a new release than I > am worried about the numbering now being 7.X instead of 1.7.X. As long > as the new number is bigger than

Re: Heimdal 7 Release candidate 1 (7.0.1) available

2016-11-30 Thread Henry B (Hank) Hotz, CISSP
Yay! Did I miss a 7.0 release? Also why does 7.0.1rcX automatically become 7.1? While I’m asking, why are we renaming 1.7 as 7.x? > On Nov 29, 2016, at 8:02 PM, Viktor Dukhovni > wrote: > > Dear Heimdal Community, > > As promised in: > > > http://kerberos.996246.n3.nabble.com/Preparing-fo

Re: Copying principals to another realm

2016-09-19 Thread Henry B (Hank) Hotz, CISSP
maybe they shouldn’t. > On Sep 16, 2016, at 10:07 PM, Victor Sudakov wrote: > > Henry B (Hank) Hotz, CISSP wrote: >>> I would like to copy some user principals from one realm to another >>> while retaining their keys/passwords. Which is the correct way to do >>>

Re: Copying principals to another realm

2016-09-16 Thread Henry B (Hank) Hotz, CISSP
If both are Heimdal, then I’ve done: kadmin -l dump —decrypt | grep ‘^principal’ >xfr.file kadmin -l merge xfr.file If it’s between implementations, then the only general solution is to independently create them with a password (a really long/good password). I’ve written no code, but I’ve gener

Re: Where does the Latest Version Work?

2016-08-12 Thread Henry B (Hank) Hotz, CISSP
> On Aug 11, 2016, at 6:37 PM, Jeffrey Altman > wrote: > > On 8/11/2016 9:21 PM, Henry B (Hank) Hotz, CISSP wrote: >> I can get Heimdal 1.6 to work with some fiddling. >> >> There doesn’t seem to be a 1.7 branch in GIT. > > Nor will there be. The nex

Where does the Latest Version Work?

2016-08-11 Thread Henry B (Hank) Hotz, CISSP
I can get Heimdal 1.6 to work with some fiddling. There doesn’t seem to be a 1.7 branch in GIT. The bleeding-edge version doesn’t seem to be usable. Since I believe there are people on this list actually doing development on Heimdal, where are you doing it? I’ve tried the latest Debian and Net

Re: /var/heimdal/kpasswdd.history no longer updating after a heimdal upgrade

2016-06-29 Thread Henry B (Hank) Hotz, CISSP
Ah! Then it’s a question for Russ Allbery or Alf Wachsmann. you need their email addresses? > On Jun 29, 2016, at 5:22 PM, Jeffrey Altman > wrote: > > On 6/29/2016 6:39 PM, Renata Maria Dart wrote: >> >> >> Hi, we recently upgraded our heimdal servers from solaris to linux >> RHEL6 and from