Quest Software (logo)

Quest Samba Suite

How to configure native or third-party Samba with Vintela Authentication Services

Note: The Samba server configuration instructions in this document have since been automated by the vas-samba-config script found in the vasidmapd package.

Native Samba refers to Samba software supplied by Operating System vendors or related communities. There are also quite a few third-party Samba packages available for customers. Quest customers may want to use these packages on their systems for support purposes. Installing and configuring native or third-party Samba packages to work with VAS is easy and straightforward.

This page lists native and third-party Samba packages we are aware of, and provides a short guide for configuring them to work with Quest Authentication Services (VAS).

Native Samba packages

Most Linux distributions come with native Samba packages that are capable of working with VAS. HP-UX also has a CIFS server which works with VAS.

However, not all vendor-supplied Samba packages include Active Directory support which is required by VAS. For example, the Samba package distributed with Sun Solaris 10 was not compiled to support AD. Samba packages made available for IBM AIX and some old Linux operating systems are too old to support AD. Please see our detailed information on configuring native Samba packages for different operating systems. It also contains instructions for manually configuring native Samba packages to work with VAS, where that is possible.

Third-party Samba packages

For those operating system environments where native Samba packages are unavailable or do not work with VAS, there are third-party Samba packages available. The rest of this section introduces such Samba packages for IBM AIX and Sun Solaris. These have been tested and are known to work with VAS 3.2.

Installing third-party Samba on AIX

The Samba project provides a third-party binary package for AIX.

After downloading the package and installing the Samba package per the README file, Samba will be installed under /opt/pware/samba/<version>. The configuration file is /opt/pware/samba/<version>/lib/smb.conf.

The AIX Samba package also installs its own Kerberos 5 executables under /opt/pware/bin. The Kerberos 5 configuration file is /opt/pware/etc/krb5.conf.

Installing third-party Samba on Solaris

The OpenSolaris community, Blastwave provides a Solaris Samba package.

After reading the instructions on using the pkg_get tool you can install the Samba package with this command: 

# /opt/csw/bin/pkg-get -i CSWsamba

This installs Samba and all its dependant packages onto the local Solaris system under /opt/csw/. The configuration file is /opt/csw/etc/samba/smb.conf.

Making native or third-party Samba use Vintela Authentication Services

The following sections present detailed instructions for configuring native and third-party Samba packages to interoperate with VAS. Briefly, four steps are required:

  1. Edit smb.conf
  2. Edit vas.conf
  3. Run vasidmap-krb5-config to configure Kerberos
  4. Reset the local machine password to synchronize Samba with VAS

You can configure native and third-party Samba packages in one of two ways. You can either configure it manually by editing the smb.conf and vas.conf configuration files, or you can configure it by running the vas-samba-config-native script. In either case, you need to install the vasidmap package available for free at Resource Central website.

We introduce these two ways of configuration in the following two sections.

Configure Samba manually

Edit smb.conf

smb.conf is the main Samba configuration file. Native and third-party Samba packages keep this file in different locations:

Linux (Red Hat, SuSE, etc) /etc/samba/smb.conf
HP-UX /etc/opt/samba/smb.conf
Solaris /opt/csw/etc/samba/smb.conf
AIX /opt/pware/samba/<version>/smb.conf

You should modify or add the following parameters in the smb.conf file on your local system.

workgroup
This parameter sets the pre-Windows 2000 domain name of the server. It should match your domain's usual workgroup name. 
workgroup = EXAMPLE
realm
This parameter specifies the Active Directory domain name, also known as the Kerberos realm. You should set this parameter to the currently joined domain name. Use the command 
# vastool -u host/ info domain
to determine what it is. The realm is generally entered in uppercase. 
realm = EXAMPLE.COM
security
This parameter specifies the role of the server. It must be set to ads which means Active Directory Server. 
security = ads
use spnego
This parameter specifies whether RFC2478 authentication should be used. It must be enabled so as to allow encapsulated Kerberos authentication. 
use spnego = yes
use kerberos keytab
This parameter specifies whether Samba should keep the machine password (host key) in a private database, or in the keytab file named by the external Kerberos library. VAS keeps the machine password in the keytab file, /etc/opt/quest/vas/host.keytab, so this parameter must be enabled for interoperability. 
use keberos keytab = yes
machine password timeout
Both Samba and VAS attempt to reset the machine password approximately once a month to prevent the machine account being locked. This parameter must be set to 0 so that only VAS changes the machine password, otherwise vasd daemon may cease functioning. Please also see the changes to vas.conf, below. 
machine password timeout = 0

