Portable encryption systems – keeping your USB / flash drive data safe

Flash drive securityUSB-based flash drives are a part and parcel of everyone’s life these days. Not only they are dirt cheap, they provide  substantial storage, making them extremely handy tools for carrying around large amounts of data, including personal  and official  information of sensitive nature.

What’s worrisome is that the data on an average flash drive is grossly unsecure and can prove to be a tremendous source of data leakage both from the personal front and an organization network if the drive falls into wrong hands.

Because of their tiny sizes these devices are prone to being lost or misplaced or worse yet – easy targets for thieves.  Both TechRepulic and PCWorld provide lengthy discussions on the kind of damage such an action may cause to an organization.

Good news is that there are numerous commercial and free / opensource solutions (both software and hardware based) to securing your flash drive data. This article attempts to provide brief overviews of the most well-known ones with an emphasis on those which are free and readily available to everyone. In each case, portability is the key criteria, as that’s what USB drives are for.

Hardware

Hardware ChipTo begin with,  hardware-based data protection systems (for flash drives) aren’t all that prevalent yet with not many viable (read inexpensive) options for the mass consumer market. For most part, these devices are targeted towards the SMB (Small and Medium Business) and Enterprise market.

Although dubbed “hardware-based encryption” these flash drives employ a dual layer of software and hardware to secure your files.

These drives come with two partitions – a normal partition for publicly viewable data and an encrypted one for all your sensitive information, with the ability to set the size of this partition (as a percentage of the total flash drive capacity) at will. All data flowing in and out of the latter is encrypted / decrypted on-the-fly using AES-256 by an encoder chip (hardware) built into the flash drive. To access this special partition one needs to provide a password. This authentication mechanism is where the software part comes into play. The whole process is transparent to the end user and doesn’t cause any noticeable loss in data transmission speeds.

Note that the authentication software (in most cases) is Windows compatible only! Hence, on other platforms (Mac, Linux etc.) your encrypted partition cannot be accessed.

Did you know…

even if you ever lose your USB stick it will take someone with a very powerful computer at least 100 years to decrypt the data using brute force?

The drives also sport automated self-destruct systems that securely wipes out  data on the encrypted  partition after a certain number of attempted break-ins. This effectively counteracts any brute-force cracking attempts, although you can give up all hopes of recovering your data. But then again – “Better safe than sorry”.

Some of the vendors offering hardware encryption based USB Flash drives are:

Among these, the drives from Kingston, SanDisk and Verbatim have been awarded the FIPS 140-2 Level 2 certificate issued by the US National Institute of Standards and Technology (NIST), which validates the USB drives for use with sensitive government data. Recently, a potential security hole was discovered in the drives from all three vendors – but that was primarily due to poor coding of the software counterpart. The actual encryption system still remains stands strong. Besides, patches have already been rolled out by all three vendors rectifying this problem.

If you’re the  paranoid kind and / or are strong on security these are the drives for you. But be prepared to shell out a thick wad in the order of $100 – $500 depending on the make and capacity of the drive.

Software

The pure software encryption systems have a couple of distinct advantages over their hardware counterparts:

  • They can transform any given USB disk into a secure storage location
  • Most such systems allow you to set a preferred cipher (encryption routine). Besides the default AES Blowfish, Twofish, DES, Tripple-DES etc. are also offered.
  • And finally, they come much, much cheaper than the hardware variants. The price range starts from “free” and goes up to $50.

As far as modus operandi goes, both hardware-based and software-based systems are virtually alike – except that, for the latter, the functionality of the hardware encoding chip is taken up by an additional layer of software. The same software that handles authentication is also responsible for encoding / decoding of the encrypted partition and a portable copy of the same is usually placed on the USB drive in order to avoid re-installation issues when working on a different PC.

USB EncryptionAnother added advantage is that one can create multiple encrypted partitions on the same USB drive. These so-called encrypted partitions aren’t “real” partitions, per se. Rather they are encrypted files that serve as containers for your data and are mounted as separate partitions by the software on-demand. Hence, it is possible to create as many of these partitions as you wish – each dedicated to a different kind of content (or as you see fit) – the only limitations being the total capacity of the flash drive and the availability of drive letters (on Windows). Like the hardware version, these data can be read from / written to these partitions on-the-fly.

Well-known commercial tools for this task are:

  • Encrypt-Stick – Employs Polymorphic Encryption. $40/license.
  • WinEncrypt CryptArchiver – Can choose between AES and Blowfish. $18 to $50/license depending on edition. A free edition – which limits volumes to 25MB – is also available.
  • I-Secure Key – Pricing and features are not clear from their website, but a fully functional trial version is available for download. This isn’t an encryption software per se and utilizes TrueCrypt behind the scenes to create and maintain the encrypted volumes.
  • Master Voyager – Apart from creating encrypted volumes on USB drives, this tool is also capable of creating encrypted CDs and DVDs. $70/license.
  • Discryptor – A pretty robust application with a strong set of features (and a lot of excess baggage like Parental Control, Employee Monitoring etc.) Licenses can range from $85-$2500 depending on edition. A free but limited Basic edition is also available.

