Return-Path: Received: from PCH.mit.edu (PCH.MIT.EDU [18.7.21.50]) by krbdev.mit.edu (Postfix) with ESMTPS id 995823FB24; Thu, 24 Dec 2015 00:21:42 -0500 (EST) Received: from pch.mit.edu (localhost.localdomain [127.0.0.1]) by PCH.mit.edu (8.13.8/8.12.8) with ESMTP id tBO5Lgp2029447; Thu, 24 Dec 2015 00:21:42 -0500 Received: from mailhub-dmz-3.mit.edu (mailhub-dmz-3.mit.edu [18.9.21.42]) by PCH.mit.edu (8.13.8/8.12.8) with ESMTP id tBO0JDBc014341 for ; Wed, 23 Dec 2015 19:19:13 -0500 Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) by mailhub-dmz-3.mit.edu (8.13.8/8.9.2) with ESMTP id tBO0JAJZ017613 for ; Wed, 23 Dec 2015 19:19:13 -0500 X-Auditid: 1209190c-f79c96d00000038e-bb-567b39ff9c1f Authentication-Results: symauth.service.identifier Received: from haven.eyrie.org (haven.eyrie.org [166.84.7.159]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id DD.E6.00910.00A3B765; Wed, 23 Dec 2015 19:19:12 -0500 (EST) Received: from lothlorien.eyrie.org (unknown [96.90.234.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by haven.eyrie.org (Postfix) with ESMTPS id 9970B118444 for ; Wed, 23 Dec 2015 16:19:11 -0800 (PST) Received: by lothlorien.eyrie.org (Postfix, from userid 1000) id 11A0BB4156B; Wed, 23 Dec 2015 16:19:10 -0800 (PST) From: Russ Allbery To: krb5-bugs@mit.edu Subject: Multiple incremental propagation issues hosting non-default realms Organization: The Eyrie User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) Date: Wed, 23 Dec 2015 16:19:10 -0800 Message-ID: <8737uspukh.fsf@hope.eyrie.org> MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrIIsWRWlGSWpSXmKPExsWyLIR9vi6DVXWYQeMCBYuGh8fZHRg9ms4c ZQ5gjOKySUnNySxLLdK3S+DKOPXuBXNBv0jF26PsDYxtAl2MnBwSAiYS/2Z0M4PYjAJGErvP vWKFiItJXLi3nq2LkYtDSGAtk8Tyq0ugnFlMEjs372ADqRISKJWYfmAWE4jNJqAisebGXDBb REBU4uXfYyxdjBwcwgLeEqs3u4OE+QXEJfbvbwZbJipgKXGv7y7YGBYBVYnrU88ygpTzCmhL rHoKVsIrIChxcuYTFhCbWUBC4uCLF8wTGPlnIUnNQpJawMi0ilE2JbdKNzcxM6c4NVm3ODkx Ly+1SNdQLzezRC81pXQTIzC8hDgleXYwvjmodIhRgINRiYdX4lZVmBBrYllxZe4hRkkOJiVR 3n6J6jAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrx//wKV86YkVlalFuXDpKQ5WJTEeed+8Q0T EkhPLEnNTk0tSC2CyTJxsB9ilOHgUJLgdbYEmixYlJqeWpGWmVOCrIYTRHCBrOEBWqNoAVTI W1yQmFucmQ5RdIpRUUqc9yZIQgAkkVGaBzcAlhIuMcpKCfMyMjAwCPEAXQD0OKr8K0ZxoKeF ec1B7uDJzCuBm/4KaDET0OI/68pBFpckIqSkGhjjT5ZPTupb2r3r13zl/Z1ROj+3f2LST2Qu WRHQoN63qWThvlmzvk57ulKS6f4Pi6sq03+sM933fbP+5C2sSw9F6qodtOKu+ZTmd6xFcLee serb5P4/W52v/GX9fZUz4foHfrO7e4P+njh8ZVtF9MEnl+deZvDN/3Vxg7LBgXC/f9st1LV4 F7BlKrEUZyQaajEXFScCALnW0eMEAwAA X-Mailman-Approved-At: Thu, 24 Dec 2015 00:21:40 -0500 X-Beenthere: krb5-bugs-incoming@mailman.mit.edu X-Mailman-Version: 2.1.6 Precedence: list Sender: krb5-bugs-incoming-bounces@PCH.mit.edu Errors-To: krb5-bugs-incoming-bounces@PCH.mit.edu X-RT-Original-Encoding: iso-8859-1 Content-Length: 2529 For various reasons (development realms, separate realms for users and machines), I frequently want to host a Kerberos realm on a system that has some other realm as its default realm. This generally works well if one remembers to add -r flags to krb5kdc, kadmind, and all kadmin and related local commands. However, when trying to also use incremental replication, I ran into several related issues. Not sure if this is all one bug or several bugs, so starting with one bug and letting you clone if desired. All of these problems have the same root cause: realm information given on the command line doesn't propagate into all the places it needs to. 1. kpropd does not use the -r flag when deciding what KDC configuration to read, and therefore does not get the correct stanza in /etc/krb5kdc/kdc.conf. The usual symptom is that it doesn't pick up iprop_enable setting and just listens to normal network connections. Workaround: Create separate krb5.conf file with the default realm set to the served realm and using KRB5_CONFIG to redirect kpropd to that config file. 2. When a new replica needs a full replication, kadmind does not pass the realm information from its command-line -r flag to kdb5_util to generate a dump of the database. kdb5_util therefore fails, and the replica end stalls waiting for a full replication. Workaround: Create a wrapper that sets KRB5_CONFIG as above and then execs kdb5_util, and tell kadmind to use that wrapper with the -p flag. 3. Once you get past kdb5_util, kprop run by kadmind has the same issue. I used the same fix and the -K option, plus disabling normal domain-realm mapping and forcing all hosts into the served realm in that secondary configuration, and then added a host/ keytab in the served realm to /etc/krb5.keytab on the replica. I'm not sure if there's a simpler approach using cross-realm authentication. Incidentally, the error reporting on the kadmind side is horrid. With the kdb5_util problem above, the only error reporting in the logs was: Dec 23 22:34:43 dfw3b-rm1-1a kadmind[70510]: iprop_full_resync_1: pclose(popen) failed: No such file or directory which actually means "kdb5_util died with some error message nothing captured." Once kdb5_util was fixed, failures in kprop resulted in no log messages whatsoever on either side. I had to use strace to figure out what was failing. -- Russ Allbery (eagle@eyrie.org)