Supporting custom requests for MS-NRPC
Alexander Bokovoy via krbdev <[email protected]> Fri, 26 Sep 2025 13:00:44 +0300
| Newsgroups | gmane.comp.encryption.kerberos.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi, In Active Directory Microsoft has been working on removing NTLM support. One of the remaining parts was the pass-through authentication mechanism[1]. In this mechanism, a domain member cannot validate the password presented by a user from a different domain. Instead, it uses its own mutually authenticated connection to the own domain controller and asks for a pass-through authentication request. Domain controller then uses its mutually authenticated connection to a trusted domain's domain controler to relay this request. The remote domain controller will do authentication and validation of the user credentials and return back the result. For Kerberos-based pass-through authentication Microsoft added few new NRPC protocol messages described in '3.2.4.2 Network Ticket Logon'[2] section of MS-NRPC specification. These basically repeat the pass-through authentication using different messages: '2.2.1.4.19 NETLOGON_TICKET_LOGON_INFO'[3] and '2.2.1.4.20 NETLOGON_VALIDATION_TICKET_LOGON'[4]. The steps described in[2] include 2. Netlogon delivers the request (see section 3.2.4.2.1) 3. The Key Distribution Center (KDC) processes the request and sends a reply (see [MS-KILE] section 3.3.5.8.1) 4. Netlogon processes the reply and sends it to the client (see section 3.2.4.2.2) I asked Microsoft Open Specification documentation team on whether there is an description of how (2) communicates to (3) and got a response that since these components (Netlogon server and KDC) run on the same Domain Controller, there is no network visible communication. In other words, it is a custom interface: From the thread on cifs-protocol@ mailing list[5]: -------------- I have word back from the engineering team on your question. Since the netlogon and KDC binaries are hosted on the same machine for Windows Domain Controllers, the process described is done by the two binaries communicating with each other directly within LSASS. It is not via a network call to the KDC like TGS or ticket renewals. -------------- So I am thinking on how we can implement this in MIT Kerberos-based Samba AD DC or FreeIPA domain controllers. Option 1. Implement a custom pre-authentication plugin that is used by Samba cifs/... service and contains preauth data encrypted using a derivation from the cifs/.. key. This way cifs/.. service could stuff the client's ticket buffer it needs to validate into a preauthentication data and will receive a preauth data back from the KDC side of this plugin after validation as part of AS-REQ exchange. 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. Option 3. Add a new KDC plugin interface that exposes needed functionality and allows to add callbacks into KDC verto_ctx for triggering this functionality. [1] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nrpc/fe2775d4-a3e2-4971-a255-8eef8dd27a27 [2] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nrpc/6e6a6d1b-465a-458a-9f37-ccf2b2cdddb7 [3] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nrpc/e1c68d5c-e6c6-4593-8da8-54be559c90f8 [4] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nrpc/97ff55d3-6bf3-4123-8d41-d419275ecd3d [5] https://lists.samba.org/archive/cifs-protocol/2025-September/004571.html -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland _______________________________________________ krbdev mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/krbdev