Bug 11517 - Samba GPO issue when Trust is enabled
Summary: Samba GPO issue when Trust is enabled
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: 4.9.0rc3
Hardware: All All
: P5 critical (vote)
Target Milestone: 4.9
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
Depends on:
Reported: 2015-09-14 08:41 UTC by Brascon
Modified: 2018-09-10 23:57 UTC (History)
9 users (show)

See Also:

traces_for_sambabug11517.tar.xz (2.53 MB, application/x-xz)
2018-06-05 16:06 UTC, Arvid Requate
no flags Details
Samba 4.8.4 patch to allow user policy for native domain to function, even when trusted domains are enabled. (1.08 KB, patch)
2018-08-15 19:45 UTC, Joshua Songy
no flags Details
Work in progress patches on top of 4.9 (should also apply to 4.8 and 4.7) (18.88 KB, patch)
2018-08-28 11:52 UTC, Stefan Metzmacher
no flags Details
Patches for v4-9-test (67.36 KB, patch)
2018-09-04 08:00 UTC, Stefan Metzmacher
metze: review? (abartlet)
slow: review+
Patches for v4-8-test (67.36 KB, patch)
2018-09-04 08:00 UTC, Stefan Metzmacher
metze: review? (abartlet)
slow: review+
Patches for v4-7-test (67.36 KB, patch)
2018-09-04 08:01 UTC, Stefan Metzmacher
metze: review? (abartlet)
slow: review+

Note You need to log in before you can comment on or make changes to this bug.
Description Brascon 2015-09-14 08:41:05 UTC
Hi Experts

We are testing Samba 4.3 and we are having somes isssues with GPO when the external trust (Windows AD and Samba) is established to gpo will not work with the error below:

User policy could not be updated successfully. The following errors were encount ered:

The processing of Group Policy failed. Windows could not determine if the user a nd computer accounts are in the same forest. Ensure the user domain name matches the name of a trusted domain that resides in the same forest as the computer ac count. Computer Policy update has completed successfully. 

When we remove the trust the gpo works, also when the trust is established i can enumerate users from Windows AD, but not from Samba AD except when i issue wbinfo -u --domain=windowsAD.net 

can someone asist if it is a known issue? smb.conf below



# Global parameters
        workgroup = TEST
        realm = TEST.NET
        server role = active directory domain controller
        passdb backend = samba_dsdb
        dns forwarder =
        rpc_server:tcpip = no
        rpc_daemon:spoolssd = embedded
        rpc_server:spoolss = embedded
        rpc_server:winreg = embedded
        rpc_server:ntsvcs = embedded
        rpc_server:eventlog = embedded
        rpc_server:srvsvc = embedded
        rpc_server:svcctl = embedded
        rpc_server:default = external
        winbindd:use external pipes = true
        idmap_ldb:use rfc2307 = yes
        idmap config * : backend = tdb
        map archive = No
        map readonly = no
        store dos attributes = Yes
        vfs objects = dfs_samba4 acl_xattr

        path = /usr/local/samba/var/locks/sysvol/cnx.net/scripts
        read only = No
        write ok = Yes

        path = /usr/local/samba/var/locks/sysvol
        read only = No
        write ok = Yes
Comment 1 Stefan Metzmacher 2015-09-14 08:50:39 UTC
While a lot of things regarding trusts have been implemented and tested,
there's still some development effort required to implement full support
for trusts. This is mainly related to winbindd and NTLMSSP, but maybe more.
Comment 2 Brascon 2015-09-14 09:19:42 UTC
Many thanks Stephan, does this mean we cannot use the trust now? is there a work around?, strange thing when i issue wbinfo -u --domain=windowsAD.net  i can enumerate all users in the Windows AD but not from ADUC.


Comment 3 Clive Ferreira 2016-11-09 01:20:50 UTC

Are you trying to edit the GPO of the Samba or Windows domain?

What credentials are you using and which machine or domain are you accessing from?

We have set up a Windows AD and Samba trust ourselves on upstream Samba but have yet to run into any issues yet.
Comment 4 SATOH Fumiyasu 2017-02-12 15:08:35 UTC
(In reply to Brascon from comment #0)
Comment 5 Denis Shestov 2017-11-03 09:41:15 UTC
Same bug. Two AD (one Samba and other Windows) with trusts. When I try to update user policies with gpupdate /force Target: User the same error appears. Computer policy works fine.
Workstation and User accounts are in the same domain.
Samba version 4.6.7-Ubuntu
Comment 6 Arvid Requate 2018-06-05 16:06:19 UTC
Created attachment 14222 [details]

The attached archive contains network traces and level 10 logs of three GPO evaluation test runs (gpupdate /force) on a Microsoft Windows 7 client joined into a Samba 4.8.2 AD/DC.


a) Working GPO evaluation without any domain trust

