Use Samba With Windows 7 Clients
How well is Microsoft's latest operating system dealing with the Linux world's most popular server software? Charlie Schluting tells you what to expect as you bring Windows 7 clients into your Linux network.
Windows 7 is out, and everyone says they are going to upgrade, finally. What does this mean for your Samba servers? In this article we will talk about our experience using Windows 7 with Samba, both as a domain controller and as a basic file server.
Samba is not important just for those rogue sysadmins who try to avoid buying Windows Server products. Samba is used by storage appliance manufacturers and within a wide variety of other embedded devices. Samba interoperability is therefore important for both IT shops that run Linux servers, and businesses that sell Linux-based devices. Microsoft may not, contrary to popular belief, intentionally break Samba, but updates to the protocol and client default settings (due to complaints about security in the Windows world) often leave Samba unable to operate, which brings us to some good news:
This time, with Windows 7, only half of Samba stops working.
Accessing Samba Shares
Accessing Samba shares from Windows 7 "just works." That is, assuming you're running a relatively recent version of Samba. Samba 3.3.2, which ships with Ubuntu Jaunty, works perfectly with Windows Vista and therefore Windows 7 (they are the same, really). In testing, we had no problem connecting to various different Samba servers and Windows XP-based shares.
If you are stuck with an older version of Samba and cannot upgrade, workarounds do exist. Many NAS devices still run Samba 2.x, and do not have an upgrade mechanism. Before modifying all your Windows 7 machines' registries, it is worth checking with the manufacturer of your storage device to inquire about an upgrade. Failing that, you must "degrade" Windows 7.
Go to: Control Panel -> Administrative Tools -> Local Security Policy
Select: Local Policies -> Security Options
As shown in Figure 1, there are two settings to change.
"Network security: LAN Manager authentication level" -> Send LM & NTLM responses
"Minimum session security for NTLM SSP" -> uncheck: Require 128-bit encryption
After these two settings have been changed, you will be able to connect to older Samba-based file shares.
If problems still exist, one final thing to try is removing the stored credentials for the Samba share. During testing, it's possible that something strange got "stuck" in there. In the Control Panel -> Credential Manager, find and remove the stored credentials for the Samba server.
The "just works" comment should be true for people with an already-working Samba setup, who need to allow access from new Windows 7 clients. If you are trying this for the first time, we have left out a lot of details. Start the Samba project's own documentation.
Joining to a Samba Domain Controller
To join a Windows 7 workstation to your Samba domain controller, you must be running Samba 3.3.4 or higher. It also requires registry hacks within the Windows 7 machine due to security upgrades from Microsoft. Microsoft is not intentionally breaking Samba support, they are simply forcing the Windows Server world to upgrade and deploy more secure mechanisms. Samba often gets caught in the crossfire of forced security hardening, but this is to be expected given that Microsoft doesn't work with or inform the Samba team of upcoming changes.
Failure to join a Samba domain is confusing. The error, as seen in Figure 2, will state, "The specified domain either does not exist or could not be contacted." If the domain controller really was inaccessible, you would get another error, before Windows asked for credential to join the machine to the domain. That error would explain how a domain controller was not found. This error, however, really has nothing to do with a connection error.
Figure 2. Some Windows errors are needlessly confusing.
To get Windows 7 clients to connect to the domain running Samba 3.3.4 or higher, four registry keys need to be changed. For the ones that don't exist, create them.
Two dword keys within HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesLanmanWorkstationParameters:
"DomainCompatibilityMode" = 1
"DNSNameResolutionRequired" = 0
And two within HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesNetlogonParameters:
"RequireSignOnSeal" = 0
"RequireStrongKey" = 0
After setting these, you should be able to join the machine to the existing Samba-run domain. Again, this is assuming you're working in an already-working environment. Configuring Samba to act as a domain controller is covered in the article, Build a Primary Domain Controller With Samba.
If you are adding a new Windows 7 machine to the domain, don't forget to create the machine account in Samba, after the Unix account exists. In Samba: 'useradd -a -m HOSTNAME'. And finally, remember that when joining the Windows 7 machine to the domain, you must use an account that has credentials to add machines.
Windows 7 is largely the same as Vista, so figuring out other problems that crop up doesn't take long, since people have been using and testing the operating system for a few years now. If you are planning to run a Samba domain controller for Windows 7 workstations, we recommend automating those registry setting changes within your installation environment.
Overall, Windows Vista/7 didn't present many surprises. The most common use case of Samba, as just a basic file server, works flawlessly assuming you have a fairly recent version of Samba. Most IT environments running a few Samba shares mixed within a Windows network, should have no problem supporting Windows 7 clients.
Charlie Schluting is the author of Network Ninja, a must-read for every network engineer.