Automatically locating domain controller

[Towers, Tim (London)]

Dear Jeremy,

   Thanks for your swift response, here's our
(selfish) reply... :-)

> -----Original Message-----
> From: Jeremy Allison [mailto:jallison at cthulhu.engr.sgi.com]
> Subject: Re: Automatically locating domain controller
> 
> Towers, Tim (London) wrote:
> 
> Ok - this is doable by querying for a DOMAIN<1c> (group)
> name and then attempting to use the list of IP addresses
> returned in order as a password server.

I have tried locating our domain controllers using nmblookup
but have failed. I can get a list of some of the machines in
the domain by searching for the domain name, but suspect I'm
running into a WINS problem (the list is FAR shorter than
I would expect, 30 machines instead of maybe 1000). But I'll
have a go at sorting that out as a seperate issue...

If I can get that working then I can build the process into
the "samba.pkg" package file which we use under solaris.

> Hmmmmm. The question is, do we do this on smbd startup,
> or should we do this on first client connect (better as
> it allows flexlibility w.r.t smb.conf include files, but
> potentially may cause timeouts on connect if the WINS server
> is slow to respond) ?

As far as I can tell...
1) You can't go too wrong doing it when NT does it, on startup.
2) if one of the servers is down, how quickly can you notice and
   how long will it take to change the authentication to a
   backup server. This is a requirement for "enterprise"
   software.
3) Can it use any clever tricks to connect to a server which
   is "closer" in a network topological sense.

> Also, this does mean that Samba will treat as a password
> server any machine that can successfully register a 1C
> name. I haven't done this yet as it bugs me that there is
> no security in name registration. I know this is what NT
> does, but what worries me is the following scenario.

If the security hole is documented then the implementer
can choose whether the risk is acceptible.

We're still using NIS, which has the same security hole,
and as noted above, you can't go too wrong implementing
something in the same way as the system you're emulating.

> Any comments, thoughts ?

Making the domain available to the smb.conf remapping would
allow tricks to be played with DNS. That's the only way I
can think of varying the "password server=" line with
different domains. You can then handle the failover and
security by putting "<ntdomain>.ntdc.company.com" in the
file, and patching DNS to match. I wouldn't like to do it
that way because there's an extra level of administration and
DNS and NT may become out of syncronisation.

I prefer the simpler, NT way of doing things in spite of
the security risk.

I've seen "password server = %m" put forward as a solution
to this, regard it as a desperate security hole but need a
viable alternative (the one machine you can guarentee is
available is the client that is asking for authentication).

   Tim