[20550] in Kerberos_V5_Development
Re: Supporting custom requests for MS-NRPC
daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Sep 29 14:38:26 2025
Message-ID: <7329c864-87ff-4535-8642-b89b8f9f3ccd@mit.edu>
Date: Mon, 29 Sep 2025 14:38:09 -0400
MIME-Version: 1.0
To: Alexander Bokovoy <abokovoy@redhat.com>
Cc: krbdev@mit.edu
Content-Language: en-US
From: "Greg Hudson" <ghudson@mit.edu>
In-Reply-To: <aNowuKjCWNigpbcV@redhat.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: krbdev-bounces@mit.edu
On 9/29/25 03:09, Alexander Bokovoy wrote:
> Since it needs access to the encrypted keys, that separate daemon would
> effectively be a KDC in the sense that it will need to verify signatures
> and issue a PAC content. It is a large duplicate of the feature set
> provided by the KDC code.
I don't understand how that squares with the proposed option 2:
Option 2. Implement a custom pre-authentication plugin that hooks into
KDC's loop (via vt->loop()'s verto_ctx passed there) and handles custom
requests over the custom (e.g. UNIX domain socket) interface. All it
needs is access to the KDC's krb5 context to be able to call for KDB
methods and perform PAC validation.
In this design option, how would the custom code leverage the KDC code
for signature verification and PAC issuance?
> I would consider having a separate daemon in such case a security issue
> as well.
Is it a security issue that kadmind is a separate daemon from krb5kdc?
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
