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.