Edit vas.conf

You will need to add one parameter to vas.conf to inform Samba of automatic machine password changes. Vintela Authentication Services periodically changes the machine password, and Samba requires knowledge of this to perform NTLM authentication correctly. A small script installed by the vasidmap package provides this function. 

[vasd]
password-change-script = /opt/quest/libexec/vas-set-samba-password-native

However, on installations using earlier versions than VAS 3.1, you will have to instead disable automatic password changes. 

[vasd]
password-change-interval = 0

The default vas.conf file should work for most Samba deployments. However, if you have problems locating the domain controllers, you can use vastool info toconf to specify the realm and Domain Controller to use.

Run vasidmap-krb5-config to configure krb5.conf

Next, you should the vasidmap identity bridge tool. This package contains the vasidmapd service daemon, a few test utilities and some configuration scripts. The configuration script vasidmap-krb5-config modifies krb5.conf.

Before using the package you should ensure you have properly installed and configured Quest Authentication Services (VAS) (version 3.0.2 or later) and that your machine was successfully joined to the Active Directory domain.

vasidmap-krb5-config is a script tool to configure Kerberos 5 to work with VAS and Active Directory. It modifies existing config options or adds new config options into krb5.conf file so that Kerberos 5 works with VAS and Active Directory.

The script takes on optional argument: -s path which specifies the location of the krb5.conf file.

Without options, the vasidmap-krb5-config script searches for the krb5.conf file under default location and modifies it. The old config file is saved as krb5.conf.<date>.<pid> in the same directory. The default locations for different Unix and Linux platforms are:

Linux (Red Hat, Suse, etc) /etc/krb5.conf
HP-UX /etc/krb5.conf
Solaris /etc/krb5/krb5.conf
AIX /opt/pware/etc/krb5.conf

Invoke the script as root: 

# /opt/quest/bin/vasidmap-krb5-config

Here is list of potentially changed variables in krb5.conf made by vasidmap-krb5-config:

default_realm
This parameter is set to VAS's current realm.
default_keytab_name
This parameter is set to /etc/opt/quest/vas/host.keytab which is where VAS keeps the host keytab.
[realms]
This section is populated with the addressed discovered for the Active Directory services.
[domain_realms]
This section is populated with the DNS domains detected for the Active Directory domain.

For example: 

[libdefaults]
 default_realm = EXAMPLE.COM
 default_keytab_name = /etc/opt/quest/vas/host.keytab

[realms]
 EXAMPLE.COM = {
  kdc = kerberos.example.com:88
  kpasswd_server = kerberos.example.com:464
 }

[domain_realm]
 .example.com = EXAMPLE.COM
 example.com = EXAMPLE.COM

Synchronize the host password between Active Directory and Samba

You need to synchronize the host password between Active Directory and Samba. 

# /opt/quest/bin/vastool -q -u host/ passwd -r -o | net -f -i changesecretpw

You might have to provide the full path to the net command which will be in the Samba bin or sbin directory.

On some systems the net command doesn't support the -i option. In this case you will have to run each command separately and manually supply the output of one to the other: 

# /opt/quest/bin/vastool -q -u host/ passwd -r -o
<random-password>
# net -f changesecretpw
Enter machine password: <random-password>
Modified trust account password in secrets database

Configure Samba using provided scripts from vasidmap pacakge

Instead of manually editing the smb.conf and vas.conf files, you can use a script provided in vasidmap package. The vas-samba-config-native script can be used for configuring smb.conf and vas.conf as well as for sychronizing the host password between Active Directory and Samba. It also performs some checks on the existing configuration.

Before running this script, make sure vasd is running, and modified krb5.conf by running /opt/quest/libexec/vasidmap-krb5-config script. Please refer to the section on running vasidmap-krb5-config for more information.

Now you can invoke /opt/quest/bin/vas-samba-config-native to perform the configuration and sychronize the host password. This script modifies smb.conf in its default location (/etc/opt/quest/samba/smb.conf). To configure one at different location, you can specify it with the -s /path/smb.conf option.

