Linux · December 8, 2006 1

How To: Setup and emulate a Windows Server Domain on Linux and make Windows 2000/XP log onto it

This time we’re going to with an issue that is very common in everyday networking and is implemented almost everywhere in some form or the other. The primary issue here is to make two DIFFERENT Operating Systems talk to each other over the network and synchronise and share files without letting off any hint about the complex protocols involved in between.

Windows 2000/XP is used by most home users as standalone workstation. Those who have cared to venture into Windows Networking and tried out the Host to Domain logon model would have an idea where I’m getting at. Normally, a windows workstation would only log onto a domain that is being served by a server called Primary Domain Controller or PDC in terms of Windows Networking. Following this model if we have a machine running a Windows based Server behaving as the PDC and several Windows Workstations which allow individual users to log onto this server – what we get is a massive sharing of resources by all these workstations at a Single Pass Authentication, i.e. whatever shared resources are attached to the server (printers, tape drives – any kind of peripherals) – are made available to EACH workstation as soon as the user logs into the domain. One DOES NOT need to enter a separate set of login credentials (username/password) to access each of these shared resources as it happens when you setup a simple bus network using multiple windows workstations.

Fortunately for us, we have a tool called SAMBA on Linux, that is capable of emulating Windows Domains and can let users running Windows log onto this emulated domain using their login credentials for Linux. In turn, they reap the great benefits of a Linux Server (security, high uptime & stability etc.) while being able to work on all their favourite applications on Windows. The home drives that are created on Linux for each user (usually in the /home folder are directly mapped on as an extra Physical Drive Letter (say, H:, I:, J: … whatever you choose it to be) on your Windows machine – and whatever you save into this drive gets automatically transferred to your home drive on the Linux Server.

The origin of the name SAMBA is from SMB which stands for Server Message Blocks – a protocol used to share files between different Operating Systems with relative transparency.

I decided to write this tutorial after I successfully managed to setup this Windows Domain on Linux and here I am, sharing one more of my adventures in taming the “Linux Beast”. However, unlike the DNS configuration – this was a pleasant breeze. The process is very simple and surprisingly can be accomplished in a very few steps. Besides, the only configuration file that we have to edit is smb.conf that resides in the /etc/samba/ directory.

Requirements for this experiment:

  1. A Server running on Linux – that has the smbd or Samba Daemon up and running
  2. A Windows XP/2000 Pro Workstation – physically connected to the server

If you are unsure about the status of smbd service (whether it’s running or not), check with the command…

shell> service --status-all | grep smb

This should return you a message similar to

shell> smbd (pid 5831) is running...

If not, you can fire up the service by simply typing

shell> smbd -D

Step 1 – Editing the /etc/samba/smb.conf file

This is the one and only file used for configuring the Samba Daemon and there are only a few parameters that you have to edit. Open this file in your favourite editor (vi/emacs etc.).

Right near the beginning you’ll find a section called [workgroup] that looks like…

# workgroup = NT-Domain-Name or Workgroup-Name
workgroup = asterix

The default smb.conf will contain some other name as the name of the workgroup – I set it to asterix for my system. Feel free to change it to whatever you like – but keep it less than 15 characters. It can contain Alphabetic characters, Numbers and Underscores ONLY.

Scroll down a little below till you find a line similar to…

# Security mode. Most people will want user level security. See
# security_level.txt for details.
security = user

The line “security = user” might be commented out with a “#”. If so, just remove the “#” at the beginning. Go a little further down again and find the line…

# You may wish to use password encryption. Please read
# ENCRYPTION.txt, Win95.txt and WinNT.txt in the Samba documentation.
# Do not enable this option unless you have read those documents
encrypt passwords = yes
smb passwd file = /etc/samba/smbpasswd

Once, again, the

 encrypt passwords = yes
smb passwd file = /etc/samba/smbpasswd

lines are likely to be commented out. Remove the comments. You can choose an alternate location for the samba password file, but leaving it where it is wont harm in any way.

A little further down you’ll meet another large block of commented out statements…

 # Browser Control Options:
# set local master to no if you don't want Samba to become a master
# browser on your network. Otherwise the normal election rules apply
local master = yes

# OS Level determines the precedence of this server in master browser
# elections. The default value should be reasonable
; os level = 65

# Domain Master specifies Samba to be the Domain Master Browser. This
# allows Samba to collate browse lists between subnets. Don't use this
# if you already have a Windows NT domain controller doing this job
domain master = yes

# Preferred Master causes Samba to force a local browser election on startup
# and gives it a slightly higher chance of winning the election
preferred master = yes

# Enable this if you want Samba to be a domain logon server for
# Windows95 workstations.
domain logons = yes

Un-comment the line(s):

local master = yes
domain master = yes
preferred master = yes
domain logons = yes

If any of them equate to “no”, set it to “yes”. The “os level = 65” is usually set to a much lower value, but setting it to 65 gives a big performance boost according to man pages.

Following this, right in the next block, you’ll find these statements…

# if you enable domain logons then you may want a per-machine or
# per user logon script
# run a specific logon batch file per workstation (machine)
; logon script = %m.bat
# run a specific logon batch file per username
logon script = %U.bat

Both the “logon script = %m.bat” and “logon script = %U.bat” and commented out. I am using a logon script on per user basis – so that’s the one I un-commented. A word about logon scripts here. This logon script will reside on the Linux Server itself, but it is actually a MS-DOS BATCH FILE. It’s not directly run by Linux, but dished out to the Windows workstation once the login credentials are settled. This logon script may contain any number of commands, ranging from commands to map your Linux HOME DRIVE to a logical windows drive and/or synchronizing your workstations CLOCK with the Server’s Clock. We’ll come to this later on towards the end of the tutorial. If you un-comment the “logon script = %m.bat” line, then your logon script’s name has to be WindowsNameOfYourWorkStation.bat. If you are using per-user basis like me, then you’ll have to create a copy of this script with the name of every user that intends to log onto your domain. As you can guess, the %m and %U variables expand to take on the machine name and user name respectively. DO NOT, under any circumstances un-comment BOTH. That could lead to a lot of confusion for the Domain Controller. More later.

Towards the bottom end of the file you are going to find a large section dedicated to mapping different shares between Windows and Linux. Find the section named “netlogon“:

# Un-comment the following and create the netlogon directory for Domain Logons
[netlogon]
comment = Windows Network Logon Service
path = /home/netlogon
; guest ok = yes
writable = no
public = no
; share modes = no

In my default .conf file, the comment was different and I changed it to the “Windows Network….” – you can modify it to whatever you feel like.

Next the line “path = /home/netlogon” – uncomment this and set the path to point to whatever directory you want to keep your logon scripts in. Set “writable” and “public” to “no”. Comment out “guest ok = yes” and “share modes = no”.

THAT’S IT. Save the file and quit.

Step 2 – Setting up Machine Account & User Accounts in SAMBA

All the Windows machines that will log onto the Linux Domain are required to have an entry corresponding to their Windows names, in the samba database. The machine names as well as the user names are to be added to a group calledsmbuser” which doesn’t exist on its own. So first create this group…

shell> groupadd smbuser

Next, we create an entry with the name of the Workstation that is going to hook onto this domain controller. Find out the Windows name of your system (Desktop > My Computer > Right-Click > Properties > Network Identification TAB > Properties).

In the dialog box that comes up you’ll find a field called Computer Name. That is the name of your machine. In my case the windows name of my workstation is “WorkStation“. So I used that here. Remember to replace it with yours.

This name, added with a “$” sign at its back is going to be your machine name in samba. So “Workstation” becomes “workstation$“. Next use the following command to add this to Samba:

shell> useradd -g smbuser -d /dev/null -s /bin/false workstation$

Note: The name that you find on your Windows system might contain MIXED CHARACTER CASING – but for Linux, convert the whole name to LOWERCASE and then add the “$” sign.

Next, add this windows client to the samba password database…

shell> smbpasswd -a -m workstation

Note that this time we DO NOT INCLUDE the “$” at the end of the computer name. The option -a tells samba to add the client name and option -m specifies that this name is the name of a computer and NOT a user.

Next, what we are going to do is create user accounts in Samba, which will be used to login from the Windows machines.

shell> useradd -g smbuser -d /dev/null -s /bin/false microscopicearthling

One word here – notice we are allotting a null directory and null shell to the users and the machine name – since these users won’t need shell access & can login directly from windows.

If you already have some users setup in your Linux Server, you can skip this step and add the user directly to the samba password database. If that case the samba user will inherit the home folder that had been created while creating the user account. Say, I have an existing user account called “someone“. I’ll use the following command to add him to the samba database.

shell> smbpasswd -a someone

Notice that I’ve removed the “-m” option, since this is an actual USER that we are adding. For any other user, replace the “someone” with the corresponding username. You can change the PASSWORD that the user will use, by using…

 shell> smbpasswd someone

But make sure that the user has been added to the samba database through the step right before this – else “smbpasswd” will spit out some error message like:

Failed to find entry for user someone.
Failed to modify password entry for user someone.

Another important point: the user you are adding to the samba database – has to exist as a valid user of the Linux Server, i.e. the user has to have an active account on the server created with the command “useradd”. Only then, he can be added to the samba database as a remote logon user.

Next, add the user “root” into the smbpasswd db the same way…

shell> smbpasswd -a root

Step 3 – Configure the netlogon.bat – LOGIN SCRIPT file

Recall that while we were editing the smb.conf file, we came across a line: “path = /home/netlogon” towards the end of the file. Switch over to this directory now. The directory wouldn’t be created automatically, so you need to change to /home and create one called netlogon in it. Now enter this directory and fire up your editor. Create a file called “netlogon.bat” that will serve as a template for all users. Whenever you add a new user to the samba database, you have to make a copy of this file as that username.bat. So for a new user, “someonelse” we’ll simply copy over netlogon.bat as someonelse.bat.

The contents of the batch file will be as follows…

net use Z: /HOME
NET TIME \\getafix /SET /YES

The first entry maps your Linux Home folder as a DRIVE named Z:\ in Windows. So whatever you save in drive Z: gets saved directly to your home folder on the Linux Server – and the files/folders – all acquire the strong security settings that Linux offers. Thus no one else should be able to view your files – unless you set their attributes such that they get shared with others in your group or domain.

The second line, sets the TIME of your Workstation by syncing it with the time of the server. The \\getafix is the hostname of my server. Replace it with whatever your Linux server hostname is.

Step 4 – Restart smbd

The Samba daemon needs to be restarted so as to load the new configuration options. Simple step, just do…

shell> smbd -SIGHUP

Step 5 – FINAL Step: Make your Windows Workstation join the Linux Domain

Follow this step depending on your OS…

  • For Windows 2000: Desktop > My Computer > Right-Click > Properties > Network Identification TAB > Properties
  • For Windows XP: Desktop > My Computer > Right-Click > Properties > Computer Name > Click on the Change button

The lower part of the dialog box should contain two fields with radio buttons namely, Domain and Workgroup. Normally, you’d see some random entry in the workgroup field – usually from the settings that you had specified during windows installation. Click the radio button beside the DOMAIN and enter the name of the domain that you’d specified in your smb.conf file right at the beginning using the clause “workgroup = asterix”. In my case, I entered asterix as the domain name here and clicked OK.

Windows Name & Domain Logon Settings

There will be a short delay, after which you’ll be asked to enter a pair of login credentials that has authority to join the samba domain. Use your root/password combination. After another short wait, you’ll be informed that your workstation has successfully joined the domain and that you should restart your computer for the changes to take effect.

Upon reboot, you’ll see a completely different kind of splash screen – one that you’ve never seen before in standalone mode. It’ll tell you to press Ctrl+Alt+Del to login and thats what you should do. Next, you’ll be presented the standard login screen. Click on the Options and you’ll see one more drop-down list titled “Log onto:” – click on that and you’ll be presented with TWO options. One is the name of your Windows machine – which will be selected by default. If you use this – you’ll log on locally – as you’d do on a standalone system. The OTHER one is the name of the Linux Domain that you just joined.

Select that and enter the username/password that you had created for yourself or “someone” in the samba password database.

That’s it – you should log into a windows normally – but beware you wouldn’t find most of the icons on your desktop that you normally have when you log on locally as an administrator. You’ll be presented with a bare minimum set of icons, determined by the windows access rights that you’ve specified for your system. Most of the common applications will be there in the Start Menu though. To log back in locally, just log out and switch the “Log onto:” option to your local machine name.

When you click on My Computer you should see another drive called H: which as I said before is mapped onto your home folder on Linux Server.

WARNING:

I believe it’s very necessary to know what you are heading for when you setup a login process like this.

Windows 2000 and XP have something called “ROAMING PROFILES” which basically means that whatever you save on your Desktop – all your files, icons & registry and windows settings propagate to the Linux server when you log out and gets saved in your home folder. When you log back in these setting migrate back to your local windows system and take effect – creating the exact desktop state you’d left it in. This ensures all the personal preferences of every user using these systems remain intact. While the feature sounds good – it’s a HUGE DRAWBACK (drag) from networking perspective – as it can create immense bottlenecks. These profiles are not small in size by any means – each profile is at least 4-5MB in size. When the network is small and consists no more than 10 computers – this is pretty all right to have enabled. But when you consider the a network of nearly 150 computers (like my school network) – with over 500 users logging in and out several times a day – you can imagine the amount of traffic this generates – just by downloading the profile when you log in and uploading it back when you log out. This alone can bring the whole network down in a matter of days.

SOLUTION:

Turn off the Roaming Profiles in Win2K/XP on your windows workstatoin when you use this model. The performance gain achieved is thousand folds better than clogging the whole network just trying to save your icon settings. You can do so by opening the Start Menu > Run and typing gpedit.msc in both Win2k and XP. This will bring up the Group Policy Editor.

In the Group Policy Editor, follow this route: Local Computer Policy > Computer Configuration > Administrative Templates > System > Logon. This brings you to a panel on the right where you can turn off the roaming profile. In XP it is very easy. There will be an option called Only allow local user profiles and Prevent Roaming Profile Change from Propagating to the Server. Enable these two and your job is done. For Windows 2000 – you have to look around in the same panel and have to enable/disable a combination of options to disable to roaming profile as a whole. More on Win2K later.

Have fun….and all the best ๐Ÿ™‚