Samba Authentication by Active Directory

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

Introduction

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 sambamath.math.ucla.edu and sambapic.pic.ucla.edu 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 math.ucla.edu to example.org, to make it obvious what the reader has to change to his own domain.

EXAMPLE.ORG = {
kdc		= foothill.example.org
kdc		= palomar.example.org
kdc		= maunakea.example.org

master_kdc	= foothill.example.org
admin_server	= foothill.example.org
kpasswd_server	= foothill.example.org

# 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
realm = EXAMPLE.ORG
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 foothill.example.org -U administrator -d 1

Explanation of the options:

• ads : You need to specify the protocol family it will use.
• join : The main command, for joining the domain.
• member : Windows will not set up credentials making the Samba server a domain controller, just an ordinary host.
• -k : Use Kerberos for authentication; even so, an existing ticket will not be used and you will have to give the admin password again.
• -S foothill.example.org : Use this domain controller. In Active Directory they are all peers, but it's better to use the one with the kadmin and kpasswd services.
• -U administrator : This is the domain administrator, who has privileges to add a host to the domain.
• -d 1 : Optional, make it log some extra information.
• The name of the host being joined is inferred from smb.conf; the default is the one-component name per `hostname` and the FQDN from `hostname --fqdn`.

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

• Kinit failed: Client not found in Kerberos database -- It's probably reporting that the host being joined has no prior Kerberos principal, which is no surprise.

• Joined 'SASSAFRAS' to dns domain 'example.org' -- a good outcome.

• DNS Update for sassafras.example.org failed: ERROR_DNS_GSS_ERROR -- We are very paranoid: we use DNS on UNIX and we don't turn on dynamic DNS, relying on pre-existing static configuration. Thus this step always fails for us.

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/sassafras.example.org@EXAMPLE.ORG, 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)

Testing

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

• -L server : List the shares available on this server. The list can be long.
• -U user : Specify a user who has a Windows account, in case you're being lazy and doing this as root.
• -s smb.conf.hacked : If you need to test altered parameters, specify an alternate smb.conf file here.
• -k : Use Kerberos authentication. You should be able to use a pre-established Windows TGT, but smbclient and the Windows KDC are unable to negotiate a cipher and HMAC. This should be fixable but I haven't figured it out yet.
• -N : Skips authentication. The share list is not secret. If authentication fails, supply this option and verify that the server is capable of delivering the share list.

Outcomes for various servers:

• Palomar: Windows file server, positive control. Works with the new configuration.

• Sassafras: Samba server for testing. Works with the new configuration.

• Sambamath: Samba server with the old configuration. You need to specify the old smb.conf file; then it will work.

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

• Start (hit the Start pearl) - My Computer - Tools - Map Network Drive.
• Windows asks for a drive letter (prefilled, no need to change) and the share name in the form \\server\user; for me: \\sassafras\jimc .
• With the bad old configuration it would ask for a plaintext password at this point -- the password on UNIX to be interpreted by PAM. With ADS authentication your Kerberos ticket on Windows is honored and the password is not demanded again.
• A Windows Explorer page opens on your UNIX home directory. Success!

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% rdesk003.example.org