How to debug the integration of a Windows 7 machine into a Samba 3 domain?

Question

We are running a Samba 3 domain (Samba 3.5.6) with a LDAP backend. Lately, we installed Windows 7 on a virtual machine (called schnellwienix) and joined the computer to the domain, following the hints on the Samba Wiki Windows 7 page. The Windows machine acquitted the joining with a success message, and our domain controller (DC) created a correct machine account. Everything seems to be in order.

However, when any domain user tries to log in, the Windows logon screen gives the error message

There are currently no logon servers available

The NETLOGON service on the Windows machine regularly logs two failure messages: The "no servers available" above, and "RPC call failed". The problem occurs every time the machine is rebooted and persists until a machine administrator goes to "My Computer"->"Manage"->"Local Users and Groups" and tries to look up any Domain Account there, which causes the problem to go away until machine reboot. Rebooting schnellwienix, restarting smbd, nmbd and winbindd on the domain controllers or re-joining the domain did not help.

We have two running domain controllers that are successfully used by a few dozen Windows computers for logging on. asterix is the PDC configured with

domain logons = Yes
domain master = Yes
local master = Yes
preferred master = Yes

obelix is the BDC with all masters set to No, but domain logons = Yes. Both DCs connect to the same WINS server, which gives the correct addresses for PDC, DC and LM on request (checked via Samba's net lookup command). Every computer resolves to its correct name in the DNS, but no special Windows domain names are configured in the DNS.

I've tried to analyze a network traffic dump of the conversation with the domain controller:

1. schnellwienix acquires an IP address via DHCP and gets the correct DNS and WINS server addresses in the packet.
2. schnellwienix queries _ldap._tcp.dc._msdc.<ourdomain> over DNS, getting no such domain.
3. schnellwienix registers its own name over NBNS and queries for the PDC, getting the IP of asterix.
4. schnellwienix sends a packet of SMB_NETLOGON protocol with the message SAM LOGON request from client to the mailslot \MAILSLOT\NET\NETLOGON with its computer name and an empty user name. At first it sends to the broadcast address, then (after name resolution, probably) to both the broadcast address and asterix. It reliably and quickly gets a respons "SAM Response - user unknown" from both the asterix and obelix.
5. SMB_NETLOGON is re-tried by schnellwienix at regular intervals, but is always failing.

The Samba log files on both asterix and obelix show absolutely nothing on the incident at log level 10.

The network topology is trivial: All computers are in the same and only subnet, except for the WINS server, which is supplied by the University and its address made known by DNS. We have the same problem intermittently on another Windows 7 machine, all other machines run fine. However, this is our first virtual Windows machine, and it is virtualized by VirtualBox with a bridged network interface.

Does anyone have any idea what is going on here? What can I do to debug this further?

Answer 1

If you are getting errors trying to resolve the DNS name and the WINS server is not returning proper responses (which what the SMB_NETLOGON packets are), this means that your Win7 machine will not be able to discover a domain controller to talk to. This is inline with the error message you are getting.

To help you troubleshoot those types of errors, enable Netlogon logging by running "nltest /dbflag:2000ffff" and after reproducing the problem look at %windir%\debug\netlogon.log. You will see the machine trying to locate a domain controller and what the errors it is getting are. Once you fix those, it should work fine.

Since you mentioned that the WINS server is supplied by the university, is it actually reachable from the VM? Likely you can't do NetBIOS name resolution because your WINS server is unreachable and your DNS configuration is busted (the error in step 2).