How To: Setup a DHCP Server on Linux

This is one of the first of a series of tutorials I wrote on taming the Linux daemons. It was first published at Astahost Forums on February 5th, 2005.I’m sure all of you must have come across the term DHCP – anyone who’s connects to the internet has to come across it every now and then. You see the term even on the small setup instructions leaflets that accompany the dial-up internet packages from most of the ISPs. DHCP is what allots you a unique IP address every time you dial out to your ISP. Here’s a short description of what DHCP is and what it can do straight from the Redhat Manuals.

Chapter 18. Dynamic Host Configuration Protocol (DHCP)

Dynamic Host Configuration Protocol (DHCP) is network protocol for automatically assigning TCP/IP information to client machines. Each DHCP client connects to the centrally-located DHCP server which returns that client’s network configuration including IP address, gateway, and DNS servers.

18.1. Why Use DHCP?

DHCP is useful for fast delivery of client network configuration. When configuring the client system, the administrator can choose DHCP and not have to enter an IP address, netmask, gateway, or DNS servers. The client retrieves this information from the DHCP server. DHCP is also useful if an administrator wants to change the IP addresses of a large number of systems. Instead of reconfiguring all the systems, he can just edit one DHCP configuration file on the server for the new set of IP address. If the DNS servers for an organization changes, the changes are made on the DHCP server, not on the DHCP clients. Once the network is restarted on the clients (or the clients are rebooted), the changes will take effect.

Furthermore, if a laptop or any type of mobile computer is configured for DHCP, it can be moved from office to office without being reconfigured as long as each office has a DHCP server that allows it to connect to the network.


  1. You have a Linux Server up and running with DHCP pre-installed on it. This will be referred to as your DHCP Server from now on.
  2. You have another Windows 2000/XP workstation running and connected to the Linux Server. This is required to test if the DHCP is being able to allot the IP addresses properly. This will be referred to as your DHCP Client from now on.
  3. You have only ONE network card (NIC) attached to the Linux Server and it’s name according to Linux Device List is eth0.

If you are unsure about what your NIC is referred to as, type the following in a linux console: shell> ifconfig

The output you get should look similar to this:

eth0   Link encap:Ethernet  HWaddr 00:0D:88:39:D2:69
inet addr:  Bcast:  Mask:
inet6 addr: fe80::20d:88ff:fe39:d269/64 Scope:Link
RX packets:14450 errors:0 dropped:0 overruns:0 frame:0
TX packets:15310 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1539185 (1.4 Mb)  TX bytes:1763316 (1.6 Mb)
Interrupt:225 Base address:0xb800

This tells you that indeed your NIC is present and set to handle Linux networking. See if you can spot the important parameters like the Server’s NIC Hardware Address (MAC address), the Server’s alloted IP, Subnet Mask etc. They’re all grouped up in the first 2-3 lines of the output.

