Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

What the scientists have in their briefcases is terrifying. -- Nikita Khruschev


devel / comp.protocols.kerberos / Re: kadmin not working after server migration, but kdc works

SubjectAuthor
o Re: kadmin not working after server migration, but kdc worksGreg Hudson

1
Re: kadmin not working after server migration, but kdc works

<mailman.102.1663770645.8148.kerberos@mit.edu>

  copy mid

https://www.novabbs.com/devel/article-flat.php?id=301&group=comp.protocols.kerberos#301

  copy link   Newsgroups: comp.protocols.kerberos
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!tncsrv06.tnetconsulting.net!.POSTED.mailman.mit.edu!not-for-mail
From: ghud...@mit.edu (Greg Hudson)
Newsgroups: comp.protocols.kerberos
Subject: Re: kadmin not working after server migration, but kdc works
Date: Wed, 21 Sep 2022 10:29:57 -0400
Organization: TNet Consulting
Lines: 20
Message-ID: <mailman.102.1663770645.8148.kerberos@mit.edu>
References: <YynL5A9eZog8XQNu@pc220518.home.grep.be>
<03a01502-744e-d72f-d8b5-bff5e2980826@mit.edu>
<Yyn8l/Qed7tgqZqU@pc220518.home.grep.be> <871qs5yg3g.fsf@hope.eyrie.org>
<YyrBL9bEEmFayl3U@pc220518.home.grep.be>
<b0aeb636-a019-59fa-67c7-105255a1f1ac@mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Info: tncsrv06.tnetconsulting.net; posting-host="mailman.mit.edu:18.7.21.50";
logging-data="10880"; mail-complaints-to="newsmaster@tnetconsulting.net"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.9.1
Cc: kerberos@mit.edu
To: Wouter Verhelst <w@uter.be>
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=ZT0fGP5yYwdPqx4OWXKKO1ScyWZqlX3TVRCIADpFRoNmaAHBkIR5laUnhjHhhpcfNxaKwztbiV5Y2a8Rba3QzQ2Yf2FdWywR5v1cpWF23lniJ5m0KKwlr3/+igaWElbKbswygtBESiP4pDUj8jHZC38kOs5vwfmiM2TCEZjmZg/sUcYhRh82Wz5g4wHG5+eNZJ7hPmktyjXacBIGKWcxb0SJbO3SWKG+ffEL8EuW3p4gg+0IiV2Bvdymgr5uCma/NezQeRHC/DWW6D9QIgEHrRvtfXz1Kc1FQKzcR1GkcebMWoUxDiPu17gOcAeP2PXZ26E7nB687ddCSmxruqkZrQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector9901;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=SKOMKO3FNvw1j6qcUWTmvl6qRysS8JFwLbg5m1pICmU=;
b=OgBpc2aEWpvII/kXvf/uHDODHY+nOtW/rNdf19j2hAf1T0DzTVlOELgUTTq5QJFlDoYjgza8wl0ZSSg5qkcCmKutDuTr13/L5MrzxpgCLqRJfh2Xru2g44FGlPYWjgfR8v1diNdlZmcG7BICRXAg9F7FFQ63WQu/l0de0FMmaUy9Ut1hFoqVFq61U3eJosC7Pedmba5rmxjjZDV54YEu9mbjq8/Juta5IBMGA1u5F1z3o5RwThFvkVgEMjqbvtmTHjABEyWhksh7HhowQPE2k64Qtua3gPPets4DbewoYDa0O2c1TtGFOfy/DLXtra15EYascBfG5c1XWdifNxcJUw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
18.9.28.11) smtp.rcpttodomain=mit.edu smtp.mailfrom=mit.edu; dmarc=pass
(p=none sp=none pct=100) action=none header.from=mit.edu; dkim=pass
(signature was verified) header.d=mit.edu; arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector2;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=SKOMKO3FNvw1j6qcUWTmvl6qRysS8JFwLbg5m1pICmU=;
b=fJHL7VxbZsLZyJFmFShrC3ZLuGoP4Z/pKpAbfydnVWwqJjRAy7rMV5LzZ0I54fR9hryghd4j84aF6GEsH/I6HFL3mj5BnsXSRf4W9+mnChnqvaoblzxmwmmit0NpZeOogUdbpsbXKJBftGh7AlduiR8epIcq1Iizp5lF6YZuQ+E=
Authentication-Results: spf=pass (sender IP is 18.9.28.11)
smtp.mailfrom=mit.edu; dkim=pass (signature was verified)
header.d=mit.edu;dmarc=pass action=none header.from=mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates
18.9.28.11 as permitted sender) receiver=protection.outlook.com;
client-ip=18.9.28.11; helo=outgoing.mit.edu; pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing;
t=1663770601; bh=SKOMKO3FNvw1j6qcUWTmvl6qRysS8JFwLbg5m1pICmU=;
h=Date:Subject:To:Cc:References:From:In-Reply-To;
b=RSpD9xFDOhwKbUnfARMb+EDXK7ALAcdZlRezhQW7Audaggc/n4+yiK0cejpyAIEkm
bcRBDkvo7cAtO9Uw8VzsF7n9sMSdKAMt8KtwLEgBsf35nrO2LFeX3TpxLPYUSmNU/o
/3ARDJ48zCzhoYuIJYBiqoQvumSpPNtWsr8EP2ccPdzaOts5jp32i9Q8/dEqBp6JZt
GYeH1R7JerUFYURQ5SiLryaUdVREcRyN9NilwlUFDD86zi1piInJhaQj8H12leOIoK
7fdxeN+p0YHVmvxTmWYIBUSZ7wkRZS9cu4eNMZNZ4YnxIJVI3iBdwF7XZH1Mxpghz4
9jrqkbNZsNygg==
Content-Language: en-US
In-Reply-To: <YyrBL9bEEmFayl3U@pc220518.home.grep.be>
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b:0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN8NAM11FT005:EE_|DM6PR01MB5193:EE_
X-MS-Office365-Filtering-Correlation-Id: 345e25f4-b890-4d95-5eb6-08da9bddc4e4
X-LD-Processed: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b,ExtAddr
X-MS-Exchange-AtpMessageProperties: SA
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: hk+gvhegNKShLjBeyw/sXJ+yrb5EtFRcUheRE6hOl/Tsz7GPAa37uyKclsr0XZeJbOA/v8els4xa8Jou279GGc43FxQhEROLNUHzI+FGaM7a6UeZwH9ZRH5s7bdsHtU7a/HxbYbij3+3nJuac1Ho4WKsKlHQeCxq3tka3EJp+36xGBinZNP87AAVUeA+x/o+K3Qiz8v9UzSLcVgBviDOD3DTAababJHpyhoNZTWOlvdw4MXtv+NE7udQHa3oLFtdnvF4H1uGi8E98xte1c7kWPj9frfdbMzqDxDjj5FIu/sQhXtK76g5VM0Julhk85obuEzKP4Jwfhuf5GAcBnJW5hVtnUlP8hrknLyLQr+HwxcxSfyyd6xMXH88GXowTts5Hs7r/6VDRZ1PXxuaM9uLvXiSyEeUDSxlI7cp4UtOcYcOMpt+wObwaU4KchHMG90vwme8TR1KA6eREaGcMrcno9fyI67WuPWDWu8ue5phf8aykHuTI7u7lXwnDsqS4KZjXrUfS2glt6c1ajk9oAJe9sOp+AImUs6OsIzKhkXLnEaL8sU7olBUUuVyHS73QtCTCGXl8rdtc769CXtDWVNh3QRBbRUst8tOSgvKztpGUid3Sc/1gNeDciWNsnz7RRGVtqvDU8OuZ8UzbbLjzSblkKNs9XbT0gbRWsFiLSLgancuTH8hvK1zbntKG29paK/lXNcT95cothrrojSOXCx0KWvbVaN/R4sbljCSFpMLYIq2IF0C1DytQJZZNo6NPZCr9JYTMqYHPZbVPOMwNbeQWIIHHlkqW0d/EIw7zlbFxYaEQavTSQPlw1jw299td2uUYcn7iXsL7V4B0RTBz9cMFA==
X-Forefront-Antispam-Report: CIP:18.9.28.11; CTRY:US; LANG:en; SCL:1; SRV:;
IPV:CAL; SFV:NSPM; H:outgoing.mit.edu; PTR:outgoing-auth-1.mit.edu; CAT:NONE;
SFS:(13230022)(4636009)(376002)(39860400002)(136003)(396003)(346002)(451199015)(31686004)(5660300002)(6862004)(956004)(8676002)(53546011)(68406010)(2906002)(4326008)(70586007)(786003)(36756003)(31696002)(316002)(6706004)(75432002)(7696005)(2616005)(356005)(26005)(6666004)(86362001)(336012)(83380400001)(426003)(478600001)(781001)(43740500002);
DIR:OUT; SFP:1102;
X-Auto-Response-Suppress: DR, OOF, AutoReply
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Sep 2022 14:30:01.8318 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 345e25f4-b890-4d95-5eb6-08da9bddc4e4
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-AuthSource: BN8NAM11FT005.eop-nam11.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR01MB5193
X-OriginatorOrg: mit.edu
X-BeenThere: kerberos@mit.edu
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: The Kerberos Authentication System Mailing List <kerberos.mit.edu>
List-Unsubscribe: <https://mailman.mit.edu/mailman/options/kerberos>,
<mailto:kerberos-request@mit.edu?subject=unsubscribe>
List-Archive: <http://mailman.mit.edu/pipermail/kerberos/>
List-Post: <mailto:kerberos@mit.edu>
List-Help: <mailto:kerberos-request@mit.edu?subject=help>
List-Subscribe: <https://mailman.mit.edu/mailman/listinfo/kerberos>,
<mailto:kerberos-request@mit.edu?subject=subscribe>
X-Mailman-Original-Message-ID: <b0aeb636-a019-59fa-67c7-105255a1f1ac@mit.edu>
X-Mailman-Original-References: <YynL5A9eZog8XQNu@pc220518.home.grep.be>
<03a01502-744e-d72f-d8b5-bff5e2980826@mit.edu>
<Yyn8l/Qed7tgqZqU@pc220518.home.grep.be> <871qs5yg3g.fsf@hope.eyrie.org>
<YyrBL9bEEmFayl3U@pc220518.home.grep.be>
 by: Greg Hudson - Wed, 21 Sep 2022 14:29 UTC

On 9/21/22 03:45, Wouter Verhelst wrote:
> default_principal_expiration = 0

This value is failing to parse as a timestamp. Removing this line
appears to clear up the config parsing error, and the default should
have the same effect.

I see that the documentation for default_principal_expiration says "The
default value is 0, which means no expiration date." I see how someone
would get that from the code when writing the documentation, but clearly
the documented default should be something that parses. (I think you'd
have to write out the beginning of the POSIX time epoch--in local
time--in something like yyyymmddhhmmss format to get this default.) The
whole concept of default_principal_expiration as an absolute time seems
suspect to me; I have trouble imagining a productive realm configuration
where every new principal by default expires on some particular fixed date.

I don't see any meaningful differences between the current code in this
area and the code going back fifteen years or so. So I'm not sure how
this broke during a migration.

1
server_pubkey.txt

rocksolid light 0.9.8
clearnet tor