Double Agents

Whether you're thinking about adding Apache or SAMBA to your Windows network or you're already running them, the trick is making the integration seamless. Here's how to do it.

Double Agents

Linux and Windows are often seen as competitors engaged in a knock down, drag out battle for corporate and personal dollars. Much of the buzz is about whether Linux has enough applications or a friendly enough desktop to replace Windows. Tastes great! Less filling! Well, regardless of political or cultural issues, there comes a time when reality intrudes on personal prejudices and wishful thinking. Let’s face it — Windows currently rules the desktops and MIS departments of the corporate world. The other side of this coin is that Windows users and administrators have to admit that Linux is better at many server-type tasks.

For example, it’s no accident that Apache is the most popular Web server on the planet and that its home happens to be Linux. In fact, Apache has become so effective as a Web server that it has broken through many corporate religious barriers. Lots of system administrators have brought Linux into their network by adding a Linux system that is running an Apache Web server to their existing Windows environment.

Of course, Linux is good for a lot more than just serving up Web pages — a Linux box running SAMBA makes a better SMB-based file and print server for Windows clients than native Windows servers do. We’ve all heard stories of system administrators who snuck a Linux server running SAMBA into a Windows network, and the only thing users noticed was that the file server seemed to be faster and never crashed any more.

However, for Windows-based shops that haven’t yet brought Apache or SAMBA into their network, and even for those that have, the chief concern is usually making the integration as seamless as possible. But one thing you can say about Linux is that it makes a great chameleon. Linux, Apache and SAMBA can add a lot of functionality to a Windows network, without requiring the system administrator to modify any of the services currently provided by Windows servers.

There are a lot of ways to integrate Linux into an existing Windows environment. However, for the purposes of this article, we are going to assume that you wish to add a Linux box to a Windows-based network, while changing as little of the existing setup as possible. Once you’ve got everything up and running smoothly, there will be lots more power on tap, and many services that you can migrate to Linux if you so desire. We’ve included plenty of Weblinks on page 66 for those who want to take things further than space allows us to in this article.

Even if you already have SAMBA or Apache up and running on your network, hopefully you’ll find a few tricks in here to make the integration smoother. And if you have a Windows network but haven’t configured your Linux box yet, you may want to surf on over to http://www.samba.org and http://httpd.apache.org/ and download and install the latest versions of those applications.

Camouflaging Linux

While SAMBA makes a Linux file server look like a Windows file server to Windows clients, it’s not quite as transparent to system administrators. There are a number of issues you’ll need to deal with as soon as you add a SAMBA server to your network, the first of which is access control and user passwords.

Since there are differences in the way Linux and Windows handle user authentication, SAMBA provides you with a number of techniques for dealing with this issue. The SAMBA configuration file, /etc/smb.conf, contains a global option called security that determines which method SAMBA will actually use. However, assuming your Windows network already has an SMB password server or Windows Primary Domain Controller (PDC), the simplest way to do things is probably to have SAMBA delegate user authentication tasks to the existing password server or PDC. There are two parameters you can use with the security option that allow SAMBA to use an existing SMB password server or PDC; server and domain.

With either of these options, when a Windows user attempts to connect to a SAMBA file share, SAMBA will for-ward the user’s name and password to the network’s password server for validation. Although both of these options perform similar functions, if you have a network with a Windows NT/2000 server acting as a PDC, domain is the preferred method. It allows the SAMBA server to function as a valid member of the Windows domain, offers some performance improvements, and in general is less of a hack than the server method.

In order to make this work properly you need to create a “machine account” on the existing PDC, adding the SAMBA server to the domain. On the Windows side, you can do this by using the Windows NT Server Manager for Domains tool on the PDC. The Server Manager for Domains requires you to give it a computer type, so use the Windows NT Workstation or Server option. (Don’t make the SAMBA server a Primary or Backup domain server.) You’ll also have to supply the SAMBA server’s NetBIOS name.

On the Linux side, you need to create a machine password for the SAMBA server. You can do this with the smbpasswd utility that comes with SAMBA, by using the -j and -r options. In our example, the domain will be called WVH-NT-DOMAIN, and our PDC will be WVH-NT. So to create the machine password, type:

smbpasswd -j WVH-NT-DOMAIN -r WVH-NT

If everything works properly, you should get the message:

smbpasswd: Joined domain WVH-NT-DOMAIN.

Next, a few modifications must be made to /etc/smb. conf in order to get everything up and running. As mentioned previously, the security option must be set to domain. You also need to tell SAMBA what domain we belong to (in this case, WVH-NT-DOMAIN, which is set with the workgroup option), what the name of the password server is (in this example it’s WVH-NT), and to use password encryption, since NT PDCs expect to be presented with encrypted passwords.

Figure One contains a snippet from /etc/smb.conf that configures your SAMBA server to use a PDC named WVH-NT for authenticating users.