b) Failing GPO evaluation (user part) in the context of a bidirectional forest domain trust with a Micosoft Windows 2008R2 AD/DC

c) Failing GPO evaluation (user part) in the context of a bidirectional external domain trust with a Micosoft Windows 2008R2 AD/DC

smb.conf, output of testparm -v and the domain keytab are included.
Comment 7 Stefan Metzmacher 2018-06-05 21:13:49 UTC
(In reply to Arvid Requate from comment #6)

I guess the problem lies somewhere in fill_one_domain_info() called from netr_LogonGetDomainInfo, instead we need to use something like
dsdb_trust_parse_tdo_info() for the external trusts.
Comment 8 Stefan Metzmacher 2018-06-05 21:31:05 UTC
(In reply to Stefan Metzmacher from comment #7)

There seems to be more locations in dcerpc_netlogon.c which
could get some cleanup and use dsdb_trust_* helper functions.
Comment 9 Stefan Metzmacher 2018-06-05 21:34:28 UTC
(In reply to Stefan Metzmacher from comment #7)

Can you check if replacing ret3 = gendb_search(...
with just ret3 = 0; will avoid the problem?

That will prove we're searching at the right spot.
Comment 10 Joshua Songy 2018-07-18 16:22:15 UTC
I have identified the root cause of user policy failing for the native forest.

In dcerpc_netlogon.c, in fill_one_domain_info, every trust has the following code run against them:

info->trust_extension.info->flags =

The primary flag here is the cause: every trust is marked as the primary domain for the local forest, and as a result, windows clients get confused and fail to identify a netlogon server to use.

Removing that flag from the trusted domains in the trust list (but not the native domain in the trust list) causes user policy to correctly apply for users of the local forest, even with a trust established.

I have not been able to get user policy to apply to users of a different forest, however. I believe that it has something to do with mis-set flags in either the trust flags or trust attributes.

I have converted the following lines to do correct TDO lookups locally:

info->trust_extension.info->parent_index = 0; /* should be index into array
								 of parent */
info->trust_extension.info->trust_type = LSA_TRUST_TYPE_UPLEVEL; /* should be based on ldb search for trusts */
info->trust_extension.info->trust_attributes = 0; /* 	TODO: base on ldb search? */

Fixing these to use TDO lookups *did not* allow trusted domains to apply user policy correctly, I get the same error about not being able to verify that the user is in the forest.
Comment 11 Joshua Songy 2018-07-18 16:29:50 UTC
As reference for my previous comment:

Note that the bit being set is bit D: "Domain is the primary domain of the queried server."

Setting this on every trust confuses the client, which is receiving multiple primary domains for the domain controller they are querying (which doesn't make any sense).
Comment 12 Stefan Metzmacher 2018-07-19 05:46:44 UTC
(In reply to Joshua Songy from comment #10)

Thanks for testing!
See comments #7 and #8 we need to use more dsdb_trust_* functions
and just return what we have stored in our database
instead of returning hardcoded values.
Comment 13 Joshua Songy 2018-07-19 13:07:58 UTC
(In reply to Stefan Metzmacher from comment #12)

That's what I meant with "TDO" lookups. I converted them over to use the helper dsdb_trust_* functions locally (both for the trust flags and attributes), but it wasn't enough to get policy applying. In fact, it somehow seems to have corrupted something in the samba database and I could no longer add new trusts between the samba install and IPA, even after reverting the change.

I'm not sure if anything else is using that function as a source of truth, maybe causing something to get re-stored wrong?

Anyways, I've been playing with random flag combinations to try and get it working, with no luck.
Comment 14 Joshua Songy 2018-07-19 13:14:15 UTC
(In reply to Joshua Songy from comment #13)
Notably, when I made the change to the helper functions, it did seem to fail to mark *any* of the domains as primary, including the native domain. It was setting the trust flags to 0b100010 for every domain, just indicating the trust relationship is direct and bidirectional.

It looks to me that in addition to fixing these to use the helper functions, some fixes might need to be applied for what trust flags are stored.
Comment 15 Elias 2018-08-12 23:00:34 UTC
(In reply to Joshua Songy from comment #14)
Hey Joshua,

Any news about your tests? You're tested with samba 4.9 version?
Comment 16 Joshua Songy 2018-08-13 14:31:24 UTC
(In reply to Elias from comment #15)
Unfortunately, I have not had the bandwidth to continue my testing much beyond what I have already written.

My tests were all run against 4.8.3 I believe, and I never found a working combination of trust flags and attributes. I'm unsure if this is just me not understanding the MS documentation and using the wrong flags, or if there are other RPC calls that need to be corrected to get everything working.

I did run a patch that removed the NETR_TRUST_FLAG_PRIMARY flag from all trusts except for the primary domain, and it did allow user policy for the native forest to work. I never ran into any issues caused by this. If this is all someone needs working, then I think it is safe to patch that behaviour in.
Comment 17 Elias 2018-08-14 13:52:01 UTC
(In reply to Joshua Songy from comment #16)

Could you make this patch available? I would like to test in my testing environment. :)
Comment 18 Joshua Songy 2018-08-15 19:45:38 UTC
Created attachment 14422 [details]
Samba 4.8.4 patch to allow user policy for native domain to function, even when trusted domains are enabled.
Comment 19 Elias 2018-08-16 21:00:19 UTC
(In reply to Joshua Songy from comment #18)
Thanks for the patch Joshua!!! I already applied and now I will test! I come back here to give you feedback! :)
Comment 20 Mario Codeniera 2018-08-23 02:44:42 UTC
(In reply to Elias from comment #19)

Elias any updates for your test?

I have the same issue with this, tried using Forest/External trust broke the GPO. As working with Samba 4.9.0rc2 which not resolve on this version.

Else will give a try the patch.
Comment 21 Mario Codeniera 2018-08-23 23:26:49 UTC
(In reply to Joshua Songy from comment #18)

Thanks a heap Joshua your patch is a remedy on the issue on the one-way trust (Windows AD users can be authenticated in Samba).

I recompiled and apply to 4.9.0rc3. It's working well at the moment but will check further if there's another issue.
Comment 22 Andrew Bartlett 2018-08-23 23:41:04 UTC
(In reply to Mario Codeniera from comment #21)
So what we need now is a test to this does not regress.

In python using the dcerpc bindings or in smbtorture somewhere would be the best.
Comment 23 Joshua Songy 2018-08-24 13:01:20 UTC
While the patch does fix half the issue, if the patch is integrated, I would like to request that this issue remains open.

Applying policy to users from a trust still won't work, which is still a problem for me.
Comment 24 Stefan Metzmacher 2018-08-28 11:52:52 UTC
Created attachment 14450 [details]
Work in progress patches on top of 4.9 (should also apply to 4.8 and 4.7)

Can someone please test if these work in progress branches also solve
the problem (at least to the same extent as attachment 14422 [details]).

It would be good to get this into 4.9.0.

Comment 25 Joshua Songy 2018-08-28 13:13:05 UTC
(In reply to Stefan Metzmacher from comment #24)

This patch allows me to apply user policy on users from the native forest correctly, same as attachment 14422 [details] (so it seems to work at least as well as that patch). However, I still cannot apply user policy or generate RSOP data for users from an IPA cross-forest trust. I tested this patch by patching an existing test domain we have been running, I might look at testing it against a freshly provisioned domain a bit later today.

I've been working on getting the windows gpsvc logs to generate some useful error messages, but I've been having trouble there. I'll post back here if I generate anything useful.

Let me know if there is anything more specific you would like me to test, I am very interested in helping get this patch (and eventually a patch that works for both user classes) working.
Comment 26 Stefan Metzmacher 2018-09-03 12:07:27 UTC
This also happens with 4.9.0rc releases
Comment 27 Stefan Metzmacher 2018-09-04 08:00:02 UTC
Created attachment 14464 [details]
Patches for v4-9-test
Comment 28 Stefan Metzmacher 2018-09-04 08:00:38 UTC
Created attachment 14465 [details]
Patches for v4-8-test
Comment 29 Stefan Metzmacher 2018-09-04 08:01:07 UTC
Created attachment 14466 [details]
Patches for v4-7-test
Comment 30 Ralph Böhme 2018-09-04 08:18:15 UTC
Reassigning to Karolin for inclusion in 4.7, 4.8 and 4.9.
Comment 31 Karolin Seeger 2018-09-04 08:55:35 UTC
(In reply to Ralph Böhme from comment #30)
Pushed to autobuild-v4-{9,8,7}-test.
Comment 32 Karolin Seeger 2018-09-06 07:15:07 UTC
Pushed to all branches.
Closing out bug report.

Comment 33 Stefan Metzmacher 2018-09-07 08:13:28 UTC
(In reply to Joshua Songy from comment #25)

Can you test 4.9.0rc5 or master and report remaining problems as a new bug report?
Comment 34 Stefan Metzmacher 2018-09-07 08:15:03 UTC
(In reply to Stefan Metzmacher from comment #33)

You may need to recreate the trust to the FreeIPA domain,
as https://bugzilla.samba.org/show_bug.cgi?id=13539 is also fixed
in order to address problems with FreeIPA.
Comment 35 Elias 2018-09-10 11:50:00 UTC
(In reply to Stefan Metzmacher from comment #33)
hello Stefan,

4.9r5 already comes with the patch?
Comment 36 Stefan Metzmacher 2018-09-10 20:27:21 UTC
(In reply to Elias from comment #35)

Yes and also the patch for bug #13539
Comment 37 Elias 2018-09-10 23:57:14 UTC
(In reply to Stefan Metzmacher from comment #36)
Awesome!!! Thanks for everyone!!!