This article describes how to integrate an Arch Linux system with an existing Windows domain network using Samba.

Before continuing, you must have an existing Active Directory domain, and have a user with the appropriate rights within the domain to: query users and add computer accounts (Domain Join).

This document is not an intended as a complete guide to Active Directory nor Samba. Refer to the resources section for additional information.

Active Directory serves as a central location for network administration and security. It is responsible for authenticating and authorizing all users and computers within a Windows domain network, assigning and enforcing security policies for all computers in a network and installing or updating software on network computers. For example, when a user logs into a computer that is part of a Windows domain, it is Active Directory that verifies his or her password and specifies whether he or she is a system administrator or normal user. Server computers on which Active Directory is running are called domain controllers.

Active Directory configuration

This section works with the default configuration of Windows Server 2012 R2.

GPO considerations

Digital signing is enabled by default in Windows Server, and must be enabled at both the client and server level. For certain versions of Samba, Linux clients may experience issues connecting to the domain and/or shares. It's recommended you add the following parameters to your smb.conf file:

client signing = auto
server signing = auto

If that is not successful, you can disable Digital Sign Communication (Always) in the AD group policies. In your AD Group Policy editor, locate:

Configuring NTP

On the NTP servers configuration, use the IP addresses for the AD servers, as they typically run NTP as a service. Alternatively, you can use other known NTP servers provided the Active directory servers sync to the same stratum.

Ensure that the service is configured to sync the time automatically very early on startup.

Kerberos

Let us assume that your AD is named example.com. Let us further assume your AD is ruled by two domain controllers, the primary and secondary one, which are named PDC and BDC, pdc.example.com and bdc.example.com respectively. Their IP adresses will be 192.168.1.2 and 192.168.1.3 in this example. Take care to watch your syntax; upper-case is very important here.

Note: Heimdal 1.3.1 deprecated DES encryption which is required for AD authentication before Windows Server 2008. You will probably have to add

allow_weak_crypto = true

to the [libdefaults] section.

Creating a Kerberos ticket

Note: The keys and commands are user specific: sudo will be root, so your non-elevated account can connect to a different AD user with a separate key. If you only have one domain, it is not necessary to type @EXAMPLE.COM

Now you can query the AD domain controllers and request a kerberos ticket (uppercase is necessary):

kinit administrator@EXAMPLE.COM

You can use any username that has rights as a Domain Administrator.

Validating the Ticket

Run klist to verify you did receive the token. You should see something similar to:

