Valid HTML 4.01 Transitional

Samba Authentication by Active Directory

James F. Carter <>, 2014-01-18

The objective is to export UNIX (Linux) home directories to Windows machines. This access requires authentication.


UCLA-Mathnet users' UNIX home directories are hosted on one of four file servers and exported via NFS. PIC works similarly. Windows users want to use these UNIX home directories. (There is no present requirement for global shares between realms, and it is very rare for users on UNIX to want access to their Windows home directories.) At present, we have hosts called and which run the Samba CIFS gateway, version 3.6.12.

By policy, each user has both a UNIX and Windows account with the same user name (loginID). The password is not required to be the same for both (though that is typical). Windows uses Active Directory (Kerberos, LDAP, dynamic DNS) for identity maintenance. UNIX has the same components, but in a different realm. Cross-realm trust is planned but has not been set up yet.

At many sites the goal is to have UNIX use the Windows Kerberos, LDAP and dynamic DNS to authenticate users and manage identities, using winbind, or to have Windows use UNIX identity servers. That is not what we are trying to do here. We are just trying to share files between separate (though related) identities.

In the present setup, when the Windows user wants to map his UNIX home directory he uses Windows Explorer - Tools - Map Network Drive. It asks for a drive letter and a share name, which would be \\sambamath\user (replacing user with the user's own loginID on UNIX). Having negotiated a protocol with the Samba server, Windows asks for the user's password and sends it over. There is no Windows-style user secrets table on sambamath, and it uses PAM for authentication. Therefore the password must arrive unencrypted (actually, unhashed). It's a gaping security hole to have unencrypted passwords on the wire, although other elements of defense in depth mean that hackers do not have easy access to the plaintext traffic. We have always wanted to improve this situation but have not been able to make it work.

We are upgrading servers to OpenSuSE-13.1, and Samba-4.1.3 has a bug or feature that prevents plaintext passwords from being received and/or utilized by the server's cifs.ko kernel module. There are three possible courses of action: don't upgrade (unacceptable), fix the bug (failed so far), or use encrypted passwords. The latter approach has been made to work at last.

How to Accept Windows Kerberos Authentication

Kerberos for the Samba Server

Edit /etc/krb5.conf to include the Windows realm. (Actually for us it would be /etc/krb5/krb5.conf.m4). You need to add this stanza to the [realms] section. The domain name has been changed from to, to make it obvious what the reader has to change to his own domain.

kdc		=
kdc		=
kdc		=

master_kdc	=
admin_server	=
kpasswd_server	=

# Inferring the local loginID from the principal name.  DEFAULT
# means use the principal name minus the realm.  The rules
# convert user/root -> root and user/admin -> user.
auth_to_local = RULE:[2:$1;$2](^.*;root)s/^.*$/root/
auth_to_local = RULE:[2:$1;$2](^.*;admin)s/;admin$//
auth_to_local = DEFAULT
Samba Configuration

Edit /etc/samba/smb.conf making these changes. Do not restart the Samba server yet. The former authentication configuration was like this:

# security = user (is the default)
# Blecch, PAM can't deal with encrypted passwords.
encrypt passwords = no
client lanman auth = Yes
client plaintext auth = Yes
client NTLMv2 auth = No

The replacement configuration is this. Notice that I have a directory /etc/krb5 where I keep all my Kerberos files. Most people have them directly in /etc, so the keytab file would be /etc/windows.keytab.

security = ADS
kerberos method = dedicated keytab
dedicated keytab file = /etc/krb5/windows.keytab
# encrypt passwords = yes (is the default)
# client NTLMv2 auth = Yes (is the default)
Join the Domain

Join the domain using the edited smb.conf and krb5.conf.

net ads join member -k -S -U administrator -d 1

Explanation of the options:

In our setup the debug output comes out on stderr. These items should be looked for:

Extract the Windows Keytab

I want to use a separate keytab file from the default, because Linux tools work on it and would wipe out the entries not for the UNIX realm, i.e. for Windows. The various tools have poor support for creating alternative keytabs. This method is probably the easiest, although I actually used a more roundabout way. Also you will notice that my dedicated keytab file is shown as /etc/windows.keytab. Actually I have a directory /etc/krb5 where all the Kerberos files are, including windows.keytab. Use mv -i so it will warn you if you're going to overwrite something important.

mv -i /etc/krb5.keytab /etc/krb5.keytab.unix
net ads keytab create -U administrator  # Asks for the domain admin password
mv -i /etc/krb5.keytab /etc/windows.keytab
mv -i /etc/krb5.keytab.unix /etc/krb5.keytab
chmod 600 /etc/windows.keytab  # Should be read/writable only by root
klist -e -k /etc/windows.keytab

In the final klist command, -e makes it show the ciphers. it will show three principals: host/, host/sassafras@EXAMPLE.ORG, and SASSAFRAS@EXAMPLE.ORG. Each one will have five ciphers: des-cbc-crc des-cbc-md5 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96 arcfour-hmac. With luck, you have no back-version clients that require the inadequate DES ciphers.

(Re)start the Samba Daemon

systemctl restart smb  # With systemd, --or--
/etc/init.d/smb restart # With SysV LSB init scripts, --or-
(something involving upstart that I don't know)

A convenient test command on Linux is smbclient -U user -s smb.conf.hacked -L server using various servers. The options are:

Outcomes for various servers:

Now get on a Windows machine. These instructions are for Windows XP but Windows 7 and 8 are quite similar.

For reference, if you have RDP set up, you can do this from a Linux box using a command line similar to this one:

rdesktop -u jimc -d MATH -g 50%