From: Wang Zhaolong <wangzhaolong3@outlook.com>
To: Stefan Metzmacher <metze@samba.org>,
Namjae Jeon <linkinjeon@kernel.org>,
Jan Koester <jan.koester@gmx.net>
Cc: linux-cifs@vger.kernel.org,
Sergey Senozhatsky <senozhatsky@chromium.org>,
samba-technical@lists.samba.org, linux-kernel@vger.kernel.org,
Tom Talpey <tom@talpey.com>, Wang Zhaolong <wangzhaolong@fygo.io>,
ChenXiaoSong <chenxiaosong@chenxiaosong.com>,
wang zhaolong <wangzhaolong@fnnas.com>
Subject: Re: [PATCH 0/2] ksmbd: NTLM pass-through to a domain controller
Date: Tue, 20 Oct 2026 21:54:51 +0800 [thread overview]
Message-ID: <TYZPR02MB6959BC66EECFB5D178F92012E6672@TYZPR02MB6959.apcprd02.prod.outlook.com> (raw)
In-Reply-To: <0cadbdcf-6074-449c-98f9-3aeda3756160@samba.org>
Hi Stefan, Namjae, Jan,
Thanks for bringing me into the discussion, and sorry for the delayed response.
> And Wang, what are the AD/DC features?
I'm working on adding Active Directory Domain Controller support to ksmbd,
rather than just allowing ksmbd to join an existing AD domain as a member
server.
The initial goal is a single writable AD domain controller, supporting one
forest, one domain and one site, with most of the new AD services implemented
in Rust userspace components.
The planned functionality includes:
- AD directory services, including LDAP, DNS and CLDAP discovery.
- Kerberos KDC and PAC support.
- NETLOGON and domain secure-channel functionality.
- Integration with ksmbd authentication, identity mapping and authorization.
- Windows domain join and logon, including SYSVOL/NETLOGON and Group Policy support.
The existing ksmbd kernel SMB data path would remain in place, while the
AD services and directory/account management would primarily live in userspace.
The implementation is still at an early stage, with some initial discovery,
directory and credential-management components in place. A fully functional
AD DC is still a long way off.
> why making this NTLM specific, I think it would be good to the whole session setup
> blob exchange to userspace, so that authentication is not used in kernel at all?
> And it will also help when IAKERB and other things will be implemented later.
> It would also be good to have the infrastructure working with winbindd being
> the bridge to the domain.
I think keeping authentication protocol handling and identity services in
userspace is worth considering, particularly as support for additional
authentication mechanisms is introduced.
However, I haven't evaluated the implications of moving the entire SMB Session
Setup authentication exchange to userspace yet, so I don't have a concrete
proposal for that interface at this point.
I also understand Namjae's preference for keeping the current NTLM pass-through
changes minimal.
Jan's patches primarily address authentication against an existing domain controller,
while my work aims to implement the domain controller services themselves. These are
different goals, but there may be opportunities to share or align some of the
userspace authentication and NETLOGON infrastructure.
I'd be happy to discuss the architecture and coordinate the development to avoid
overlapping work.
Best regards,
Wang Zhaolong
next prev parent reply other threads:[~2026-10-20 13:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-18 17:53 Jan Koester
2026-10-18 17:53 ` [PATCH 1/2] ksmbd: pass through NTLM authentication " Jan Koester
2026-10-19 1:48 ` Namjae Jeon
2026-10-18 17:53 ` [PATCH 2/2] ksmbd: put the workgroup into the NTLMSSP target info's domain names Jan Koester
2026-10-19 2:00 ` Namjae Jeon
2026-10-19 1:31 ` [PATCH 0/2] ksmbd: NTLM pass-through to a domain controller Namjae Jeon
2026-10-19 10:43 ` Stefan Metzmacher
2026-10-19 13:02 ` Namjae Jeon
2026-10-20 13:54 ` Wang Zhaolong [this message]
2026-10-20 14:24 ` Ralph Boehme
2026-10-20 15:51 ` Wang Zhaolong
2026-10-21 8:56 ` Namjae Jeon
2026-10-20 19:40 ` ronnie sahlberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=TYZPR02MB6959BC66EECFB5D178F92012E6672@TYZPR02MB6959.apcprd02.prod.outlook.com \
--to=wangzhaolong3@outlook.com \
--cc=chenxiaosong@chenxiaosong.com \
--cc=jan.koester@gmx.net \
--cc=linkinjeon@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=metze@samba.org \
--cc=samba-technical@lists.samba.org \
--cc=senozhatsky@chromium.org \
--cc=tom@talpey.com \
--cc=wangzhaolong@fnnas.com \
--cc=wangzhaolong@fygo.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®