[PATCH] DNS and Subdomain patches

Andrew Bartlett 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?
> 
> Done.
> 
> >> 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:
> 
> DC=rootdomain,DC=example,DC=com
> DC=rootlevel1,DC=rootdomain,DC=example,DC=com
> DC=rootlevel2,DC=rootlevel1,DC=rootdomain,DC=example,DC=com
> 
> and
> 
> DC=rootdomain,DC=example,DC=com
> DC=otherdomain,DC=example,DC=com
> DC=otherlevel1,DC=otherdomain,DC=example,DC=com
> 
> 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.

OK.

> The security of the DCERPC layer is enough for NETLOGON and LSA
> when we use schannel for both.

OK.

> 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
> ncacn_ip_tcp.

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.

Good.

> 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?

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
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...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140905/2c57803f/attachment.pgp>


More information about the samba-technical mailing list