Note that this script uses Samba's net command to perform some checks. On older versions of Samba, this command may fail. You can ignore the failures. However, we still recommend installing the latest available Samba on your system. In the case where the script fails to synchonize the host password due to an old version of net command or absence of the tdbtool command, please follow the instructions in the section on synchronizing the machine secret.

It is also recommended that you check smb.conf and vas.conf after running the script to make sure the modifications made are correct. You can refer to details in the sections on editing smb.conf and editing vas.conf for details.

Testing the Samba server is properly configured

There are a couple of basic tests that can be done to make sure your Samba server is properly configured.

First of all, after each edit of the smb.conf file run the tool named testparm. This tool will check that parameter names are correct. It will also confirm that the Samba server is configured as a domain member.

You can also test that Samba recognizes itself as correctly joined to the windows domain by running the basic join tests: 

# /path/net ads testjoin
# /path/net rpc testjoin

These two commands will confirm that Samba is correctly joined both using the Kerberos/AD and the NTLM/RPC protocols.

If the rpc testjoin command takes a long time, or fails, you may need to set the wins server parameter in smb.conf to the IP address of a known AD server.

Finally, get a shell on your machine as a normal user. Make sure you have a Kerberos ticket: 

$ vastool kinit
Password for alice@example.com:

Then try to access your home directory via the [homes] share: 

$ smbclient //server.example.com/alice
where server.example.com is the fully-qualified hostname of your server, and alice is your username.

This will let you browse your home directory. (It is assumed that you have not modified the default [homes] section in the Samba configuration file. If you have, then use some other share you have configured.)

If you are upgrading a previous Samba server you may find directives such as valid users or invalid users on some shares. Please note that recently the Samba configuration rules have been tightened and now Samba requires strict identification of users and groups in these directives. Therefore if you want to apply one of these rules to domain users make sure the name is fully qualified. As of Samba 3.0.23 you should use the forms DOMAIN\username and DOMAIN\groupname to identify domain users and groups. DOMAIN is always the short domain name, not the Active Directory domain name (Kerberos realm). Also, remember to use quotes surrounding names with spaces. For example: 

valid users = EXAMPLE\alice @"EXAMPLE\Domain Users"

If you have problems you may raise the log level of your Samba sever to 5 (initially) or 10 (for high quantity of output), and make sure log size is set to 0 so that your logs are not rotated. Quest recommend you do not use higher log levels and absolutely never use log level = 100 or it will fill up your disk.

Troubleshooting notes

Common problems

I changed the host/ password and now samba logins don't work. The logs show failed to get schannel session key from HOST for domain DOMAIN: Error was NT_STATUS_ACCESS_DENIED
If you changed the password with something like 
# vastool -u host/ passwd -r  or
# vastool -u Administrator passwd -r host/
then the two machine secrets for the host will have become desynchronized and the samba server will shortly discover it can't talk to any other domain controllers.

The reason for desynchronisation is that copies of the host's secret key are kept in VAS's /etc/opt/quest/vas/host.keytab and Samba's /path/samba/secrets.tdb. And only one of them was updated.

You can, and should, reset the password in both files simultaneously with the following command: 

# /opt/quest/bin/vastool -q -u host/ passwd -r -o |
    /path/net -f -i changesecretpw
