[PATCH] DNS and Subdomain patches

[Andrew Bartlett]

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

I'm not sure, but I don't think we should be using the domain account as
a kerberos principal of its own.  This just seems totally wrong.
Certainly it is not available for NTLMSSP (I checked that). 

> We should also think about changing the "client ldap sasl wrapping" default.
> 
> 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'.
> 
> 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.
> 
> 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).

So, with lots of work to do and a larger refactor of winbindd proposed
above, how do you suggest we proceed?  Are you able to work on some of
this?

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