My server’s IP is set to and that’s what you see on first half of the second line, along with the Broadcast Address ( and Subnet Mask (

Step 1 – Editing the /etc/dhcpd.conf file

Most likely the file dhcpd.conf would not exist beforehand in you /etc directory. We’ll start with a blank file. If you want to save up on some typing, you can load up the sample configuration file that comes with linux and modify the parameters. If you have the most recent version of DHCP you’ll find the sample configuration file at /usr/share/doc/dhcp-3.0.1rc12/dhcpd.conf.sample. The location of the sample file might vary from distribution to distribution – so if you can’t find it in this directory try using the locate command to find the location of the file. A quick example of how to spot a file with locate…

shell> locate dhcpd.conf

Personally I prefer starting off with the blank file and inserting the configuration data according to my needs. So lets get on with it. Type in the following four lines at the beginning of the file…

default-lease-time 86400;
max-lease-time 86400;
ddns-update-style interim;
ignore client-updates;

A short explanation:

  • default-lease-time 86400 – This tells the DHCP server that the minimum amount of time that an IP is alloted to a client a.k.a lease, shouldn’t be less than ONE DAY (86400 seconds). One day is a good figure to keep for your default lease time. This will lease an IP address for 86400 seconds if the client host doesn’t ask for a lease over a specific time frame.

  • max-lease-time 86400 – This again, is the maximum duration for which one particular client host will have the IP alloted to it. When this period is over, the client has to re-apply for a new IP lease – and depending on the range of free IP addresses, it might be given the same IP as it had before or a new one. Be aware that once you have the server running – this process takes place with absolute transparency without any human intervention. Feel free to modify the numbers to suit your need. Normally you wouldn’t need values larger than 86400 – unless you intend to have any of your client hosts to be up and running for more than a day. Say you want it running for 2 days – change the figure to 2 x 86400 = 172800 and so. Whatever number of days you want the lease to stay, just multiply 86400 by that and put the result in. Even if the client host requests a lease time frame which is more than this – the request would be rejected and the client will receive this figure as the maximum lease time.

  • ddns-update-style interim & ignore client-updates – These two lines are required too – but we won’t delve much deeper into these parameters – except that they involve a far advanced concept involving the inner operations of the DNS Server and are REQUIRED here. So just blindly put them in.

  • Below this part put a few blank lines and type in the following lines…

    option subnet-mask;
    option broadcast-address;
    option routers;
    ## The IP address of the name server
    option domain-name-servers;
    option domain-name "";

    These are the global option clauses that take the form:

    option <optionname> <optionvalue>

    The options should be fairly self evident. The first line sets a global subnet mask for your network. The second line fixes the Broadcast address for your subnet – the DHCP Server will advertise it’s services from either this IP ( or use the universal broadcast IP ( The third line sets the address of your router – which in turn shows up as the Default Gateway under windows. If you don’t have one, you can comment out this line. Fourth and fifth line as you can see specifies your DNS Servers IP and your Domain Name. If you have multiple DNS Servers, say and – you should specify them in order of search, i.e. the statement will take this form:

    option domain-name-servers;

    We key in all these parameters here, because certain network services/hosts cannot be allowed to have dynamic IPs. They require fixed addresses to perform properly i.e., any hosts on the network should always be able find these services at fixed addresses.

    Next we come to the Subnet Configuration part of the config file. Go ahead and type in the following…

    subnet netmask {

    As you can see – the first line specifies the subnet of your network and your netmask. Replace my subnet IP with that of yours. The netmask usually always is – which means your network logically wouldn’t have more than 253 client hosts and 254 including your server. My experimental network has just one subnet. You might have many more. In case you do, you have to make another similar block on entry below this one replacing the IPs with those of your second subnet.

    Next comes the clause that takes the form of…

    range <startrange> <endrange>

    – which specifies the IP Block or IP Pool from which addresses will be handed out to the client hosts. As you can see, I was experimenting with it, and set the start range to and end range to – so range of IPs alloted to my clients will start only at .31 and upto a maximum of .250.

    You can repeat the option statements that we used earlier inside this subnet {} block too – in case, you want this subnet to have a different set of dns/router/domain etc. The “options” specified earlier in the file are global and will affect any subnet which doesn’t have it’s own set of option clauses.

    This brings us to the last part of the configuration file. Whatever we’ve put in so far is enough to get your DHCP Server up and running – but in some special cases, you need to tell the server to allot a fixed IP to a certain system. This is possible by setting up a matching list of IPs and Hardware MAC Addresses of those systems. Say I have my own development WorkStation and a friend’s system called Tony who joins my network regularly. So the config options to be entered are…

    # Assign fixed address to certain hosts based
    # on NIC Address
    # My Development Workstation
    host workstation {
    hardware ethernet
    # Tony's Computer
    host tony {
    hardware ethernet
    # Networked Laser Printer
    host laser-printer {
    hardware ethernet 08:00:2b:4c:59:23;

    Once again this part should be self evident:

    • host <hostname>clause specifies the host for which I’m going to fix a specific IP address.
    • hardware ethernet and 00:11:2F:47:54:F2 together specify the MAC address of the client hosts.
    • fixed-address; tells the DHCP Server to allot only this IP against that particular MAC address.

    I’ve defined two systems here – but you are allowed to add in as many systems as you want. I’ve also got a networked laser printer which you can see defined in the third block.

    Be aware though – with every fixed MAC Address/IP combination you specify here, you IP Pool or IP Range that you specified for your subnet will get shorter by one free IP. In effect, if you’d specified around 250 hosts here manually – the whole IP Pool will be exhausted. In case some new system connects to your network – it wouldn’t be able to receive any free IPs. Besides if any of the client hosts has a malfunctioning NIC which has to be replaced – you’ll have to come back here and change the respective entry for its MAC address here and set it to the new one.

    Be very careful about the Opening and Closing Braces {} – if you miss out on any one of them the DHCP server will fail to start. If possible, use a GUI based editor with brace-matching, which helps to a considerable degree here.

    There’s something I forgot to mention though. Since these fixed IP specifications are for clients who are part of your subnet, this whole section should be enclosed within the subnet netmask {} declaration right after the line where you specify the IP Pool range (range;). If you are still unsure where to include this – see the attached sample config file and you’ll know right away.

    Save the file and quit 🙂

    Step 2 – Editing the /etc/rc.d/init.d/dhcpd file

    This is the file that actually starts up the DHCP Daemon during boot time, which in turn reads the configuration options from the dhcpd.conf in the /etc folder. This file is almost fully configured beforehand and we have to make only a few minor modifications. Scroll down till you come upon something that looks like a subroutine named start(). It should look like this:

    start() {
    # Start daemons.
    echo -n $"Starting $prog: "

    Below the second line with the “echo” add the following two lines…

    start() {
    # Start daemons.
    echo -n $"Starting $prog: "
    /sbin/route add -host dev eth0 2> /dev/null
    daemon /usr/sbin/dhcpd eth0
    #daemon /usr/sbin/dhcpd ${DHCPDARGS}

    The /sbin/route add -host dev eth0 2> /dev/null sets up the DHCP Broadcast address to the global broadcast address of and binds it to your primary NIC [b]eth0[/b]. Your system now knows that DHCP will broadcast its presence using this IP through your primary NIC.

    The second line daemon /usr/sbin/dhcpd eth0 is the actual command that starts your DHCP Server and tells it to listen on eth0 – which again, is your primary NIC. When you edit this file, you’ll probably see the third commented out line already present. You can either comment it out and insert the second line manually – or modify the same line and remove the ${DHCPDARGS} variable and put in eth0 there instead.

    Next scroll a little further down till you get to another similar sub routine titled stop(). Once again add the following line as shown…

    stop() {
    # Stop daemons.
    echo -n $"Shutting down $prog: "
    /sbin/route del -host dev eth0 2> /dev/null

    You have to add only the /sbin/route del -host dev eth0 2> /dev/null line here which tells you system to stop broadcasting DHCP upon shutdown of the service and unhooks it from the global broadcast address.

    That’s it. Save the file and quit.

    We are now ready to start the DHCP server and put it to test. But before you do that there’s one last step that you got to perform. The DHCP Server stores all its lease information in a file called /var/lib/dhcp/dhcpd.leases by default. This file wouldn’t exist when you start the server – and on some systems, depending on the version of DHCP you are using it might spit out some error and cause DHCP to halt. Creating a blank file with that name solves the problem. We’ll just go ahead and do it anyway whether the file exists or not. So enter the following command…

    shell> touch /var/lib/dhcp/dhcpd.leases

    …and we are done.

    Step 3 – Starting the DHCP Server

    The DHCP Server can be started up in several ways. Do any of the following:
    shell> /etc/rc.d/init.d/dhcpd start


    shell> service dhcpd start

    Either way, you should get a message saying…

    Starting dhcpd: [ OK ]

    …which means all has gone well and your server is working fine.

    Step 4 – Starting your Windows System to check if DHCP is working properly

    Boot up your windows system and go to the Network and Dial-up Connections Panel. Right-click Local Area Connection and click on Properties. Then double-click on Internet Protocol (TCP/IP) and in the panel that comes up, make sure that the radio buttons next to Obtain an IP address automatically and Obtain DNS Server address automatically are both checked. If they are NOT, select them and click OK. Next Restart your system.

    Upon next boot – open a command line console type ipconfig /all. This should print out detailed information about your Network Card (NIC) and your present IP address. In my case, I booted up my development workstation – which if you recall from dhcpd.conf was set to have an IP address of based on my hardware MAC address. That’s what I found my workstation to have. And if you didn’t allot fixed IP to any system, you’d find you Windows machine to have taken up the first free IP in your IP Pool, once again, the range of which was specified in the dhcpd.conf.

    One last cross-check that you can do – is to get back to your Linux Server and open the /var/lib/dhcp/dhcpd.leases file and view its content. It was blank when you created it – but now it should contain an entry corresponding to your Windows system(s) and should look like this…

    lease {
    starts 2 2005/02/01 20:03:10;
    ends 3 2005/02/02 08:03:10;
    hardware ethernet 00:11:2F:47:54:F2;
    uid 01:00:00:e8:4c:5d:31;
    client-hostname "WorkStation";

    Thats about it. Good luck and have fun. If you’ve any questions about any of the steps shown here, feel free to leave a comment 🙂


    CodeLibrarian is my brainchild born out of necessity. It’s a handy storage/archiving tool for code snippets. It stores the thousands of code snippets you may accumulate from all over the net over years and helps you keep them all neatly categorized in a fully search-able local lightweight SQLite database.CodeLibrarian, which is entirely written in C# is based on Microsoft’s .NET 2.0 framework and released as open-source under GNU GPL (General Public License), which in other words means that the software is freely download-able along with it’s source code for further modification and development.

    Here’s a short list of planned and/or implemented features:

    1. Easy export (and mailing) of a single/multiple/all snippet(s) from a single category or across multiple categories. As good as ‘one-click’ sharing of your favourite snippets with your friends.
    2. Ability to upload and synchronise your snippets with a remote server – with a web-interface for browsing your snippets from any corner of the world, as long as you’ve a net connection.

    You can download the source files for the pre-alpha version 0.1 below. A copy of the same can be checked out of the OpenSVN subversion repository at:

    I highly recommend the usage of TortoiseSVN for checking in & out of the repository. TortoiseSVN is an extremely easy to use Revision Control / Version Control / Source Control software for Windows. It’s not integrated with any specific IDE (Integrated Delevopment Environment) and hence you’re free to use it with any development tools you like.

    You’ll need the NET 2.0 SDK to compile and run the code. Also suggested for downloading: SharpDevelop, which is a terrific open-source IDE for C#.


    Source Code – Pre-Alpha v0.1

    /* Hello World */

    Yawn !! Time to fire up the furnace and get the forge rolling…

    How To: Setup and emulate a Windows NT 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 shoudld return youa 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

    Uncomment 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 uncommented. 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 uncomment 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 uncomment 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
    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 databse…

    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.


    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.


    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 🙂