[PATCH] DNS and Subdomain patches
abartlet at samba.org
Thu Sep 4 23:49:17 MDT 2014
On Tue, 2014-09-02 at 14:23 +0200, Stefan (metze) Metzmacher wrote:
> Hi Andrew,
> >>>> I'm still working on tidying the rest up, but I expect to have it back
> >>>> to you tomorrow.
> >>> The patches that had sufficient review are in master, and the rest is in
> >>> my subdomain-wip tree.
> >>> Can you clarify to me what more you want done on the crossRef partitions
> >>> patch, beyond your improved API (which I'm quite happy with, and I fixed
> >>> to use ctx.domsid)?
> >> The patch is fine.
> > Can you please push it then?
> >> But reading the context of this change showed a possible 2nd problem
> >> with the same LDAP object.
> >> I see windows used the 'rootTrust' attribute instead of 'trustParent'.
> >> There might be also other related problems.
> >> so it would be good to have a Windows 2012R2 enviroment with
> >> msDS-Behavior-Version=4 with the following 6 domains
> >> in just one forest with 'DC=rootdomain,DC=example,DC=com'
> >> as forestroot:
> >> DC=rootdomain,DC=example,DC=com
> >> DC=rootlevel1,DC=rootdomain,DC=example,DC=com
> >> DC=rootlevel2,DC=rootlevel1,DC=rootdomain,DC=example,DC=com
> >> DC=otherdomain,DC=example,DC=com
> >> DC=otherlevel1,DC=otherdomain,DC=example,DC=com
> >> DC=otherlevel2,DC=otherlevel1,DC=otherdomain,DC=example,DC=com
> > I'm not sure I can promise to create 6 domains any time soon. As each
> > needs a unique SID, I can't just clone them, and it becomes a total pain
> > to manage more than just 3 or 4 VMs...
> We might not need all of them at the same time.
> Maybe the following two setups are all we need:
> It would be also interesting how the transitive trust network is
> constructed in these
> situations. Is everything routed via the forest root or are there trusts
> between parent and child domains based on the partition DN.
> >> Then setup the same thing with samba
> >> and compare the objects under
> >> CN=Partitions,CN=Configuration,DC=rootdomain,DC=example,DC=com
> >> (including the nTSecurityDescriptor attribute).
> >> As well as "*,nTSecurityDescriptor" for the domain (and DomainDnsZones)
> >> partitions.
> > Also, can you look at the subdomain-wip branch, not as a final review,
> > but to let me know if I am working in the right direction? Do you have
> > any comments on the approach taken in the patch? Is the idea to use smb
> > signing in winbindd reasonable?
> I think instead of using the machine account for smb authentication
> against domain controllers of another domain, we should try to use
> ncacn_ip_tcp, as windows does for netlogon connections.
> Falling back to anonymous smb connections for ncacn_np.
> The security of the DCERPC layer is enough for NETLOGON and LSA
> when we use schannel for both.
> I think we should try to use NetrEnumerateTrustedDomains()
> in msrpc_trusted_domains() and only fallback (For older Samba DCs) to
> lsa_EnumTrustDom*() as this seems to be the only thing that requires
> cm_connect_lsa() and a policy handle, which is not available over
I just looked, and this is what we already do in winbindd_ads.c. So we
would only use LSA if we are not in security=ads mode, or we are talking
to our internal domain.
> For SAMR we can just use the machine account and SPNEGO with sign or seal
> at the DCERPC layer, with a fallback to schannel.
> At the DCERPC layer we should do a fallback to anonymous
> only if we have winbind sealed pipes = no and require strong key = no.
> If we use our machine account for smb against our own domain
> we should force smb signing by default.
> Is the domain trust account able to do smb authentication via krb5?
> We should also think about changing the "client ldap sasl wrapping" default.
I've added a patch for that.
> What we also need is some more information in the list of domains.
> We need to have a list of direct trusts (maybe with a priority)
> and a list of all trusts, where each domain has a reference to the direct
> trust that injected the domain. This is important
> as we need to contact a dc of the direct trust when authenticating users
> of indirect trusts. Currently we just use the IS_DC variable, and I
> guess we do
> the wrong thing if this is set to 'true'.
This is the biggest task here, I've not started on this yet. We will
require fully connected trusts for the timebeing.
> Except for SAMR (which we should avoid as much as we can) we should only
> ever contact
> directly trusted domains and allow the remote dc forward netlogon and
> lsa requests.
I agree. SAMR should mainly be used for password changes.
> In addition to NETLOGON and LSA we could have a drsuapi connection
> (using krb5)
> for our own domain and other direct trusts.
> Windows seems to forward LSA Lookup calls as DsCrackNames calls
> (maybe only to GC servers).
Thanks for the above. It wasn't as much trouble as I expected. I'll
tidy up these patches and propose them. Any thoughts on other things
like should we drop the GUID check on the AddRefs calls?
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: This is a digitally signed message part
More information about the samba-technical