Figure One: Global Settings


# workgroup = NT-Domain-Name or Workgroup-Name, eg: REDHAT4
workgroup = WVH-NT-DOMAIN


# Security mode. Most people will want user level security. See
# security_level.txt for details.
security = user
# Use password server option only with security = server
password server = WVH-NT

# 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

Finally, there is a bit of administration related to user accounts and passwords that you’ll need to perform on the Linux side. Because of the way the Linux filesystem works, in order to read or write files on the Linux box, users will need to have a valid user name and user ID in the master Linux password file (/etc/passwd). So even though SAMBA will be using the Windows PDC to verify names and passwords, you are going to need to add user name and ID entries for all of the Windows users requiring access to the SAMBA server to the Linux /etc/passwd file.

Note that a Windows user doesn’t need to have a separate password in his or her /etc/passwd entry. In the interest of maintaining just one authentication server on the network (in our example, the existing Windows PDC), you can just add the user to /etc/passwd and put an asterisk (*) in the user’s password field. That will disable the password, at least on the Linux side. The user’s name and password will still be verified by the Windows PDC at log in.

It’s worth pointing out that this setup makes life really easy when Windows users want to change their passwords. All they have to do is change things on the Windows PDC, just as they would have before, and everything will still work flawlessly.

Non-Stick Passwords with PAMs

Aside from simplifying things with SAMBA, maintaining the existing Windows PDC as a single password and authentication server on the network is a great way to seamlessly integrate a number of other Linux services into a Windows environment. But how can you do that without maintaining a password file on the Linux server as well? What about all the services that require you to log in to the Linux box directly? This is where PAMs come in handy. PAMs (Pluggable Authentication Modules) are interchangeable modules that allow you to implement flexible authentication schemes on any system that supports PAMs.

Let’s try that again in English. Historically, whenever someone wanted to log in to a Unix system, the login program would check the /etc/passwd database to verify that his or her name and password matched. Most other programs that required you to provide user names and passwords (such as ftp, rsh, etc.) were also written to use the /etc/passwd database. As new types of password databases were developed (such as NIS, LDAP, etc.), programs that were designed to use the /etc/passwd database needed to be re-written in order to explicitly support each new system.

PAMs were designed to alleviate this problem. Instead of being re-written to support every different type of password database, programs such as login or ftp can be written to only support PAMs. Then, different PAM modules can be written to support each different type of password database. So for example, a PAM aware login program would be able to verify a user’s name and password against whatever password database was in use on that system, be it /etc/passwd, NIS, or any other password system for which there is a PAM module.

This is a massive over-simplification of what PAMs are and how they work. A great resource for finding out which applications can use PAMs and where to get those PAMs is the home page for the Linux-PAM (Pluggable Authentication Modules for Linux) project at the following URL: http://www.us.kernel.org/pub/linux/libs/pam. For an even more detailed technical summary of how PAMs work, you can check out the June 2000 Guru Guidance located on-line at http://www.linux-mag.com/2000-06/guru_01.html.

Meanwhile, how can PAMs help you seamlessly integrate Linux and Windows? Well, as a user or sysadmin, you may occasionally need to telnet to your Linux systems to check the status of an application (such as Apache), examine log files (Apache again), and so on. A PAM named pam_smb allows you to log in to the Linux box, but continue using the Windows PDC as a password server. The PAM aware login program on Linux will use the pam_smb module to check with the Windows PDC for password validation, rather than using the /etc/passwd database on Linux.

The big advantage here is that you only have to remember your Windows password, which is used “everywhere.” Without this feature, Linux and Windows NT/2000 users and administrators would need to have separate accounts on their Linux and Windows systems, with separate pass-words, and so on. The Using the pam_smb PAM Module sidebar shows you where to get pam_smb and how to compile, configure, and install the module.

Using the pam_smb PAM Module

Go grab a copy of pam_smb from ftp://ftp.samba.org/pub/samba/pam_smb/pam_smb-1.1.6.tar.gz. The module comes as source code, so you are going to need to compile it (the README included with the tarball contains clear instructions). Alternatively, for those who are compile-impaired, you can also grab a pre-compiled RPM of pam_smb from ftp://rpmfind.net/linux/contrib/libc6/i386/pam_smb-1.1.6-1.i386.rpm.

Once you’ve un-tarred and un-gzipped the file, compiling the module should be as simple as cd-ing into the new pam_smb directory that was created, and then executing:


followed by:


This should produce a share library named pam_smb_ auth.so, which you should copy into the /lib/security directory by typing:

cp pam_smb_auth.so /lib/security

The next thing you’ll need to do is create the /etc/pam_ smb.conf file using your favorite Linux text editor, and fill it with the following entries:


