With Linux becoming more prevalent in enterprises, the need for interoperability between it and incumbent operating systems becomes more important. Who wants to add a new system if it will require a whole new set of administration tools and additional user accounts?

One tool that has become ubiquitous in Linux configurations is Samba, the freeware file services and authorization software. The release of Windows 2000 and its use of Active Directory complicated integrating a Linux server in a Microsoft environment, which had become a snap with Windows NT and Samba version 2.2.x. Although Samba can still be used as a domain controller, it requires a mixed-mode Windows 2000 domain, in which some Windows NT 4.0 domain controllers are still present (Samba is considered a Windows NT 4.0 domain controller).

In addition, Windows 2000 (and XP) uses Active Directory with the Kerberos authentication protocol, which presents new challenges for interoperability. With some administrators’ desire to move to a native mode Active Directory domain, but still provide a central authentication service, a new way needs to be devised to handle authentication.

Enter Samba 3.0. The Samba team is providing the means to handle exactly this task in it newest version, which is still under heavy development. In this Daily Drill Down, I’ll show you how to use the latest alpha version of Samba to allow your Linux server to authenticate against a Windows 2000 domain controller.

Alpha to Omega

This Daily Drill Down employs the latest alpha version of Samba 3.0. Although not ready for production networks, the alpha code does work and, according to the roadmap, will not drastically change when the full public release is ready. After a lengthy chat with the Samba development team, I was reassured that coming changes to Samba 3.0 (from alpha to the final release) will primarily be the addition of features and the stabilization of the code. The installation and configurations shown in this Daily Drill Down, however, are not likely to change.

What you need
To get Samba 3.0 up and running, you must have:

  • ·        Windows 2000 Server acting as a domain controller.
  • ·        The OpenLDAP development libraries. As of this writing, version 2.0.23-4 is the latest release and can be downloaded here.
  • ·        The MIT Kerberos development libraries. As of this writing, these libraries are at version 1.2.4-1. krb5-devel can be downloaded here; \\krb5-libs can be downloaded here; and krb5-workstation can be downloaded here.
  • ·        The latest version of the Samba alpha code (I chose not to get the CVS version). As of this writing, build 17 of the Samba code was the latest and can be downloaded here.

If you’re not sure if you have these libraries installed, you can use the RPM command to find out. Use the rpm -qa |grep openldap command to see if you have the openldap-devel library and use rpm –qa | grep krb to check for the Kerberos libraries. If you are missing any of these libraries, install them with the rpm –i libraryname command. The only library that I was missing in my default Red Hat Linux 7.3 installation was the krb5-workstation library.

IP addresses

The IP addresses of the machines used in this Daily Drill Down will be:
Win2k – 10.109.10.133
Linux – 10.109.10.132

Installing Samba 3.0
The installation of Samba 3.0 is fairly straightforward. Follow these steps:

  1. 1.      Expand the Samba 3.0 distribution with the command gunzip -cd samba-3.0-alpha17.tar.gz | tar xvf -.
  2. 2.      Switch to the source directory of the newly created directory with the command cd samba-3.0-alpha17/source.
  3. 3.      Run the configuration script, using the command /configure -prefix=/usr/local/samba to instruct the script to install Samba into /usr/local/samba.
  4. 4.      Make sure the lines #define HAVE KRB5 1 and #define HAVE LDAP 1 are present in the include/config.h file.
  5. 5.      Compile the application with the make command.
  6. 6.      Install the application with the make install command.

Configuring Kerberos
You need to configure some parameters to let the Kerberos process know how to handle the Active Directory server. Listing A shows the entire contents of my /etc/krb5.conf file. Make the appropriate modifications to your configuration, keeping in mind that case matters to Kerberos; SLOWE.COM and slowe.com do not match.

You have one more thing to check. While it might sound trivial, I cannot stress enough the importance of clock synchronization between your Windows 2000 Server and your Linux server. If the time is off by more than five minutes, the two servers will be able to communicate, but no ticket information will work. This is very easy to troubleshoot because you will be greeted with kinit(v5): Clock skew too great while getting initial credentials when you test Kerberos.

