[PATCH] DNS and Subdomain patches

Stefan (metze) Metzmacher metze at samba.org
Tue Sep 2 06:23:15 MDT 2014


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?

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

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140902/3fa8ca33/attachment.pgp>


More information about the samba-technical mailing list