Re: KDC acting as both master and slave
On Thu, May 31, 2018 at 08:03:22AM -0700, Adam Lewenberg wrote: > > I am trying to set up a chain of KDCs where KDC1 replicates from KDC2 and > KDC2 replicates from KDC3. > > Thus, KDC2 is both a master and slave. > > However, I cannot get this to work. If iprop-slave is running on KDC2, then > KDC1 will not replicate from KDC2. As soon as I stop the iprop-slave > process, KDC1 starts replicating. > > Is it possible to have a Heimdal KDC act as both a master and slave? If so, > how? It is not currently possible because ipropd-slave maintains an exclusive lock on the log file thus preventing other writers. We will consider taking a more liberal strategy with this lock. Can you describe your use case a bit more to help justify this? Also, can you create an issue in https://github.com/heimdal/heimdal to track this? Thanks, -- Roland C. Dowdeswell
Re: Expired tickets not renewed
On Wed, Aug 09, 2017 at 09:58:04PM +0700, Victor Sudakov wrote: > > Now if I destroy the expired ticket by "kdestroy --credential=host/techno..." > a new ticket is received and gssapi-with-mic is again successful until > the new tickets expires again. > > I'm beginning to think of a cron job which would destroy hourly all > the service tickets... all except the TGT. To bring the conversation back a little to the original point: It appears that Heimdal 1.5 had incorrect behaviour. The ccache code should skip expired credentials when finding service tickets. This looks like it was fixed by the following commit: commit 0f1ae2d10186afb654df8f50cc78663eb53f27a9 Author: Nicolas Williams <n...@cryptonector.com> Date: Fri Aug 2 18:55:36 2013 -0500 Use KRB5_TC_MATCH_TIMES when looking for creds So, if you upgrade, this issue will be resolved. -- Roland C. Dowdeswell
Re: How to disable DNS lookups?
On Tue, Jul 25, 2017 at 11:20:57PM +0200, u-hd-p...@aetey.se wrote: > > Given that SRV records as a matter of fact are defined via A[AAA] records, > (and given that A lookups historically _are_ interposed by /etc/hosts) > what says that /etc/hosts are to be ignored if an A lookup happens as > a consequence of an SRV one? Actually, I do not think that A lookups historically are interposed by /etc/hosts. I think that it is more accurate to say that historically there have been functions called gethostbyname(3) and getaddrinfo(3) which mediated by the definitions in /etc/nsswitch.conf choose whether to do files, DNS, LDAP, YP, etc. In all of the implementations that I've seen, once you call into one of those modules, it will either return an entire answer back up or fail which allows the NSS framework to pass control to the next module. In some cases, mostly with YP there are ways to mix the modules a bit but those are mostly used for the passwd and group maps rather than the host map. -- Roland C. Dowdeswell
Re: How to disable DNS lookups?
On Tue, Jul 25, 2017 at 11:20:57PM +0200, u-hd-p...@aetey.se wrote: > > > As you can see, getaddrinfo(3) will only use DNS to chase the CNAME > > defined in DNS and does not consult /etc/hosts in the middle of a > > You refer to a certain implementation which is not a specification > by itself. What do the applicable standards say? Since we are discussing our processing of SRVs rather than CNAMEs, I'll limit my conversation to the relevant stanards for SRVs. >From RFC2782[1] page 4, the target of a SRV RR: Target The domain name of the target host. There MUST be one or more address records for this name, the name MUST NOT be an alias (in the sense of RFC 1034 or RFC 2181). Implementors are urged, but not required, to return the address record(s) in the Additional Data section. Unless and until permitted by future standards action, name compression is not to be used for this field. A Target of "." means that the service is decidedly not available at this domain. Note that it states "the domain name of the target host". /etc/hosts doesn't contain domain names but rather host names. It also urges implementors to return the address records in the Additional Data section. This implies, I think, the addresses are to be obtained by the implementor probably on the domain name server. Later in RFC2782, on page 6 (according to the below URL), there is a section entitled "Usage rules" which again clearly states that a SRV-cognisant client SHOULD use a procedure which includes querying DNS for the results of the SRV RR targets: For each element in the new list query the DNS for address records for the Target or use any such records found in the Additional Data section of the earlier SRV response. Later in the "Notes:" section, the RFC states: - If the Additional Data section doesn't contain address records for all the SRV RR's and the client may want to connect to the target host(s) involved, the client MUST look up the address record(s). (This happens quite often when the address record has shorter TTL than the SRV or NS RR's.) An "address record" in the context of an RFC about DNS is clearly a DNS A or RR and not an entry in /etc/hosts. [1] https://tools.ietf.org/html/rfc2782 -- Roland C. Dowdeswell
Re: How to disable DNS lookups?
On Tue, Jul 25, 2017 at 06:14:36PM -0700, Henry B (Hank) Hotz, CISSP wrote: > > 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 with as little surprise > as possible. I use /etc/hosts based deployments as well and note that there are many advantages. We are not suggesting that we break this. If you specify hosts in /etc/krb5.conf, then we will continue to use getaddrinfo(3) to look them up. In fact, we have recently fixed this because Heimdal used to unconditionally add a trailing dot to kdc names which makes using /etc/hosts difficult unless you know this [undocumented] piece of information. But, if you specify: [libdefaults] dns_lookup_kdc = true 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 DNS and not subjected to search lists and the like. -- Roland C. Dowdeswell
Re: How to disable DNS lookups?
On Tue, Jul 25, 2017 at 09:47:18AM +0300, Heikki Lindholm wrote: > > On 24.07.2017 19:40, Roland C. Dowdeswell wrote: > >On Sun, Jul 23, 2017 at 08:23:52AM +0300, Heikki Lindholm wrote: > >> > > > >>The Heimdal version identifies itself as 1.5.2. The main problem is that > >>Heimdal doesn't appear to use /etc/hosts for looking up the KDC's IP > >>address, but goes to DNS, and fails. > > > >1.5.2 is quite old and, IIRC, I've seen this before. You can work > >around it by adding the kdc name with a dot at the end as an alias in > >the hosts file. > > Thank you very much. That trick did it. It's weird, though. I would have > likely never arrived at the same solution by myself. It's a work-around in the Heimdal code which appends a trailing dot to hostnames when looking them up to avoid the DNS search path specified in /etc/resolv.conf. Viktor and I discussed relaxing this yesterday because we believe that it is counter-intuitive. It certainly confused me, but I worked it out by reading the code rather than the documentation. The approach that we think will work in the short term is to append the trailing dot iff the hostname came from DNS SRV RRs as they should not honour the DNS search path. The existing behaviour will be able to be replicated by those who are using /etc/krb5.conf by appending their own trailing dot to the configured names. In the longer term, we should likely stop using getaddrinfo(3) for names obtained from DNS SRV RRs and directly query DNS for them as this matches expectations. That is: you wouldn't expect that if you find _kerberos._udp.my.realm IN SRV 0 0 88 foo.my.realm that an entry for foo.my.realm in /etc/hosts would then override the DNS for it. -- Roland C. Dowdeswell
Re: How to disable DNS lookups?
On Sun, Jul 23, 2017 at 08:23:52AM +0300, Heikki Lindholm wrote:
>
> The Heimdal version identifies itself as 1.5.2. The main problem is that
> Heimdal doesn't appear to use /etc/hosts for looking up the KDC's IP
> address, but goes to DNS, and fails.
1.5.2 is quite old and, IIRC, I've seen this before. You can work
around it by adding the kdc name with a dot at the end as an alias in
the hosts file.
So, if your kdc is kdc1.example.com, then your /etc/hosts line should
look like this:
1.2.3.4 kdc1.example.com kdc1.example.com. kdc1
or something quite like that.
--
Roland C. Dowdeswell
Re: How to quickly get a snapshot of the Heimdal DB file
On Sat, Apr 01, 2017 at 04:59:56PM -0700, Adam Lewenberg wrote:
>
> I am looking for a quick way to get a snapshot of the Kerberos
> database file.
In addition to the other methods suggested already, you could just:
$ kadmin -l dump
which can be later loaded with:
$ kadmin -l load
Or one could even grep the entries out that you wish to restore and pass
them to:
$ kadmin -l merge
if, say, you wanted to revert some entries to the dump file that you
created using the cronjob that we all generally have in place.
--
Roland C. Dowdeswell
Preparing for the Heimdal 7 Release
Dear Heimdal Community, A team consisting of staff from Two Sigma Open Source and AuriStor is starting the release process for Heimdal version 7. We have changed the version of the master branch to 6.99.1 which will be considered our beta. During the beta period, we will be fixing remaining issues. In addition, we are asking for the community to submit any final patches or bug reports before the 1st of November. We expect to publish the first release candidate on or near the 11th of November. Why 7? We are adopting a new versioning scheme. o Each feature release will have a new major number. o The minor will be a patch level. A value of 0 is reserved for release candidates. A value of 99 is reserved for development. o Stable releases will not have a micro number. o Micro numbers will be incremented in release candidates and development as needed. For example, the first release candidate will be 7.0.1. The next 7.0.2, then 7.0.3, etc. When the final release candidate is deemed production quality, it will be renumbered as 7.1. All bug fixes will then be 7.2, 7.3, etc. New development for Heimdal 8 will be 7.99.1, 7.99.2, 7.99.3, etc. When the next feature release is issued its version number will start with 8.0.1 as the first release candidate and the first release will be 8.1. What will be in 7? We have a lot of major improvements since our last official release, including: o hcrypto is now thread safe on all platforms and as much as possible hcrypto now uses the operating system's preferred crypto implementation ensuring that optimized hardware assisted implementations of AES-NI are used. o RFC 6113 Generalized Framework for Kerberos Pre-Authentication (FAST). o iprop has been revamped to fix a number of race conditions that could lead to inconsistent replication. o The KDC process now uses a multi-process model improving resiliency and performance. o AES Encryption with HMAC-SHA2 for Kerberos 5 draft-ietf-kitten-aes-cts-hmac-sha2-11 For a more detailed list of changes please see: https://github.com/heimdal/heimdal/blob/master/NEWS which contains a bullet point summary of the major security, feature and bug fix changes that have been applied to the Heimdal source tree over the last four years since the release of 1.5.3. The list is currently not complete and we will be reviewing the git log to add features and bug fixes to the list before we make the final release. We expect that the ABI for libgssapi and libkrb5 will be unchanged from the prior release (1.5.3). If any differences are discovered during the release process, we will then fix them if practical or document the differences in the release notes. And, again, we aren't quite finished. Organizations and individuals wishing to submit changes to Heimdal for this release are encouraged to do so no later than 1 November 2016. The release process: Each release candidate will be given two weeks for testing and usability feedback. If a serious bug is uncovered during the review period then a new release candidate will be issued once the bug has been fixed. If after two weeks from candidate release no new showstopping bugs are uncovered, then the release candidate will be declared final. -- Roland C. Dowdeswell
