S4 Experimental patch to make S4 site aware when joined as a member

Andrew Bartlett abartlet at samba.org
Thu Jan 17 23:37:48 GMT 2008


On Fri, 2008-01-18 at 10:19 +1100, ronnie sahlberg wrote:
> Please find for review an experimental patch to add a new resolve
> method to S4 which is used to resolve/locate domaincontrollers.
> 
> The new resolve method uses DNS and CLDAP to locate a DC that belongs
> to the same site as where the S4 member server resides.
> Using sites allows a member server to quickly and reliably find a good
> DC that is near the member server, which is important for very large
> domains
> where you may have hundreds or thousands of DCs but where only very
> few of them are local.
> 
> 
> Using CLDAP from within resolve.a causes a circular dependency in the
> buildsystem which had to be resolved by the very kludgy changes to
> config.mk :-(
> 
> The patch adds a new parameter accessed by lp_dc_resolve_context()
> which differs from lp_resolve_context() in that is also
> offers the "dnssrv" resolve method.  A method you only want to use
> when resolving a DC or other service, but not a normal server name.
> 
> It adds a new parameter "dc name resolv order" which is the same as
> "name resolve order" except that it defaults to try the "dnssrv"
> method first.
> 
> It adds a new database domaindb.tdb where the dns domain name of the
> domain we are joined to is stored. (DNS/CLDAP dc location needs the
> real dns domain name)

Can we please make this ldb?  The only stuff we should use raw tdb for
in Samba4 is performance critical work.  The idea is to make this easily
visible to the admins.  

Is there any reason we couldn't just use the data in this record:

dn: flatname=${DOMAIN},CN=Primary Domains
objectClass: top
objectClass: primaryDomain
objectClass: kerberosSecret
flatname: ${DOMAIN}
realm: ${REALM}
secret:: ${MACHINEPASS_B64}
secureChannelType: 6
sAMAccountName: ${NETBIOSNAME}$
whenCreated: ${LDAPTIME}
whenChanged: ${LDAPTIME}
msDS-KeyVersionNumber: 1
objectSid: ${DOMAINSID}
privateKeytab: ${SECRETS_KEYTAB}

and just add 'site: default-first-site-name'?

> This database can also store the current site name where S4 currently
> resides but this is not used yet.
> This database can later be used to store site/server/subnet
> information when S4 is a domain controller to make it site aware in
> the future when used as a DC.
> 
> To activate "dnssrv" one needs to rejoin to the domain and specify a
> new, third, argument to the join :
> net join NBDOMAIN MEMBER DNS-DOMAIN-NAME

I think this is a poor design - we shouldn't require any more
information than windows uses here, which is a 'domain', that may be
netbios or DNS.  If we don't know (and suspect it's a netbios name),
can't we fire a CLDAP packet at the DC that response with netbios?

> The process to locate a DC when dnssrv is used is :
> 1, first do a global search in DNS for all DCs  (_ldap._tcp)
> 2, try the DCs one by one using a CLDAP ping  until one of the DCs respond.
> 3, the response from the DC to the CLDAP ping contains the name of the
> site that S4 currently resides in (The DC decides this based on the IP
> address of S4)
> 4, now when S4 knows what site it belongs to it issues another, site
> specific DNS search to find the DCs that belong to the same site as
> S4.
> 5, Finally use CLDAP pings to all DCs in our site and check which ones
> are available.
> 
> This means that normally it would only take
> 2 DNS lookups
> 1 CLDAP ping, possibly to a DC to the other side of the world
> and
> n CLDAP pings to the n DCs that are very close to us and belong to the
> same site.
> to reliably find a DC that is very close to us.
> 
> 
> Example: 200 DCs for a domain.   4 are very close and in the same
> site.   196 of them are on the other side of the planet and 200ms
> away.

In terms of the code, I don't see why we need a domaindb abstraction.
Do we really anticipate multiple implementations of this functionality?

Other than that, this seems to be really neat functionality!  I hope we
can clean these bits up and get it into the tree.  Hopefully Jelmer's
plans to simplify the build system will make it easier to fight...

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20080118/328d9385/attachment.bin


More information about the samba-technical mailing list