Quest Software

Quest ID Mapper

Using Samba Version 3.0.9 with Quest Authentication Services and Active Directory

Overview

Samba 3.0.9, and later versions, support Active Directory and Kerberos in a way that lets Samba interoperate successfully with Quest Authentication Services (QAS). Prior to Samba 3.0.9, it was necessary to configure Samba and Quest Authentication Services to use different computer objects, as each were unable to communicate information about the host password (also known as the machine password, or host key). Each uses the password to authenticate as the computer object in Active Directory, and it changes periodically. Previously, Samba created and stored the machine password in /etc/samba/secrets.tdb, while Quest Authentication Services created and stored its in /etc/opt/quest/vas/host.keytab.

Samba 3.0.9, and later versions, as well as supporting Active Directory as a password server for Samba shares, have also been 'Kerberized'. This means Samba can use the system-wide Kerberos facilities installed on the host. In particular, Samba uses Kerberos to manage the host password. Kerberos can, in turn, be configured to use the same key store as Quest Authentication Services.

You can make most Kerberos applications (including Samba) interoperate with Quest Authentication Services by making /etc/krb5.conf point at /etc/opt/vintela/vas/vas.conf as described below. This works for other Kerberised applications, and with either the Heimdal or MIT libraries since Quest Authentication Services stores its Kerberos parameters in a standard format understood by both. The configuration parameter of interest is default_keytab_name which Quest Authentication Services sets to point to the keytab file containing the host password.

Configuring Samba with Quest Authentication Services

This section presents step-by-step instructions for integrating Samba with Quest Authentication Services.

Your Samba software should be version 3.0.9 or later, and should have been compiled with the Kerberos and Active Directory features enabled. The current release of Samba is available at www.samba.org, where you can also find prebuilt binaries for all the platforms supported by Quest Authentication Services.

The first step involves asking Quest Authentication Services to update vas.conf with all of its cached Kerberos data. This helps Kerberized applications work in complex Active Directory environments. 

# vastool realms cache toconf

Next, delete or move any existing /etc/krb5.conf, and then create a symbolic link in its place: 

# ln -s /etc/opt/quest/vas/vas.conf /etc/krb5.conf

Edit smb.conf

Next, you must edit Samba's configuration file. This is typically named /etc/samba/smb.conf.

The smb.conf file is divided into sections. The configuration parameters of interest here are in the [global] section. Below is a basic [global] section that uses Active Directory: 

[global]
	realm = INTERNAL.EXAMPLE.COM
	workgroup = INTERNAL
	password server = adserver.example.com
	security = ADS
	encrypt passwords = yes
	use spnego = yes
	name resolve order = host 
	use kerberos keytab = yes
	machine password timeout = 0

	



These setting are explained as follows:






realm = ...

The Kerberos realm.
This is the same as your Active Directory domain that the host is a member of,
in uppercase.

workgroup = ...

The NTLM-style workgroup name.

password server = ...

The fully qualified DNS name of the Active Directory domain controller.

security = ADS

The security mode. This must be set to ADS for 
Active Directory.

encrypt passwords = yes

This must be set to yes for operation with Kerberos.

use spnego = yes

This must be set to yes. It enables use of the 
Negotiate protocol between clients and the Samba Server.

name resolve order = host

This tells Samba to use Quest Authentication Services
through NSS when resolving names.

use kerberos keytab = yes

This tells Samba to use the Kerberos default keytab named in the 
/etc/krb5.conf file.

machine password timeout = 0

Prevents Samba from periodically changing the host key,
as Quest Authentication Services does this already.





Together, these form the minimum set of 
configuration directives required for Samba to
interoperate with Active Directory via Quest Authentication Services.




Restart Samba




When you have completed your configuration, it will be necessary to
start (or restart) the Samba daemon to have it read in the new
configuration file. Make it do this by issuing, as root, a command such as
the following:




# /etc/init.d/smb restart




In order to browse your Samba shares from your desktop clients, 
it is also necessary that the Samba nmbd daemon be running.
If it isn't started by the above command, you may need to start it
with:




# /etc/init.d/nmb restart



Further documentation




The configuration options in smb.conf are explained in the 
smb.conf 
manual pages. 





The Samba documentation
is extensive, though when applying it to an Active Directory environment,
the reader must be aware that its emphasis is on NTLM authentication.
Samba's origins are in the (pre-Active Directory) NTLM Domain
Controller era, and many of the terms and concepts are still phrased in
consideration of that model.
The documentation is still authoritative in providing guidance for using
Kerberos and Active Directory to authenticate Windows clients against
your Samba server using Active Directory.




Caveats




There are several important factors to note about running Samba with
Kerberos/Active Directory.  The most important is to understand that
this configuration requires that all
clients authenticate via Kerberos.
This means all unix clients will need be running a recent version of Samba,
and be joined to the Active Directory Kerberos realm.





Secondly, if Active Directory becomes unavailable to the clients for a length
of time, then users will be unable to access the Samba server.
The Samba server itself does not need to talk to AD; it relies on its
host key. Clients that had already acquired 
tickets to use the server can
keep using those tickets until they expire (typically 7.5 hours), but 
new clients can't access the Samba server if they can't access Active
Directory.





Samba's net utility can cause problems with
Quest Authentication Services.
Some of its commands will overwrite 
Quest Authentication Services' host keytab, resulting
in confusion between Authentication Services and the Samba server.
The Samba commands that should never be used with
Quest Authentication Services are:


  
net ads join 
  
use /opt/quest/bin/vastool join instead
  
net ads changetrustpw 
  
use /opt/quest/bin/vastool -u host/ passwd instead
  
net ads keytab create 
  
Quest Authentication Services already has a keytab file




Known problems




Samba linked against MIT's Kerberos library (e.g. as distributed with
Red Hat or Fedora) will reject tickets generated by Microsoft clients,
unless a cifs service is explicitly created.
This is because Microsoft Windows clients (such as Windows XP Pro) will 
acquire a cifs/ service ticket to access the Samba server,
(even if you have never created such a service, with, say, 
vastool service create cifs). 
Active Directory dubiously gives the Windows client a cifs
ticket for is actually encrypted with the host/ key.
Subsequently, the MIT library rejects the ticket because it performs
stricter checks than Quest Authentication Services' Heimdal-derived Kerberos implementation.