You are on page 1of 5

www.lanzarotecaliente.

com (press
control & click here)

Join a Linux server to Active Directory with Samba 3.0


July 11, 2002
Scott Lowe MCSE

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

You might also like