Supporting custom requests for MS-NRPC

Alexander Bokovoy abokovoy at redhat.com
Fri Sep 26 06:00:44 EDT 2025


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



More information about the krbdev mailing list