I apologise for not knowing the answer to this, especially as I saw it was discussed on the mailing lists but can't find the original article (even searching the archives). Our support teams would like a single smb.conf that can be used as a default world-wide. (allowing for a minimal modification of the "workgroup=" field) This means that you're stuck for what to put in your "password server=" field. If there was a %D substitution for workgroup/domain then "password server = $d.ntpdc.whatever" could be used to automatically configure it using DNS, but better, the original samba mailing list article indicated that there was an automatic configuration method in the wings. Information on this would be appreciated. Tim Towers Technical Architect, UNIX. Merrill Lynch Architecture & Strategy email: towers@ml.com / tim@lorien.demon.co.uk phone: 0171 892 8085
Towers, Tim (London) wrote:> Our support teams would like a single smb.conf that can be > used as a default world-wide. (allowing for a minimal > modification of the "workgroup=" field) > > This means that you're stuck for what to put in your > "password server=" field. > > If there was a %D substitution for workgroup/domain > then "password server = $d.ntpdc.whatever" could be > used to automatically configure it using DNS, but better, > the original samba mailing list article indicated that > there was an automatic configuration method in the > wings.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. 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) ? 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. 1). Evil Hacker (tm) crashes the real NT PDC (quite easy I'm afraid if it has a TCP port 139 open). 2). Evil Hacker (tm) sets their own laptop up as a logon server and registers the 1C name for the domain (which they can now do as the PDC is down). 3). Evil Hacker (tm) uses smbclient to connect as user "root" to a Samba server, and sets his own laptop to allow any password authentication for the user "root"...... 4). Trouble follows........ This is why I haven't added this feature yet. The current password server code could be hacked this way if the name resolution is set to use a NetBIOS name resolution (wins, bcast) but cannot if it is set to use dns. This new feature would *always* be hackable in this way. Any comments, thoughts ? Cheers, Jeremy Allison, Samba Team. -- -------------------------------------------------------- Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. --------------------------------------------------------
Dear Jeremy, Thanks for your swift response, here's our (selfish) reply... :-)> -----Original Message----- > From: Jeremy Allison [mailto:jallison@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