[PATCH] DNS and Subdomain patches

Samuel Cabrero scabrero at zentyal.com
Fri Sep 12 09:49:58 MDT 2014


Hi Andrew,

here is a test for domain naming context creation, it may be useful for
your tests.

Samuel.

On jue, 2014-09-11 at 15:17 +1200, Andrew Bartlett wrote:
> On Fri, 2014-09-05 at 09:08 +0200, Stefan (metze) Metzmacher wrote:
> > Hi Andrew,
> > 
> > >>> 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. 
> > 
> > Sounds ok for now.
> > 
> > >> 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.
> > 
> > The main user would be a trust against a Samba3 domain with security=domain.
> > wbinfo -u and wbinfo -g.
> > 
> > The thing we need to avoid for security=ads is LDAP. It has the same
> > Problems as SAMR.
> > 
> > In the long run I'd try to use the users credentials for "management"
> > style operations
> > which trigger SAMR or LDAP operations, e.g. via wbinfo commands.
> > Everything else should just use NETLOGON and LSA with schannel.
> > 
> > >> 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.
> > 
> > Can you push them to the subdomain-wip branch for now?
> 
> I've been looking over the code (still not run it yet, been a crazy
> week), and the big issue I see is that cm_open_connection() and
> cm_prepare_connection() is built totally on the concept of SMB
> connections.   Even the cm_connect_lsa_tcp() ends up using an SMB socket
> to work out if the DC is alive. 
> 
> It might be OK that we make that SMB connection, perhaps anonymously,
> and then do TCP.
> 
> I guess I need to stop reading code and start trying it out however :-)
> 
> Andrew Bartlett
> 

-- 
Samuel Cabrero - Developer
scabrero at zentyal.com

Zentyal - Active Exchange
www.zentyal.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-python-test-for-domain-naming-context-creation.patch
Type: text/x-patch
Size: 8334 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140912/c4a437d1/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20140912/c4a437d1/attachment.pgp>


More information about the samba-technical mailing list