samba - Jul 2014 - Client Uses Impostor DC

Hi, 
We have two domain controllers running Ubuntu 12.04 and Samba 4.0.6-Debian. The
other day, we had a user set up a Windows Server 2012 computer on our
development network for testing. This user chose to set up his Windows server as
DC, DHCP server, DNS server, and more, for a new domain that he gave the same
name as our production domain (let's say both domains are named
"domain.com"). Windows 7 clients on the development network correctly
recognized that there was no trust relationship between the impostor DC and the
workstations, and consequently fell back to using the appropriate/legitimate
domain.com DCs. However, one Linux client running Ubuntu 10.04 and Samba 3.4.7
configured to use domain.com now attempted to use the fake domain.com DC to
authenticate, despite not being able to join the fake domain.com domain. Once
the Windows server was taken offline and clients' winbind service restarted,
these linux clients returned to successfully authenticating agains the correct
domain controllers.
Is this a known issue? Are there any preventative measures we could take with
either the Ubuntu 10.04/Samba 3.4.7 client or with the DCs to prevent this issue
from happening again if a counterfeit DC were ever to be placed on our network
again?

Thanks, 

Ben Cundiff 
Associate Sysadmin 
X-ES Inc. 
bcundiff at xes-inc.com

BC> Are there any preventative measures we
BC> could take with either the Ubuntu 10.04/Samba 3.4.7 client or with
BC> the DCs to prevent this issue from happening again if a
BC> counterfeit DC were ever to be placed on our network again? 

In a word, No.

If you allow someone physically connected to your network to setup a(n)
DNS/DHCP/DC server, there's really nothing you can do to prevent the
predictable havoc that will ensue.

Clients "find" the correct DC to contact to attempt authentication via
DNS. If DNS is whacked, then all bets are off. If a DHCP server is running rogue
and handing out bad addresses and options [namely DNS servers] then you
can't "fix" that.

There's no security issue, since the clients will be attempting to contact
the "bogus" DC with the PKI they used to generate the trust
relationship with the "real" DC, and so the
communication/authentication will simply fail.

So, you simply have to have ways to prevent/detect/neuter people who setup rogue
services on your network, with DNS being one of the most critical. [I tend to
recommend the neuter option - as in castrate or spay.]

---
While there's to many variables to guess at, I'd guess the
"problem" DC clients got bad DNS servers via the bad DHCP server, and
from that point on, nothing worked. The machines still working got DHCP leases
from the "good" DHCP server, along with the good DNS servers, and they
worked fine.

But unless you happened to gather a lot of data we can examine posthumously,
we're all guessing at exactly what happened. And frankly the exact details
really don't matter. Rogue DHCP/DNS servers are going to break a lot of
stuff, and there's not a lot you can do about it, other than stopping such
things from happening.


-Greg