And finally, onto the free and opensource ones.

  • TrueCrypt – Perhaps the best that there can be in this category in terms of features (and pricing). This utility offers support for unlimited encrypted volumes (as long as there are drive letters to mount on) and can encrypt entire existing partitions. The recent versions support something called Hidden Volumes where your actual data resides with a Fake counterpart stuffed with junk data to provide you with “plausible deniability” – in case you are forced to give-up your volume password to an adversary. Supported algorithms: AES, Twofish and Serpent. Probably, the only one to work on both Windows & Linux. Here is an excellent tutorial on using TrueCrypt. Advanced users will benefit from this tool.
  • Rohos Mini Drive – Easy to use portable application targeted at newbies. It creates hidden, encrypted volumes and can run on a guest computer without Administrative rights using File Virtualization technology. Caps the storage volumes at 2GB. Has virtual keyboard for protection from keyloggers. If it’s your first venture into the world of encryption, I recommend this utility.
  • SafeHouse Explorer – Another great utility with a similar set of features as Rohos. This tool presents you with an ever-familiar Windows Explorer like interface which you can use to drag & drop files and folder into the “private storage vaults”. Sports a graphical password strength meter to help you choose a good master password. A cool feature is the creation of self-executing click-and-run encrypted volumes. Recommended for basic users.
  • USB Safeguard – A free, lightweight and portable utility that works in drag & drop mode. Also features a safe-surfing mode that one can use while browsing from an internet cafe. Also a good recommendation for basic users.
  • FreeOTFE – A no frills yet powerful and portable opensource utility that supports numerous hash (including SHA-512, RIPEMD-320, Tiger) and encryption algorithms (including AES, Twofish and Serpent) in several modes (CBC, LRW and XTS) – providing a much greater level of flexibility than a number of other (including commercial!) OTFE (on-the-fly-encryption) systems. Has support for Linux volumes (Cryptoloop “losetup”, dm-crypt and LUKS). Works on PCs without no Administrator rights and has a PDA version too. Intended audience: both basic and advanced users.

Before I end, I’d like to mention this one other way which helps you encrypt data in a similar fashion without the aid of any third party software. This system utilizes the native data encryption mechanism of NTFS and works only on Windows-based computers. Online Tech Tips has a step-by-step tutorial on this. Be advised that this method limits your read / write activities to the encrypted partition on the originating computer only unless you are ready to export and carry around your EFS certificates.

Safe computing 🙂

Codec woes? Can’t find a codec required to play a video file? Try VLC Player

Video Playback IssuesWhile for many of us, Windows Media Player may serve as a good enough tool for video playback, but it’s certainly got it’s problems. Lets face it – for most part it’s perfectly capable of playing DVDs, but performs miserably when it comes to playing wmv or mpeg files which are a couple of generations old. Our hard-drives are littered with such video clips that come as attachments along with mails and it can get really frustrating when you’re faced with a message saying “A codec is required to play this file. To determine if this codec is available to download from the Web, click Web Help.” More often that not, the so-called “Web Help”, which takes you to the Microsoft Codec download page doesn’t prove to be of much Help 😡 !!

For a long time, I have been searching utmost lengths for a freeware third-party application that would dutifully play all these files without a single hiccup. Media Player Classic, which resembles the old Windows Media Player 6.4, proved to be one of the strongest contenders in this category. Unfortunately, some of the older files still refused to play. This led me off on another relentless search till I came upon this “too-good-to-be-true” media player named VLC. This terrific utility by VideoLAN happens to be one of those miracle applications which is capable of playing back virtually every type of audio and video files without requiring you to download any of those godforsaken codecs. And that includes DVD & VCD movies too.

VLC Player for WindowsVLC is a free & open-source cross-platform media player – which means it can be run on literally any OS ranging from Windows, Mac OS-X, BeOS, FreeBSD and numerous flavours of Linux. It is highly portable and can play almost any formats like MPEG-1, MPEG-2, MPEG-4, DivX, mp3, ogg etc. But it doesn’t end there. VLC can double up as a multimedia streaming server in unicast or multicast in IPv4 or IPv6 on a high-bandwidth network. A full list of features is available here.

If you ask for an honest, unbiased opinion, I can’t really claim that this is THE ultimate media player ever – but yeah, I certainly haven’t come across a codec that this cool-tool cannot handle on its own. You can always give it a shot and provide some feedback on your own experience…

Free eBook: Linux Kernel in a Nutshell

Popcorn KernelsLinux Kernel in a Nutshell is yet another release in the Nutshell series by O’Rielly that teaches you how to build, configure, and install a custom Linux kernel on your machine.

The author, Greg Kroah-Hartman routinely does the same for a living. Good news is that for the average user, no programming knowledge or experience is required to understand and implement the concepts discussed this book. However, readers are expected to be familiar with the basic operating principles and the command-line interface of Linux.

