Proposal: Good Neighbor Policy

[John E. Malmberg]

Dan Kaminsky <effugas at best.com> wrote:
>
>I believe it is imperative that, in the coming developments of PDC
>functionality, a *primary release objective* needs to be that we *not*
>disable any network that a novice administrator incorrectly configures
>Samba within.
>
>The story I relayed earlier referenced what happened at a *very* large
>multinational company--Linux workstations *banned* at their San Jose site,
>all because of a misconfigured routing daemon.


An incident recently happened at a division of a large multinational company
that I know of where the network was severely disrupted.  It was traced to
SAMBA running on a commercial UNIX box.

The network archictect for that collection of the divisions now wants to
totally ban SAMBA in that corporation as a result.

The problem was caused by SAMBA (unknown version) getting into a browser
election war with the NT Domain controller.  It was jamming quite a few
CLASS C networks.


It appears that there is some incompatabilities between the browser protocol
that NT uses and the protocol that Microsoft documents.

A non-SAMBA issue that occured that basically shutdown sections of an NT
network was browsing and PATHWORKS 5.0B /VMS.  If the PATHWORKS system was
up when the browser election happened, the PATHWORKS system would always
win.  That meant the NT network would lose completely as browsing would
effectively stop working.  So it meant that every time the NT PDC was
rebooted, the Pathworks Server would need to be shut down.  PATHWORKS 5.0C
fixed the problem by allowing browse mastering to be disabled.

I do not know exactly what the compatability problem was.  PATHWORKS 5.0 is
based on code licensed from AT&T (GLOBALSYS) that is licensed from
Microsoft.  LANMAN 2.3 is how it identifies it self.


Based on these experiences, I always recommend that anyone adding SAMBA to
an NT domain, not allow the SAMBA box to take part in browser elections.

-John Malmberg
WB8TYW at QSL.NET