Corporate Reactions to Linux (fwd)

Luke Kenneth Casson Leighton lkcl at
Wed Oct 13 21:06:51 GMT 1999

On Wed, 13 Oct 1999, Fredrik Norrman wrote:

> Luke, you are talking about adding more security for the
> protocol itself so it can cope with evil attacks to the
> NT domain system.

microsoft is doing this by abandoning the dependence on NetBIOS.  this is
done as follows:

- move to port 445 (SMB over TCP).  note that port 137 AND port 138 are
NOT involved here, where 138 is elections and 137 is NetBIOS name reg.

- use dynamic dns (undocumented but secure registration of ip addresses).

- browsing _suspected_ to involve an LDAP front-end to the trust accounts
(i.e the domain-member workstations) but i really don't know.

> What I suggested Samba takes care of is the case where 
> a stupid user who sets up his first RedHat server and 
> misconfigures Samba and brings down the corporate NT network
> because of that. 
> You can easily solve that by checking if _someone else_ is
> already registered as PDC on the network.

in samba? yes, i believe we do this.  however, you still cannot cater for
the case where the stupid user sets up a PDC without a WINS server entry
(wins server = yes) as they will take over the local subnet segment and
therefore disrupt login services on that local subnet.
> While you are at it - do the same thing with the normal 
> name registration in order to avoid name collisions 
> on the network. (btw, We (Axis) do that with _our_ CIFS server)


> NT doesn't handle this very well. Samba can be better, right?

time.  priority.  someone want to address this?
> Another thing to add to the wishlist - A misconfigured
> Samba box can screw up the browsing by incorrectly announcing 
> itself as Master Browser. The result - the samba box will
> only know about itself and 'network neighborhood' contains
> nothing but the poor misconfigured samba box.
> This seems to happen when WINS is not correctly configured.

yes.  it also happens with any other incorrectly configured SMB system,
where such systems are usually win95.

microsoft's addition of "SMB signing" has thrown a new spanner in the
works on this one.  the very presence of the "SMB signing" data at the SMB
layer will cause Win95 to stop working, even with anonymous SMB
connections.  you need to install the "DFS Client 4.1" to get it to work

i have seen networks where rebooting a winnt client (domain member) caused
a network to operate correctly again.  this probably because it happened
to be the wksta that was up the longest, so it won elections.  because it
was not configured with "SMB signing" it caused the network-neigh to
disappear on that subnet.


More information about the samba-technical mailing list