samba - Apr 2025 - Fwd: Domain member fails to map SID>*ID after DC migrated from Server 2022 to 2025

On Thu, Apr 24, 2025 at 2:25?AM Rowland Penny via samba
<samba at lists.samba.org> wrote:
> Try this one instead:
>
> <snipped>
>
> Making the obvious change.
Thanks. I gave that a shot, but it still results in the same set of errors.
>
> >       map to guest = Bad User
>
> Why do you have that set ? You do not seem to have 'guest ok' or
> 'public' in any shares.
>
> Why 'unix password sync' ? you shouldn't have any users both in
> /etc/passwd and AD.
Only hasty construction of the test lab. These were present in the
default configuration file, and I did not want to remove things that
*could* be important.
It turns out they are not important.
> >       idmap config domtest:range = 500-599
>
> Why such low numbers ? was this domain classic upgraded from an
> NT4-style domain ?
Much worse. UIDs were chosen about a decade ago for coherence with *OS
X* systems which predated the AD domain.
If only I had it to do over, I would!

Stitching responses from your other mail (just to keep the thread from
diverging, and let that fork die)
> There is no such thing as a PDC in AD [...]
Ah, my own naivete then. Thank you.

With an N=3, I can reliably reproduce this on upgrading the domain
controller from Server 2022 to *the latest version of* Server 2025 -
with any of my home domain or lab configurations.

Doing a little bit of bisecting... it looks like specifically
KB5051987, the 2025.02B update, causes this failure.

It appears there is a new access control check for DsrGetDcName in
netlogon (which is visible with debug logging enabled) which fails for
Samba clients.

+ [CRITICAL] Rejecting an RPC call due to error from AccessCheck:
0x6e4 OpNum:20 Method:DsrGetDcName

That substring  ("Rejecting an RPC call ...") does not appear in
netlogon at all prior to KB5051987. Now, I don't yet know why the 2B
update to Server 2022 doesn't have the same behavior...

--

I work at Microsoft on Windows, but not on the AD product, and I am
here solely as a home user with a bug report. That being said: if it
would help for me to bend the ear of somebody over in AD/DS to figure
out if this is a Windows issue or a Samba one, I would be happy to.

d




d

On Sun, Apr 27, 2025 at 6:43?PM Dustin Howett <dustin at howett.net>
wrote:
>
> It appears there is a new access control check for DsrGetDcName in
> netlogon (which is visible with debug logging enabled) which fails for
> Samba clients.
>
Aaaaand it works fine with the experimental feature "client use krb5
netlogon".

Considering that server 2025 introduced the new Kerberos-authenticated
netlogon channel, I suspect that the older one was missed (or
intentionally omitted) in the security fix introduced in the 2025.02B
update.

Thanks for playing along. :)