Wedding Samba to an Active Directory Domain

Brett Lymn

Recently, Microsoft has changed the way it stores details for a user. Gone are the Primary and Backup domain controllers, where the Primary Domain Controller was the master of all and the Backup domain controllers provided a partial service in the event the Primary went down. In its place is a new, more distributed system called Active Directory where all the authentication servers are peers that replicate the active directory contents between them.

Active Directory actually holds a lot more information than just user details, but I won't worry about that for the purposes of this article. Not surprisingly, the change to Active Directory changes the behind the scenes work required to perform authentication to the Windows domain.

Fortunately, the Samba team has kept up with these changes and Samba 3 is able to participate in an Active Directory domain. The downside is that unlike the old days where you could build Samba, install it, then point it at the domain controllers and it would work, getting Samba 3 integrated with the Active Directory requires more groundwork because it relies on underlying services such as DNS, Kerberos, and LDAP for its operation.

In this article, I will describe what you need to install on a Solaris 8 (or later) machine, and how to configure it to get Samba running with Active Directory.

Before I start on the technicalities, consider the following scenario -- you are a Unix systems administrator for the Phantom Manufacturing company. Your engineering department has its own Active Directory domain called eng.phantomco.com.au, and the department wants to map some data directories on their Windows workstations from a Unix server called siren.phantomco.com.au, which you administer. The Engineering department has two Active Directory servers with IP addresses of 10.7.6.9 and 10.7.4.9. As the administrator of the machine for which they need to map drives, you are tasked to provide a method for doing this. Here is how you could do it using Samba 3.

Library Dependencies

Before you can start building Samba 3, you must set some groundwork by installing some required libraries, namely Kerberos and LDAP. It's true that Solaris already comes with both of these libraries, but there are some functions required by Samba that are not found in the standard Sun libraries. The solution I've found is to build some open source versions that provide the required functions.

I chose to use MIT Kerberos for the first library, simply because it does the job required. Download the source tar file and unpack it, then run the configure script. When I was configuring the build of Kerberos, I chose an install prefix of /opt/local/kerberos5 to keep the third-party install out of the system directories. It does not matter what install prefix is chosen here, but it will be required later when building Samba. Once configured, build and install Kerberos. After the install, check that SUNWkrbr is installed since it will be required later.

I chose OpenLDAP for the other library. Download and unpack the sources for OpenLDAP. When I configured OpenLDAP, I chose to install into /opt/local/openldap. I also used the configure options "--without-bdb --disable-bdb --enable-null" to avoid having to install a Berkeley Database library, which is required to run a local LDAP server. In this case, the OpenLDAP libraries are being used to query the Active Directory domain so there is no need for a backend database. Once configured, build and install OpenLDAP.

Samba build

Download the latest Samba 3 sources (which, at the time of writing, was 3.0.4). Unpack the source files. Before performing the configure, set the following environment variables and export them:

LDFLAGS="-L/opt/local/openldap/lib -Wl,-R/opt/local/openldap/lib"
CPPFLAGS=-I/opt/local/openldap/include

If you have installed OpenLDAP into a different location then adjust the paths accordingly. The second half of the LDFLAGS sets the runtime path for the dynamic linker. By doing this, you obviate the need for setting the LD_LIBRARY_PATH to find the OpenLDAP libraries at runtime. The above syntax assumes you are using gcc as your compiler. The syntax for SunPro CC will certainly be different.

Once the environment is set up, configure Samba with the following options:

--prefix=/opt/local --with-winbind --with-ads --with-ldap 
  --with-krb5=/opt/local/kerberos5

Again, if you have chosen to install things in different locations, then update the paths accordingly. This configuration will enable all the parts that are required for Samba 3 to talk to an Active Directory server. Once the configuration is done, build and install Samba.

DNS config

Once you have all the pieces installed, you must start preparing the machine to run Samba. A fundamental part of this preparation is getting DNS working correctly. Active Directory makes extensive use of DNS to provide information to the clients about the Active Directory domain, so it is very important that DNS be functioning correctly before attempting any other work with the Active Directory. Setting up a DNS server is beyond the scope of this article, however, I will present some small configuration details that can be used when setting up DNS on your Samba server.

Before setting up DNS, you must find out the name of the Active Directory domain, commonly referred to as the Active Directory Realm. This will normally look like a normal DNS domain like "engineering.sun.com" or "ad.microsoft.com" or "foo.com.au". Your Active Directory administrator will be able to give you the realm that is being used. The name of the realm will be used in quite a few places, so make a note of it for later. At Phantom Co., the realm for the Engineering Active Directory domain is "eng.phantomco.com.au".

Configuring DNS in its simplest form would involve simply dropping the realm name and the IP addresses of one or more Active Directory servers into /etc/resolv.conf on the machine you are setting up. Then, possibly, adjusting /etc/nsswitch.conf to add the DNS service to the hosts line so that DNS will be used to look up names. For a simple network or one where Windows machines handle all the DNS serving anyway, this would be the most sensible thing to do. In the case of Phantom Co., you would configure /etc/resolv.conf to point at the two Active Directory servers 10.7.6.9 and 10.7.4.9.