The NAME_OF_DOMAIN entry is the simple name of your Windows NT/2000 domain. In our examples, we’ve been using a domain named WVH-NT-DOMAIN. So //WVH-NT-DOMAIN would be the way we refer to this domain from Windows NT/2000. The PRIMARY_DOMAIN_SERVER_NAME and SECONDARY_DOMAIN_SERVER_NAME entries are the names of your primary and secondary domain controllers, respectively. If you don’t have an explicit secondary domain controller, you can use the name of any Windows NT/2000 system on your network.

You will also need to modify the files in /etc/pam.d/ belonging to any of the services that wish to make use of pam_smb. For this example, we’ll modify the /etc/pam.d/ login file. Modify the second non-commented line of the file (the second line that does not being with a hash mark — “#”) so that it looks something like Figure One.

Figure One: Modified etc/pam.d/login File

auth required /lib/security/pam_securetty.so
auth required /lib/security/pam_smb_auth.so
# auth required /lib/security/pam_pwdb.so shadow nullok
auth required /lib/security/pam_nologin.so
account required /lib/security/pam_pwdb.so
password required /lib/security/pam_cracklib.so
password required /lib/security/pam_pwdb.so nullok use_authtok md5 shadow
session required /lib/security/pam_pwdb.so
session optional /lib/security/pam_console.so

Note that the entry for the standard Linux authentication module (the line that begins with auth and ends with pam_ pwdb.so shadow nullok) is commented out.

If you want to make sure that everything is functioning correctly, you can enable verbose debugging output, which will be output to the file /var/log/secure. To enable this, just add the word debug to the end of the pam_smb_auth.so entry.

If you were to open a telnet connection from a system named redhat7 (redhat7.vonhagen.org) with an IP address of in a Windows NT/2000 domain called WVH-NT-DOMAIN, using a primary domain controller named WVH-NT and a secondary domain controller named WVH-NT2, and you had debugging enabled, your output will look like Figure Two.

Figure Two: Output to /var/log/secure

Dec 6 10:35:00 redhat7 in.telnetd[14311]: connect from
Dec 6 10:35:16 redhat7 login: pam_smb: Local UNIX username/password check incorrect.
Dec 6 10:35:16 redhat7 login: pam_smb: Configuration Data, Primary WVH-NT,
Backup WVH-NT2, Domain WVH-NT-DOMAIN.
Dec 6 10:35:17 redhat7 login: pam_smb: Correct NT username/password pair
Dec 6 10:35:17 redhat7 login: LOGIN ON 8 BY wvh FROM redhat7.vonhagen.org

Finally, edit the /etc/passwd file by placing an asterisk (*) at the beginning of the second field (the field the password is usually stored in) for each user. The asterisk is the only character that can’t be generated by the Linux password algorithm, and is therefore used only to comment out user passwords.

That should do it. From now on, PAM aware Linux services should be able to use your existing Windows PDC to perform user authentication.

Integrating Apache and Windows with Pams

As we mentioned earlier, Apache is the most popular Web server on the planet, and is one of the most compelling reasons to add a Linux server to a Windows network. But as is the case with every other service offered on the Linux box, there will be a few Linux/Windows integration issues to attend to, and the first of those is likely to be passwords (again).

Apache allows you to restrict access to individual directories and directory trees by requiring users to authenticate themselves before they can use the files in those directories. To do this, you simply need to create a .htaccess file in the directory you want to protect, containing the names of the users that have access to that directory. Apache will then authenticate those users by looking in it’s own password file, .htpasswd, which contains the user’s name and encrypted password. (For more information on how Apache user authentication works, check out http://hoohoo.ncsa.uiuc.edu/docs/tutorials/user.html.)

The downside to all of this is that creating and maintaining a separate .htpasswd file is a tedious and time-consuming task. Fortunately, just as SAMBA allows you to use a Windows-based password server for authentication, Apache also provides a way to use an existing Windows password server or PDC to replace the .htpasswd files. In order to do this, Apache makes use of its loadable modules facility — which are chunks of code (shared libraries) that can be loaded into the base Apache server in order to add features and functionality.

In this case, Apache calls on a module named mod_auth_ pam, which allows Apache to make use of a wide variety of authentication methods (any method supported by PAM), rather than having to create and maintain its own .htpasswd file. Since we’re interested in using a Windows SMB-based password server or PDC, Apache would rely on our old friend pam_smb, which as we just saw in the previous section will then allow Apache to call upon the existing Windows password server when validating user names and passwords.

If you are interested in using mod_ auth_pam, the Using Apache mod_ auth_pam Module sidebar contains an example of how to set things up.

Using the Apache mod_auth_pam Module

You will probably have to compile the mod_auth_pam module from source code, which you can find at http://pam.sourceforge.net/mod_auth_pam/. Download the file mod_auth_pam.tar.gz. After you’ve un-tarred and un-gzipped the file, cd into 55h_pam-1.0a directory and compile the module:

/usr/local/bin/apxs -c mod_auth_pam.c

Now install the compiled Apache module in the /usr/lib/apache directory:

/usr/local/bin/apxs -i -a mod_auth_pam.so

This command will also modify the Apache Configuration file (/etc/httpd/conf/httpd.conf), adding the mandatory LoadModule and AddModule commands.

Assuming you want Apache to use the pam_smb module, you will next need to make sure the file /etc/pam.d/httpd looks like the following:

# The PAM configuration file for the ‘httpd’ service
auth required pam_smb_auth.so debug
# auth required pam_pwdb.so debug shadow md5
account required pam_pwdb.so debug md5

Finally, in any directory that you want to protect, you will need to create a .htaccess file with contents that look something like the following:

AuthPAM_Enabled on
AuthType Basic
AuthName “Authentication Testing with mod_auth_pam”
require user wvh
# require valid-user

In this case, the PAM will only allow the user wvh to access the directory in which this file is located. You can also simply enable any valid user to access this directory by uncommenting the last line in this example (removing the hash mark # before the line # require valid-user) and commenting out the line limiting access to the user wvh (adding a hash mark [#] to the line require use wvh).

You can also specify these authentication options for any directory in the Apache document tree by editing the /etc/httpd/conf/httpd.conf file. Enclose the above commands within a set of <directory> and </directory> tags, where the directory keyword in the opening tag is followed by the name of the directory you want to protect, as in the following example:

<directory /home/wvh>

(remainder of Apache protection/authentication commands as illustrated above)


Now you will need to restart Apache.Any user attempting to access a directory protected by a .htaccess file will be authenticated using the pam_ smb module you installed previously.

Working Together

Although we’ve spent most of this article talking about integrating Linux services with Windows, if you’ve got both SAMBA and Apache running on a Linux server, there are some useful ways that you can integrate them with each other, as well as with Windows. For example, Web page designers and content producers working on Windows machines can quickly publish their work directly to the Web server. You can easily configure SAMBA to give those Windows users access to the top level of Apache’s document repository (DocRoot), as illustrated in the Providing Access to Apache’s Web Documents Using Samba sidebar.

Providing Access to Apache’s Web Documents Using SAMBA

The per-directory configuration commands in SAMBA’s configuration file (/etc/smb.conf) make it easy to provide access to specific directories. If you want to allow Web designers who work on Windows systems to read and write documents from the root of the Apache document tree (DocRoot), you can add a section to /etc/smb.conf that looks like:

comment = The Apache Server’s DocRoot
path = /home/httpd/html
valid users = @web-writers
write list = @web-writers
force group = @web-writers
public = no
writable = yes
write ok = yes
printable = yes
force create mode = 0770
force directory mode = 0770
share modes = yes
locking = yes
strict locking = yes

This enables members of the Linux group web-writers to write to the /home/httpd/html directory. You must therefore add this group to the /etc/group either by editing the file directly, or by using a configuration tool like /bin/linuxconf. (For more information on creating groups, see the July 2000 Guru Guidance at http://www.linux-mag.com/2000-07/guru_01.html.) You must be logged in as or su’d to root to make these and subsequent modification. For example, the ownership of the directory functioning as DocRoot must be recursively set to be owned by the web-writers group, using commands like the following:

cd /home/httpd/html
chgrp -R web-writers

The other commands in the above configuration file entry enable sharing and locking of the files in this directory when one member of the group is already editing the file. They also set the write modes for this directory so that the directory remains owned by the entire web-writers group, no matter which individual user happens to save a file there.

Of course, once you’ve got a Linux Web and file server running on a previously all-Windows network, there’s a lot more functionality you can move over Linux without anyone noticing. For example, while in this article we’ve only talked about having SAMBA join a Windows domain and use an existing Windows PDC for authentication, versions of SAMBA that are higher than 2.0 allow SAMBA to function as a PDC for a Windows network. For more information on this and other tricks, check out the Web links below.

The point of all of this is that different systems have different strengths. Linux excels at many functions, and provides many tools that allow it to seamlessly integrate with Windows and overcome any political or religious barriers to it’s acceptance. Once you’ve got a Linux box on the network, you’ll probably start to receive lots of comments regarding the fact that the file server seems faster and never crashes any more. After that it inevitably gets easier and easier to convince systems managers and users to adopt Linux for more and more tasks.

Web Links


Source Code for Latest Version of SAMBA:

Articles on SAMBA in Linux Magazine

General PAM Information

Pluggable Authentication Modules Specification:

The Linux-PAM Page:

Red Hat 7.0 Reference Guide (User Authentication with PAM):

PAM for Windows/Linux Authentication:

Apache Modules for Windows NT/2000 Authentication



Bill von Hagen is president of Move2Linux.com. He can be reached at wvh@movetolinux.com.

Comments are closed.