Re: kadmin: failing dump/load

+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

Re: iprop: Problem forcing complete database sync

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

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

> 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

Re: How to disable DNS lookups?

> 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

Re: How to disable DNS lookups?

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

Re: How to disable DNS lookups?

> 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,

Re: How to disable DNS lookups?

> 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

Re: How to disable DNS lookups?

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

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

> On Jun 29, 2017, at 12:45 PM, Nico Williams <n...@cryptonector.com> 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 <n...@cryptonector.com> wrote: >>> On Wed, Jun 2

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

> On Jun 29, 2017, at 12:45 PM, Nico Williams <n...@cryptonector.com> 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 <n...@cryptonector.com> wrote: >>> On Wed, Jun 2

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

> 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)?

Re: Re-encrypt on change of master key

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 <hbh...@oxy.edu> > wrote: > >> On Mar 14, 2

Re: Re-encrypt on change of master key

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

Re: Documentation of principal attributes

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

Re: Heimdal 7.1 and the sqlite backend

> 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

Re: Heimdal 7 Release candidate 1 (7.0.1) available

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

Re: Heimdal 7 Release candidate 1 (7.0.1) available

+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

Re: Heimdal 7 Release candidate 1 (7.0.1) available

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: > > >