While the printed version of this book is available from Linux Kernel in a NutShellO’Rielly store, it’s offered as a free download in both Adobe PDF and Linux DocBook format from the author’s site as individual chapters as well as the whole book. It is available under Creative Commons Attribution-ShareAlike 2.5 license which means that you are free to download and redistribute it. The idea behind offering it for free is to bring out hidden talents and get more people involved in the Linux kernel development process. According to the author…

The act of building a customized kernel for your machine is one of the basic tasks needed to become a Linux kernel developer. The more people that try this out, and realize that there is not any real magic behind the whole Linux kernel process, the more people will be willing to jump in and help out in making the kernel the best that it can be.

As of now the book deals with the kernel release 2.6.18. With the introduction of newer kernel versions some of the configuration items may change / move around and / or new configuration options may be added. All said and done, the main concepts dealt in the book will still remain valid for any future kernel versions.

No single Linux distribution can provide you with a kernel that meets all users’ needs. Computers come in wide varieties and with special hardware that call for reconfiguration and rebuilding of the kernel. The book will benefit literally anyone – be it someone trying to get sound, wireless support, and power management working on a laptop or incorporating enterprise features such as logical volume management on a large server.

O’Rielly says …

Linux Kernel in a Nutshell covers the entire range of kernel tasks, starting with downloading the source and making sure that the kernel is in sync with the versions of the tools you need. In addition to configuration and installation steps, the book offers reference material and discussions of related topics such as control of kernel options at runtime.

Download the free eBook from the author’s site…

How To: Setup a Local Domain Name Services (DNS) Server for your Intranet

This was another of my journeys into the deep dark dungeons of Linux. This time I managed to set-up a DNS server locally and got it resolving addresses over my intranet.

Experimentation Platform:

Intel P4 3.0Ghz (Intel MotherBoard)
1 GB RAM
2 x 80 GB HDD on RAID 1 (Disk Mirroring) – alloted entirely to Linux

Operating System:

Linux – Redhat Enterprise AS Server v3

Note:

I was trying to setup the system so that later on when my server goes online, I don’t
have to modify much to make my nameservers work with the internet – so I used my registered domain “microsys-asia.info” and an internal IP: “10.19.168.5” – as the server IP. In future when my server goes online, all I’ve to do is modify this IP to reflect the actual ISP alloted IP and all will be good. So throughout the tutorial you’ll find references to this domain and the IP. For your own case, just change to domain to whatever you feel like and choose a suitable IP to go with.

Setting up the DNS can get quite tricky – so you need to follow the tutorial closely and pay attention to all the points discussed here.

Also make sure the following services are up & running – because they’ll be the ones affected most due to the DNS setup.

  1. httpd
  2. ftpd
  3. MTU (Mail Transport Agent) like Postfix, Sendmail etc.

You can see a list of running services using…

shell> service –status-all | less

Right, lets get to business now. Once your system boots, either login as “root” or use any other login and use “sudo” to get root access.

(more…)

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.

Assumptions:

  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:10.19.168.5  Bcast:10.19.168.255  Mask:255.255.255.0
inet6 addr: fe80::20d:88ff:fe39:d269/64 Scope:Link
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
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 10.19.168.5 and that’s what you see on first half of the second line, along with the Broadcast Address (10.19.168.255) and Subnet Mask (255.255.255.0).

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 255.255.255.0;
    option broadcast-address 10.19.168.255;
    option routers 10.19.168.5;
    ## The IP address of the name server
    ##
    option domain-name-servers 10.19.168.5;
    option domain-name "mydomain.com";

    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 (10.19.168.255) or use the universal broadcast IP (255.255.255.255). 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 10.19.168.5 and 10.19.168.6 – you should specify them in order of search, i.e. the statement will take this form:

    option domain-name-servers 10.19.168.5 10.19.168.6;

    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 10.19.168.0 netmask 255.255.255.0 {
    range 10.19.168.31 10.19.168.250;
    }

    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 255.255.255.0 – 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 10.19.168.31 and end range to 10.19.168.250 – 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
    00:11:2F:47:54:F2;
    fixed-address 10.19.168.50;
    }
    # Tony's Computer
    host tony {
    hardware ethernet
    00:0A:5E:24:24:0E;
    fixed-address 10.19.168.60;
    }
    # Networked Laser Printer
    host laser-printer {
    hardware ethernet 08:00:2b:4c:59:23;
    fixed-address 10.19.168.100;
    }

    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 10.19.168.50; 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 10.19.168.0 netmask 255.255.255.0 {} declaration right after the line where you specify the IP Pool range (range 10.19.168.31 10.19.168.250;). 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 255.255.255.255 dev eth0 2> /dev/null
    daemon /usr/sbin/dhcpd eth0
    #daemon /usr/sbin/dhcpd ${DHCPDARGS}
    ...
    ...
    }

    The /sbin/route add -host 255.255.255.255 dev eth0 2> /dev/null sets up the DHCP Broadcast address to the global broadcast address of 255.255.255.255 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 255.255.255.255 dev eth0 2> /dev/null
    ...
    ...
    }

    You have to add only the /sbin/route del -host 255.255.255.255 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

    OR

    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 10.19.168.50 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 10.19.168.50 {
    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 🙂

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

    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 🙂