Windows displays incorrect ACE Trustee Names when displaying ACEs for Samba server in an ADS parent/child forest?

Richard Sharpe realrichardsharpe at
Thu Jun 30 16:00:11 MDT 2011

On Thu, Jun 30, 2011 at 2:23 PM, Richard Sharpe
<realrichardsharpe at> wrote:
> On Thu, Jun 30, 2011 at 12:25 PM, Richard Sharpe
> <realrichardsharpe at> wrote:
>> On Thu, Jun 30, 2011 at 11:35 AM, Richard Sharpe
>> <realrichardsharpe at> wrote:
>>> Hi,
>>> I have noticed an interesting problem in an ADS forest where I have:
>>> 1. rjstest.local as the root of the forest (domain is DIFFNAME),
>>> 2. subtree1.rjstest.local as a subtree that is part of rjstest.local
>>> (domain is SUBTREE1),
>>> 3. A Samba 2.5.8+ member server that is joined to subtree1.rjstest.local,
>>> 4. A share on my Samba server called FunnyShare where
>>> SUBTREE1\administrator has full access and the group DIFFNAME\domain
>>> admins also has full access.
>>> When I bring up the share properties on a Windows server, it shows the
>>> trustee that is the SID for DIFFNAME\domain admins as SUBTREE1\Domain
>>> Admins.
>>> In looking over a capture of the Trans2, NT QUERY SECURITY DESCRIPTOR
>>> the correct SIDs are being returned. The only interesting thing I can
>>> find is that there is a DsGetRolePrimaryDomainInformation request
>>> prior to the NT QUERY SECURITY DESCRIPTOR that is also directed at the
>>> member server which has what looks like wrong info:
>>> DNS Domain: subtree1.rjstest.local
>>> Forest:            subtree1.rjstest.local
>>> The second value looks wrong and should be rjstest.local, IMO.
>>> In looking at rpc_server/srv_dssetup_nt.c, I find this:
>>>        if (lp_security() == SEC_ADS) {
>>>                dnsdomain = talloc_strdup(ctx, lp_realm());
>>>                if (!dnsdomain) {
>>>                        return WERR_NOMEM;
>>>                }
>>>                strlower_m(dnsdomain);
>>>                basic->dns_domain = dnsdomain;
>>>                /* FIXME!! We really should fill in the correct forest
>>>                   name.  Should get this information from winbindd.  */
>>>                basic->forest = dnsdomain;
>>> Is it possible that this incorrect information is confusing Windows?
>>> It sure will confuse users, and I wonder if the correct SIDs will be
>>> set if we try to add ACEs from different domains via Windows.
>>> At the moment it is not clear if we are keeping the forest anywhere, either ...
>>> Comments would be useful. Am I barking up the wrong tree?
>> Well, a quick rebuild demonstrates that this problem has nothing to do
>> with DsRoleGetPrimaryDomainInfomation, it seems. I hard coded the
>> correct info, but nothing has changed.
> Verified that the same problem does not occur on a Win2K08 member
> server ... digging deeper now.

OK, so the bug seems to be in lsa_LookupSids2 ... the node requesting
the SecDesc is sending the lsa_LookupSids2 request to the Samba server
(but so it did to the Win2K08 member server) and Samba is
mis-translating the SIDs. It returns the domain as the same even
though the authorities portions are different.

I guess I know where to look to fix the code now.

Richard Sharpe

More information about the samba-technical mailing list