[39388] in Kerberos
Re: Stateless PKINIT?
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Mar 15 12:19:00 2024
Message-ID: <faf7c1cd-c87c-42c4-a300-83bf177d55fc@mit.edu>
Date: Fri, 15 Mar 2024 12:17:44 -0400
MIME-Version: 1.0
Content-Language: en-US
To: Yoann Gini <yoann.gini@gmail.com>
Cc: Ken Hornstein <kenh@cmf.nrl.navy.mil>, kerberos@mit.edu
From: "Greg Hudson" <ghudson@mit.edu>
In-Reply-To: <15626AF7-93B5-47CA-84B7-A6CF967015A1@gmail.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: kerberos-bounces@mit.edu
On 3/15/24 06:15, Yoann Gini wrote:
> Informations about the principal (name and everything) could be
> extracted from the certificate. Principal and certificate contains the
> same informations.
To issue a ticket, the KDC doesn't need to know directory-type
information such as real names, but it does need to know
Kerberos-specific policy information like "how long can the ticket
expiration time be". That information could presumably be standardized
across clients, which is why I suggested a template principal.
> Other option I wonder is using the LDAP backend to answer dynamic
> content (we have an LDAP gateway in our codebase, so we can use it as a
> backend API between MIT Kerberos and our identity store).
>
> Doing so the main issue would be to know what Kerberos need to write, to
> handle it.
The KDC does not need to write to the KDB, although it will attempt to
do writes to maintain account lockout state (which is irrelevant to the
configuration at hand). Attempts to write can be disabled via the
settings documented here:
https://web.mit.edu/kerberos/krb5-latest/doc/admin/lockout.html#disable-lockout
When synthesizing a client principal entry (or creating a template), be
sure to include the KRB5_KDB_REQUIRES_PRE_AUTH and KRB5_KDB_DISALLOW_SVR
principal flags.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
