By
Scott Lowe MCSE
Thursday, October 10 2002 12:00 PM
URL:
http://www.zdnetasia.com/techguide/network/0,3800010800,39081966,00.htm
As Linux becomes more prevalent in enterprises, the need
for interoperability between it and incumbent operating systems becomes more
important. After all, nobody 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 open
source 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.
Some administrators want to move to a native mode Active Directory domain but
still provide a central authentication service, so a new way to handle
authentication needs to be devised.
Enter Samba 3.0. The Samba team is
providing the means to handle this very task in it newest version, which is
still under development. I’m going to show you how to use the latest alpha
version of Samba to allow your Linux server to authenticate against a Windows
2000 domain controller.
From alpha to final code
This article employs the latest alpha version of Samba 3.0.
Although not ready for production networks, the alpha code does work and,
according to the road map, 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 article 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 for Linux. As of this writing, version
2.0.23-4 is the latest release and can be downloaded here.
- The MIT Kerberos development libraries for Linux. 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 whether you have these libraries installed, you can use the RPM command
to find out. Use the rpm -qa |grep openldap command to see whether 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 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 article 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:
- Expand the Samba 3.0 distribution with the command gunzip -cd
samba-3.0-alpha17.tar.gz | tar xvf -.
- Switch to the source directory of the newly created directory with the
command cd samba-3.0-alpha17/source.
- Run the configuration script, using the command /configure
-prefix=/usr/local/samba to instruct the script to install Samba into
/usr/local/samba.
- Make sure that the lines #define HAVE KRB5 1 and #define HAVE LDAP
1 are present in the include/config.h file.
- Compile the application with the make command.
- 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 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 that 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.
Join a Linux server to Active Directory with
Samba 3.0
Page 2 of 2
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 this:
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 in to the Windows 2000 server as a user,
such as Administrator, with the rights to do this. To log in to 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 verify
that the process worked, go to your Windows 2000 Server, open Active Directory
Users And Computers, and look at the entries. If the previous 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 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
that appears in Listing B. I’ve also included a directory listing to show
that it’s actually connected. Notice the line “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 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 that they were 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, they'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 that TechRepublic 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.
Editorial disclaimer: The authors and editors have
taken care in preparation of the content contained herein but make no expressed
or implied warranty of any kind and assume no responsibility for errors or
omissions. No liability is assumed for any damages. Always have a verified
backup before making any changes.