# /path/net ads testjoin
When running vas-samba-config-native, you see "/opt/quest/libexec/vas-set-samba-password-native: line 26: /usr/bin/tdbtool: No such file or directory"
The scripts use Samba's net tool to sychronize host password. In the case when this tool doesn't support the -i changesecretpw option, the script reverts to using Samba's tdbtool to directly update Samba's secret database. On some Linux platforms with old native Samba packages, this command is not available either. You must upgrade Samba to a modern version so either net or tdbtool command can be used to changed Samba secret database automatically.
I have configured the smb.conf as described, but when starting the Samba daemon, it still complains of unknown configuration in the configuration file.
If you copied the smb.conf from the sample file provided by the package, it will contain some configuration entries for example purposes that are unknown to older versions of Samba. You have to correct or comment out this entries manually. The scripts we provide do not change these entries. Use Samba's testparm tool to directly check the configuration.
smbclient is complaining NT_STATUS_CANT_ACCESS_DOMAIN_INFO, or Windows user is seeing the error "\\host\share is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions. Configuration information could not be read from the domain controller, either because the machine is unavailable, or access has been denied."
This can be caused by having the wrong workgroup in /path/smb.conf. See how to configure smb.conf to fix this problem.
Access is denied for some Unix users when smb.conf contains a username map:
The primary group of a Unix-enabled VAS user must itself be Unix-enabled, or Samba will refuse to serve it. Samba 3.0.23a treats the primary SID group as the primary GID. A workaround for this problem is to Unix-enable the 'Domain Users' group.
smbd frequently complains reply_spnego_kerberos(286) Username DOMAIN\username is invalid on this system:
This usually happens when a non Unix-enabled account performs a network browse. It is often a workstation account, appearing as DOMAIN\HOST$. The account successfully authenticates itself to the samba server, but there is no UID associated with it (as it's not VAS-enabled). The messages are harmless, and indicate that some of your shares can't be accessed by non-Unix enabled users.

To remove these messages, do ONE of the following:

  1. specify "log level = 0" in smb.conf. This will hide those messages (and other messages).
  2. specify "map to guest = bad uid" in smb.conf. This will map non-VAS-enabled users who correctly authenticate to the 'nobody' UID. If you have your share set as writable by those users, then they may be able to create files that appear to be owned by 'nobody'.
  3. VAS-enable those accounts.
smbd won't start: ld.so.1: vasidmapd: fatal: relocation error: file /opt/quest/sbin/vasidmapd: symbol vas_group_get_grinfo: referenced symbol not found
vasidmap uses new features not available in earlier versions of VAS. Upgrade VAS to 3.0.2 or later.
smbclient complains spnego_gen_negTokenTarg failed: No such file or directory; session setup failed: SUCCESS - 0:
Your credential cache is missing. Run 
$ vastool kinit
to login and get a new TGT, then try again.
winbindd exits after complaining fetch_ldap_pw: neither ldap secret retrieved!; ldap_connect_system: Failed to retrieve password from secrets.tdb; Connection to LDAP server failed for the 1 try!
Somehow the secrets.tdb file has become corrupt. The following may help: 
# /opt/quest/bin/tdbtool /path/samba/secrets.tdb
tdb> insert SECRETS/LDAP_BIND_PW/CN=VasIdmapAdmin secret
tdb> quit
and then restart the winbindd service. The secret value is actually ignored when received by vasidmapd, so it can be anything.
I re-joined the server and now my Windows users are prompted for a password.
Ask your Windows users to flush their credentials with Ctrl-Alt-Del and lock workstation. Entering a password to unlock a workstation forces fresh credentials to be obtained for all services.
smb complains: smbd/sesssetup.c:reply_spnego_kerberos(##) Failed to verify incoming ticket!
This indicates a problem with the Keberos ticket that the client has obtained to use the Samba service (smbd). It is possible that either the ticket key is stale or the service name in the ticket is wrong.

The ticket key can be stale if you recently rejoined the Samba server to the domain or reset the machine secret (host key). In this case, the client should flush their credential cache (vastool kdestroy/kinit on Unix, or Ctrl-Alt-Del, lock and unlock display on windows, or wait 8 hours for a refresh).

Another explanation is that the name in the ticket is wrong. This can happen because clients typically ask Active Directory for a cifs/ ticket, but cifs/ is aliased to host/. When Samba receives the ticket it dispatches it to the local Kerberos library, which searches a keytab file for a matching service name.

If you are using MIT Kerberos (for example with Red Hat samba), it is known to be very sensitive to the service name. In this case you may need to arrange to have a separate < class="path"i>cifs/ service in Active Directory (with corresponding entries in the system keytab), or you can create a duplicate from existing keytab entries using ktutil or ktedit.

Alternatively, you can use a Heimdal Kerberos library with Samba. Heimdal ignores the name in the ticket and simply tries all the keys it can find until one works. Quest-samba's binaries include Heimdal Kerberos.

Troubleshooting steps

These notes assume that VAS is installed and working correctly. They focus on problems with Samba configuration.

Advanced troubleshooting steps

Native and 3rd party Sambas Download information

Release: Native or third party Sambas
Platform Filename Samba source
aix-ppcopt-samba-3.0.28-AIX5-tar.gzThird party
hpuxHP CIFS A.02.03.03Native
linuxFind CD or Linux vendor's websiteNative
solarisCSWsambaThird party

References