Unfortunately, this simple approach may not be applicable in many situations, and Phantom Co. is an example of this. At Phantom Co., they already had a DNS infrastructure set up on the Unix machines -- the Active Directory realm was added later and the Active Directory servers were configured to forward any queries for information that they did not know about to the Unix DNS servers for resolution.

Given this setup, it makes little sense to forward the Unix DNS queries to the Active Directory servers simply so they could pick out the Active Directory-related queries and forward the rest back to the Unix infrastructure. This would be especially bad for a machine being used as a Squid WWW proxy server that makes heavy use of DNS. To address this issue, you could set up a DNS server on the Samba server and make the Samba server a secondary name server for the Active Directory server.

In this manner, the Samba server will be able to resolve addresses in the Active Directory realm by looking up the information in its own DNS server. This configuration is a bit more effort to set up, but does mean that the DNS records will be served locally and any unknown domains can be forwarded to the Unix infrastructure for resolution.

In the case of Phantom Co., you cannot use this solution because the Engineering department Windows' administrator is a bit wary about making changes to the DNS setup on the Active Directory servers for fear of breaking the Active Directory domain. The next best thing you can do is to set up a caching name server on the Samba server, which is almost back to where you were with setting up /etc/resolv.conf because normally with a caching name server, all requests are forwarded to a defined set of DNS servers.

What makes the caching DNS solution better is that the Solaris named is able to selectively forward queries for a particular domain to a different set of DNS servers by using this directive in the /etc/named.conf:

zone "eng.phantomco.com.au" in {
        type forward;
        forward only;
        forwarders {
                10.7.6.9;
                10.7.4.9;
        };
};

By doing this, you can point the bulk of the queries directly to the Unix DNS infrastructure and just send the queries for the eng.phantomco.com.au domain to the Active Directory servers, which is just what you wanted.

Samba config

Now that the underlying infrastructure has been installed and tested, it is time to configure Samba. Going over all the Samba configuration options is out of the scope of this article, so I'll just cover the ones required to get Samba going with Active Directory.

There are only two configuration items that you need to modify to get Active Directory authentication working. First, you must set the security option to ADS like this:

security = ADS

Then you must set the realm of the Active Directory like this:

realm = eng.phantomco.com.au

This should be sufficient to get the Active Directory components working. (The rest of the Samba configuration is left as an exercise for the reader.)

Active Directory Bind

Once you have a Samba configuration file that you (and Samba) are happy with, the next step is to perform the binding of the Samba server machine to the Active Directory domain. This is an important step because it sets up the "machine account" for the Samba server in the Active Directory domain. The machine account is required to query the active directory server for user authentication details. Once set up, the machine account is automatically maintained, so the binding procedure only has to be followed the first time Samba is set up on the Unix server. To set up a machine account, you first must get a Kerberos ticket, cd to the directory where you installed Kerberos (/opt/local/kerberos5, in my case), and type:

bin/kinit bob@ENG.PHANTOMCO.COM.AU

Take care that you use the correct version of kinit; do not use the Sun version otherwise you will get a "kinit: No profile file open while initializing krb5" error). Also, ensure you enter the realm in upper-case letters, otherwise you will get a "kinit(v5): KDC reply did not match expectations while getting initial credentials" error message back. Finally, you must make sure the user who is requesting the ticket (in this case, Bob) has permissions in the Active Directory domain to create machine accounts, otherwise the join will fail. Once you have a Kerberos ticket, you can bind the Samba server to the Active Directory domain. To do this, change the directory to your Samba installation (/opt/local/bin, in my case) and run:

./net ads join

which will attempt to join the Samba server to the Active Directory domain. If all goes well, you should get a message that looks like this:

Using short domain name -- ENG

Joined 'SIREN' to realm 'ENG.PHANTOMCO.COM.AU'

which indicates that the Samba server called "Siren" has been bound. At this point, you can start your standard Samba services and Windows machines and the Active Directory domain will be able to map resources from the Samba server. If you are used to older versions of Samba, be sure that you start the winbindd daemon, in addition to the smbd and nmbd daemons.

Conclusion

Though there is a bit more work involved in laying the groundwork for binding Samba 3 to an Active Directory domain, once you have all the pieces in place, the process is quite easy. I have built packages for all the components using Easy Package Manager (see "Cross-Platform Native Package Creation with EPM" by Jeff Layton, Sys Admin, December 2003: http://www.samag.com/documents/s=8964/sam0312h/), so setting up a new Samba server is a matter of installing the packages and then doing the binding. Also, though this article deals with running Samba 3 on Solaris, the procedure should be the same for any other operating system supported by Samba 3. The only difference may be that you don't need to build third-party versions of the supporting libraries.

Resources

Kerberos source can be found at: http://web.mit.edu/kerberos/www/dist/

OpenLDAP source can be found at: http://www.OpenLDAP.org/

Samba 3 source can be found at: http://www.samba.org/

Brett Lymn is a small Unix admin cog in a multi-national company machine. He spends entirely too much time playing with computers but cannot help himself.