When creating trusted domains with Windows Server 2016 and older, Samba receives an ACCESS_DENIED response. After that, Windows disconnects the connection. Steps to reproduce: $ samba-tool domain trust create win.dom.net --direction="both" --type="external" --quarantined="no" --create-location="both" --skip-validation -Uadministrator@win.dom.net ... ERROR: REMOTE_DC[DC1.win.dom.net]: failed to query LSA_POLICY_INFO_DNS - ERROR(0xC0000022) - {Access Denied} A process has requested access to an object but has not been granted those access rights. Actual result: "Access denied" error Expected Results: Successful create of a trust domain
Can you please provide a the full output of samba-tool with log level 10 and a corresponding network trace?
You can also remove the try: line and the except: block in OpenPolicyFallback and you will get the NTError we probably miss to handle.
Created attachment 18375 [details] trust create log with -d 10 and commented try-except This is output for command: samba-tool domain trust create winlocal.net --direction="both" --type="external" --quarantined="no" --create-location="both" --skip-validation -UAdministrator@winlocal.net -d 10 and OpenPolicyFallback function with commented try-except: code: def OpenPolicyFallback( conn: lsa.lsarpc, system_name: str, in_version: int, in_revision_info: lsa.revision_info1, sec_qos: bool = False, access_mask: int = 0, ): attr = lsa.ObjectAttribute() if sec_qos: qos = lsa.QosInfo() qos.len = 0xc qos.impersonation_level = 2 qos.context_mode = 1 qos.effective_only = 0 attr.sec_qos = qos # try: out_version, out_rev_info, policy = conn.OpenPolicy3( system_name, attr, access_mask, in_version, in_revision_info ) # except NTSTATUSError as e: # if e.args[0] == NT_STATUS_RPC_PROCNUM_OUT_OF_RANGE: # out_version = 1 # out_rev_info = lsa.revision_info1() # out_rev_info.revision = 1 # out_rev_info.supported_features = 0 # policy = conn.OpenPolicy2(system_name, attr, access_mask) # else: # raise return out_version, out_rev_info, policy
It looks like that the OpenPolicy3() succeeds, but then QueryInfoPolicy2() fails with ACCESS_DENIED using the policy handle returned by OpenPolicy3. A network trace would show more details. If that's the case, then it it sounds like a Windows bug. MS-LSAD states: > Note: LsarOpenPolicy3 supersedes LsarOpenPolicy2 and MUST be used whenever > possible. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-lsad/9f88a19f-3bb0-474c-8308-a9f661e6c760
On the other hand, 3.1.4.4.3 LsarQueryInformationPolicy2 (Opnum 46) has: > PolicyHandle: An RPC context handle obtained from either LsarOpenPolicy or > LsarOpenPolicy2. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-lsad/516f503c-0230-489d-b012-e650b46b66a2 I will contact Micosoft for clarification.
Created attachment 18378 [details] Network trace (rpcclient lsaquery against Windows Server 2012)
If I do a LsarOpenPolicy3 call against Windows Server 2016, I get DCERPC_FAULT_ACCESS_DENIED and the dcerpc connection is closed by the server. The dcerpc fault is unexpected and the disconnect is unfortunate. Normally you get NT_STATUS_RPC_PROCNUM_OUT_OF_RANGE and then be able to call LsarOpenPolicy2 :-(
Created attachment 18379 [details] Draft patches for a fix... These need someone to cleanup, but the basics should work...
> Draft patches for a fix... I checked the patch on the latest version of Samba. Unfortunately, it doesn't work. I am attaching a log with debugging of level 10.
Created attachment 18384 [details] Log with patch from Stefan Metzmacher
The patch metze posted is far from complete. If you call OpenPolicy3 against a Windows Server which doesn't support it, it will close the pipe. Metze implemented this behavior so Samba does the same. He also added a bunch of hacks so that you can test it in selftest (make testenv). The next step is to implement the fallbacks correctly. If OpenPolicy3 fails and we have a disconnected pipe, reconnect and try OpenPolciy2. This is exactly what Windows does and we need to to the same. All the client code (trusts.py, rpcclient, winbind) needs to be able to deal with this. A good start is probably getting the lsa_utils test to work: make test TESTS=samba.tests.dcerpc.lsa_utils I wont be able to work on this the next weeks.
(In reply to Dinar Yulmukhametov from comment #10) Please also upload a network capture belonging to the logs.
I noticed that there's a bug in get_lsa_info() it doesn't pass policy_access correctly to OpenPolicyFallback, it passes it as sec_qos, so access_mask is always 0.
This bug was referenced in samba master: d2ac6221db48b93581d7ce48d31f8851c88b77bc 0c68d9bc0cd5873f7b59be0fe93d64d6d47b5a57 3bbe35d42c4d4a0ce663580dfb035b6beb329ebb a094a29e426cc79e23bb4d866334d7735159fb41 2c171fb1b8c88034a98c3aaf052e99ba5dbbafd9 73ce15e7d5b7ea867849f1aa4fa5390830660f11 f9a3fc19f1e212c54351c3f94978e66fceeb8835 a814f5d90a3fb85a94c9516dba224037e8fd76f1
Created attachment 18571 [details] patch for 4.22
Created attachment 18572 [details] patch for 4.21
Pushed to autobuild-v4-{22,21}-test.
This bug was referenced in samba v4-22-test: 60dc107d2a6154bf3254218e10b91c2a91ee88d9 d0420684649383ffbd309d23c69a0bf8a051fc06 1a3be37e0eb564604b20c5d2ab1842661d466433 310b5c9dcecfba72b3b02632fca08a68c042d2c1 82aa83142598f99d662fb9f16aa20c5e2f5fafa5 1f84f56c6df0813e488701704daf2174bd0f7eb3 8a7346f6c03dd4f5e8394997e1d118d33c950c35 29bd6fe9cbe538b267bf0ed66823cfe8599afb3d
This bug was referenced in samba v4-22-stable (Release samba-4.22.0rc3): 60dc107d2a6154bf3254218e10b91c2a91ee88d9 d0420684649383ffbd309d23c69a0bf8a051fc06 1a3be37e0eb564604b20c5d2ab1842661d466433 310b5c9dcecfba72b3b02632fca08a68c042d2c1 82aa83142598f99d662fb9f16aa20c5e2f5fafa5 1f84f56c6df0813e488701704daf2174bd0f7eb3 8a7346f6c03dd4f5e8394997e1d118d33c950c35 29bd6fe9cbe538b267bf0ed66823cfe8599afb3d
Patch for 4.21 failed during make: ../../source3/rpc_client/cli_pipe.c: In function ‘cli_rpc_pipe_reopen_np_noauth’: ../../source3/rpc_client/cli_pipe.c:3475:19: error: ‘struct rpc_pipe_client’ has no member named ‘assoc’ 3475 | if (rpccli->assoc == NULL) { | ^~ Reassigning to Andreas.
I can confirm the issue and I also run in the same compilation problems when I try to apply the backport for 4.21 Are there any updates? FYR: https://forge.univention.org/bugzilla/show_bug.cgi?id=58299
Created attachment 18650 [details] Patch for 4.21 backported from master/4.22
I tried out the new patch and was able to re-compile the debian package. Steps (on debian 12 / UCS5.2): * apt-get build-dep samba * apt-get source samba * cd samba-4.21.1/ * patch -p1 < ../samba-bug-15680-v4-21-fix-trust-win2026.patch * dpkg-buildpackage -b Will check the trust creation with M$ AD next.
I can confirm that this works with the patched samba 4.21 as expected: samba-tool domain trust create win-2k22.intranet --direction="both" --type="external" --quarantined="no" --create-location="both" --skip-validation -UAdministrator@win-2k22.intranet -d 10 ... no errors The trust relationship is also valid on the Windows AD side. Tested with Windows Server 2022, functional Level 2016.
Pushed to autobuild-v4-21-test.
This bug was referenced in samba v4-21-test: fe5b8928443d3e9aac04b6748ccb9973b883f250 4ae32d6faa0e9e075cdeceb2d57c98f372b00448 1cbbe56266b81ffeedb57f2a3283b274e33981c7 30b077b67810adcd320facf0d41c4a0836fa0abe 0a0d87f4093c88e6ba43951f7182d8bcac49fbc2 e8e6b68539bebf93ad6ec8e86386705cb8f4cc15 b106c7d77aec6c2c82937fb24ef3ee6a16087cb6 ccb5e9694e30028c8bf849fdab1f06ecca861d26
Closing out bug report. Thanks!