With this setup, winbind will create user keytabs on the fly (krb5_ccache_type = FILE) at login and maintain them. You can verify this by simply running klist in a shell after logging in as an AD user but without needing to run kinit. You may need to set additional permissions on /etc/krb5.keytab eg 640 instead of 600 to get this to work (see FS#52621 for example)

Samba

Samba is a free software re-implementation of the SMB/CIFS networking protocol. It also includes tools for Linux machines to act as Windows networking servers and clients.

Note: The configuration can vary greatly depending on how the Windows environment is deployed. Be prepared to troubleshoot and research

In this section, we will focus on getting Authentication to work first by editing the 'Global' section first. Later, we will go back and add shares.

Note: In samba 4.8.0-1, the Samba daemon units have been renamed from smbd.service, nmbd.service, and winbindd.service to smb.service, nmb.service, and winbind.service.

Next we will need to modify the NSSwitch configuration, which tells the Linux host how to retrieve information from various sources and in which order to do so. In this case, we are appending Active Directory as additional sources for Users, Groups, and Hosts.

Configuring PAM

Now we will change various rules in PAM to allow Active Directory users to use the system for things like login and sudo access. When changing the rules, note the order of these items and whether they are marked as required or sufficient is critical to things working as expected. You should not deviate from these rules unless you know how to write PAM rules.

In case of logins, PAM should first ask for AD accounts, and for local accounts if no matching AD account was found. Therefore, we add entries to include pam_winbind.so into the authentication process.

The Arch Linux PAM configuration keeps the central auth process in /etc/pam.d/system-auth. Starting with the stock configuration from pambase, change it like this:

passwd

"password" section

In order for logged-in Active Directory users to be able to change their passwords with the 'passwd' command, the file /etc/pam.d/passwd must include the information from system-auth.

Find the line:

password required pam_unix.so sha512 shadow nullok

Delete it, and replace with:

password include system-auth

Testing login

Now, start a new console session (or ssh) and try to login using the AD credentials. The domain name is optional, as this was set in the Winbind configuration as 'default realm'. Please note that in the case of ssh, you will need to modify the /etc/ssh/sshd_config file to allow kerberos authentication (KerberosAuthentication yes).

test.user
EXAMPLE+test.user

Both should work. You should notice that /home/example/test.user will be automatically created.
Log into another session using an linux account. Check that you still be able to log in as root - but keep in mind to be logged in as root in at least one session!

Configuring Shares

Earlier we skipped configuration of the shares. Now that things are working, go back to /etc/samba/smb.conf, and add the exports for the host that you want available on the windows network.

In the above example, the keyword NETWORK is to be used. Do not mistakenly substitute this with your domain name. For adding groups, prepend the '@' symbol to the group. Note that Domain Admins is encapsulated in quotes so Samba correctly parses it when reading the configuration file.

Adding a machine keytab file and activating password-free kerberized ssh to the machine

This explains how to generate a machine keytab file which you will need e.g. to enable password-free kerberized ssh to your machine from other machines in the domain. The scenario in mind is that you have a bunch of systems in your domain and you just added a server/workstation using the above description to your domain onto which a lot of users need to ssh in order to work - e.g. GPU workstation or an OpenMP compute node, etc. In this case you might not want to type your password every time you log in. On the other hand the key authentication used by many users in this case can not give you the necessary credentials to e.g. mount kerberized NFSv4 shares. So this will help you to enable password-free logins from your clients to the machine in question using kerberos ticket forwarding.

Creating a machine key tab file

run 'net ads keytab create -U administrator' as root to create a machine keytab file in /etc/krb5.keytab. It will prompt you with a warning that we need to enable keytab authentication in our configuration file, so we will do that in the next step. In my case it had problems when a key tab file is already in place - the command just did not come back it hang ... In that case you should rename the existing /etc/krb5.keytab and run the command again - it should work now.

Adding necessary options on client

First we need to make sure that the tickets on our client are forwardable. This is usually standard but we better check anyways. You have to look for the forwardable option and set it to 'true' in the Kerberos config file /etc/krb5.conf

forwardable = true

Secondly we need to add the options

GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

to our .ssh/config file to tell ssh to use this options - alternatively they can be invoked using the -o options directly in the ssh command (see 'man ssh' for help).

Testing the setup

On Client:

make sure you have a valid ticket - if in doubt run 'kinit'

then use ssh to connect to you machine

ssh myarchlinux.example.com

you should get connected without needing to enter your password.

if you have key authentication additionally activated then you should perform

ssh -v myarchlinux.example.com

to see which authentication method it actually uses.

For debugging you can enable DEBUG3 on the server and look into the journal using journalctl.

Nifty fine-tuning for complete password-free kerberos handling.

In case your clients are not using domain accounts on their local machines (for whatever reason) it can be hard to actually teach them to kinit before ssh to the workstation. Therefore I came up with a nice workaround:

It should not promt you to give your password nor should it give any other feedback. If it worked you are basically done - just put the line above into your ~./bashrc - you can now get kerberos tickets without typing a password and with that you can connect to your workstation without typing a password while being completely kerberized and able to authenticate against NFSv4 and CIFS via tickets - pretty neat.

Nice to know

The file 'username.keytab' is not machinespecific and can therefore be copied around. E.g. we created the files on a linux machine and copied them to our Mac clients as the commands on Macs are different ...