To make sure your connection is working, run the command /usr/kerberos/bin/kinit nuser@SLOWE.COM. The Kerberos kinit command will test communication between your servers. The syntax is kinit user@REALM, where REALM is your Active Directory domain name and must be uppercase. If you do not use all uppercase for the realm, you’ll receive this error:
kinit(v5): Cannot find KDC for requested realm while getting initial credentials.

If communication is working, you’ll be prompted for the user password. When entered correctly, you’ll simply come back to a bash prompt. If entered incorrectly, you’ll receive the error: kinit(v5): Preauthentication failed while getting initial credentials.

Configuring Samba
Once installation is complete, you need to create a Samba configuration file. Samba uses the file /usr/local/samba/lib/smb.conf for its configuration parameters. To begin, I’ll set up a very minimal configuration file that looks like:
realm = SLOWE.COM
ads server = 10.109.10.133
security = ADS
encrypt passwords = yes

In this configuration file, the realm statement sets the Kerberos realm information. This is analogous to a domain name and has to be all uppercase. The ads server statement is the resolvable name or the IP address of your Windows 2000 domain controller server. I chose to use the IP address to remove the possibility of any DNS issues. The security statement tells Samba to use Active Directory security. Finally, the encrypt passwords statement tells Samba that passwords need to be encrypted to work with the Kerberos protocol.

Putting it all together
With Samba and Kerberos both configured, you need to create a computer account in the Windows 2000 Active Directory. To do this, you must log into the Windows 2000 server as a user, such as Administrator, with the rights to do this. To log into the server from your Linux machine, run the /usr/kerberos/bin/kinit administrator@SLOWE.COM command, and you’ll be prompted for your Administrator password. To create the computer account, enter the /usr/local/samba/bin/net ads join command. If successful, you’ll get a message similar to: Joined ‘LDAPS’ to realm ‘SLOWE.COM.

To make sure the process worked, go to your Windows 2000 Server, open Active Directory Users and Computers, and look at the entries. If the above step worked, you’ll see an entry in this list with the name of your Linux server. My Linux server is named ldaps and now appears in the list.

Testing it
On your Linux machine, you should be able to connect to Windows shares using Samba’s smbclient without the need for a password (thanks to Kerberos). To test this, enter the /usr/local/samba/bin/smbclient //w2k/c\$ -k command at the Linux prompt.

Since this is still an alpha version of Samba 3.0, you’ll see a number of errors scroll by, but this command still works. You’ll finally be connected to the C$ administrative share on your Windows 2000 Server.

On my system, this resulted in the output shown in Listing B. I’ve also included a directory listing to show that it’s actually connected. Notice the line stating, “Doing kerberos session setup.” Samba has come a long way.

And now, the problems!
Being alpha code, Samba 3.0 still has bugs, which is to be expected. Among the errors that I received were various compilation warnings as well as errors when utilities were run. These bugs are due to the drastic changes made in transition from Samba 2.x to 3.0 and will all eventually disappear as Samba 3.0 reaches final release. In addition to the standard bug fare, I’m not able to make Kerberos connections to the Samba server, but as you could see from the examples, the server is more than capable of initiating them. Making the connection from Windows to Linux is one of the major focuses of the Samba development team, so rest assured that this feature will be in place at some point between the alpha release and the final release.

Stay tuned for more
One interesting quirk in my trial install was that the Linux server was able to connect to the Win2K server and access and use the available shares, but the Win2K server was unable to access and use the Linux shared directories. I contacted the Samba team to make sure they are aware of the inability of Samba 3.0 to allow two-way use of shared directories. As Samba 3.0 develops into full-release status, we’re confident this problem will be resolved. The Samba teams also informed me that they’ll add the first ever upgrade wizards to help users and administrators make the migration from the old Samba 2.x smb.conf files to the newer Samba 3.0 smb.conf files. You can be sure TechProGuild will be covering these wizards as they arrive.

If you are interested in staying on top of the development process of Samba 3.0, the best place to keep apprised of news is one of the many Samba mailing lists. For more information on where the Samba 3.0 development is heading, visit the Samba road map.