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

active-directorydomain-controllersambawindows

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:

schnellwienix acquires an IP address via DHCP and gets the correct DNS and WINS server addresses in the packet.
schnellwienix queries _ldap._tcp.dc._msdc.<ourdomain> over DNS, getting no such domain.
schnellwienix registers its own name over NBNS and queries for the PDC, getting the IP of asterix.
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.
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?

Best Answer

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).

Related Solutions

Windows – Useful Command-line Commands on Windows

A little known one is

getmac

It shows the MAC address(es) of your network adapter(s).

Screenshot of running getmac from a Windows commandline window.

Local User Context on AD-Joined Machine – Domain vs Local Account

Your question is not stated very clearly... howewer, here's how it basically works:

Each process running on a Windows machine runs in the context of a user account; this can be one of the three machine accounts (more on this later), a local user account or a domain user account.
A process can be started either by a logged on user, or as a service.
A process started by a logged on user inherits the user's security context, and it can interact with the user's session (keyboard/mouse/screen or RDP).
A service is a process that runs in background without direct user interaction; it can be started automatically when the system starts. A service, too, runs in the security context of a user account, just like any interactive process; this can be a local or domain user account, or a system account. A service can't interact directly with user sessions.
A process running in the context of a local user account can only access resources on the local machine (if allowed); it has no valid credentials to log on to other systems, and it can connect to network resources only by supplying another set of credentials, either those of a domain user account or of a local user account on the remote server.
A process running in the context of a domain user account can access local resources (if allowed) and network resources (if allowed) on other domain joined computers.
A process running in the system context can use one of three system accounts: Local System, Local Service and Network Service. These are built-in to every Windows computer since XP/2003 (before that only Local System existed).
A process running as Local System has full privileges on the system; a process running as Local Service has lower privileges (same as a standard user accounts) and can't connect to network resources; a process running as Network Service has the same local privileges as Local Service, but can access the network.
In either case, when a process running in one of the three system contexts connects to a network resources (so this is only true for Local System and Network Service, as Local Service just can't do that), it authenticates against remote system using the computer's machine account in the domain.

To sum it up:

If the process runs as a local user account, it doesn't have valid logon credentials on remote systems.
If the process runs as a domain user account, this user account is used for logging on to remote systems.
If the process runs either as Local System or Network Service, it logs on to remote systems using the computer's machine account in the domain.

Update:

There's not a single account under which "the machine is booted". When you are at the logon screen, there are lots of things running on the system: basic system services, the programs which actually manage the logon screen itself, and possibly plenty of application services if the system is a server. Each one of these processes can run under a different user account. Most system services, anyway, run using one of the three system accounts (Local System, Local Service, Network Service). You can see which account a service runs as in the Services MMC (and/or in the Task Manager).

The machine SID, as stated by that article and many others, is not actually needed or used for anything, besides being a "prefix" for the SIDs of local user accounts (which, as such, are never seen nor referenced outside the system itself); network authentication on behalf of the system uses the computer's domain account.

Best Answer

Related Solutions

Windows – Useful Command-line Commands on Windows

Local User Context on AD-Joined Machine – Domain vs Local Account

Update:

Related Topic