A Local KDC

Tue Jun 25 02:39:42 EDT 2024

Hello KRBDEV,

TL;DR

* Can we get support for the KDC to listen on a unix socket only?
* How do we get SID support with default backends?
* More auth ideas about Local KDC use case

## Intro

In October 2023 Microsoft announced an approach to handle NTLM removal by 
adding a local Kerberos KDC on each Windows system [1]. A KDC would be backed 
by the local account store and will not be exposed to the network directly. 
Instead, applications which support GSSAPI authentication would advertise 
IAKerb and would allow a remote authentication to happen with Kerberos. This 
is nothing new, MacOS has a Local KDC running already since several years, it 
also supports IAKerb already [2].

Samba and FreeIPA teams started looking into how we can interoperate with 
Windows systems where IAKerb and a local KDC are enabled. An update to MIT 
Kerberos to address an evolution of the IAKerb specification draft was 
recently merged [3]. We also have a work in progress branch for Samba [4] that 
adds IAKerb support. However, for Samba servers to support Windows clients’ 
use of IAKerb in non-enrolled scenarios, a local KDC configuration has to be 
considered.

For MIT Kerberos-based local KDC configuration a proof of concept is available 
at [5]. Experiments with this proof of concept led us to few considerations.

## Unix Socket

MIT Kerberos allows KDC and kadmind daemons to run bound to a particular set 
of network addresses. This allows isolating a configuration to a localhost, 
for example (127.0.0.0/24) but still makes the KDC running all the time. For 
local KDC configurations an amount of principals stored in the KDC database 
and number of requests to be handled would probably be very low. It would be 
great to allow KDC daemons to operate over UNIX domain sockets and handle its 
startup on demand with tools like systemd socket activation or similar 
methods.

## SID Support

Default MIT Kerberos KDB drivers that can be used for local KDC (lmdb or db2) 
do not support generating SIDs and filling in a netlogon info buffers in PAC 
structures. For Samba interoperability needs, it means, even for a local KDC 
case, we would have to create our own KDB driver to provide handling of 
additional PAC information and will have to synchronize it with Samba’s own 
databases. If there could be a way to overlay individual callbacks on top of 
an existing KDB driver, we could at least have something that would keep user 
and service principals in lmdb and handle PAC issuance using SIDs and account 
details from Samba databases. Perhaps, this is too much to ask and we’d have 
to create a separate KDB driver. At SambaXP’24 Samuel Cabrero demonstrated how 
a varlink interface can be added to winbind daemon in Samba to expose SMB-
specific details over varlink to systemd users and groups interface on Linux. 
Maybe we simply need to create a generic varlink-based KDB driver which would 
look up Kerberos principals information through the varlink. Kerberos 
principals’ information would be stored elsewhere and accessed by KDC via this 
driver, which would also implement PAC issuance based on the information 
exposed by the varlink modules.

## Local user auth with KRB5

Finally, the local KDC approach allows us to make local use of various pre-
authentication methods developed as part of the FreeIPA and SSSD. Those 
methods all depend on a RADIUS-speaking backend daemon behind KDC that FreeIPA 
provides and this daemon, ipa-otpd, can be taught to pick its data over 
varlink as well. As a local KDC prototype shows, a combination of the local 
KDC and SSSD allows it to handle user authentication completely with Kerberos, 
for both passwords and smartcards. With ipa-otpd-like RADIUS backend the same 
setup can also handle multi-factor authentication: FreeIPA supports HOTP/TOTP, 
RADIUS proxying, external OAuth2 device authorization grant, and FIDO2 USB/NFC 
tokens using this method. This already can be achieved without additional 
modifications to MIT Kerberos code base but use of IAKerb creates a new 
challenge. IAKerb is only available over GSSAPI and one cannot use GSSAPI to 
handle initial authentication for anything but password and keytab based 
credentials. Traditional approach was that initial authentication is handled 
with a set of raw Kerberos calls and then GSSAPI Kerberos mechanism simply 
consumes whatever credentials were obtained outside of it. This will not work 
with IAKerb and new, passwordless, pre-authentication methods. A new GSSAPI 
extension is needed to allow handling both a FAST channel establishment and 
additional interactive exchanges these pre-authentication methods require.

Best regards,

	Alexander & Andreas

[1] https://techcommunity.microsoft.com/t5/windows-it-pro-blog/the-evolution-of-windows-authentication/ba-p/3926848
[2] https://ptgmedia.pearsoncmg.com/imprint_downloads/peachpit/peachpit/
bookreg/0321635329/C_DirSerRG.pdf
[3] https://github.com/krb5/krb5/pull/1345
[4] https://git.samba.org/?p=asn/samba.git;a=log;h=refs/heads/asn-iakerb
[5] https://github.com/abbra/local-kdc

-- 
Andreas Schneider                      asn at samba.org
Samba Team                             www.samba.org
GPG-ID:     8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D