LPIC-3 Mixed Environments 3.0 Introduction #04: 304: Samba Client Configuration

This blog posting is the fourth in a series that helps you prepare for the new version 3.0 of the LPIC-3 Mixed Environments exam. In the previous post we set up an entire infrastructure, containing of two Active Directory domain controllers, a file server and a Windows client. This week we will learn how to add even more systems to our domain.

Sources for User Information

An Active Directory holds information about user accounts, including the credentials used to authenticate each user. The overall idea is to maintain this information in the directory and then get access to it on each and every computer that is joined into the domain. We have already achieved this for the virtual Windows client, but we have not considered how we can make the average Linux workstation recognize the domain users as well.

On Linux, there are multiple approaches to authenticate users against a remote repository of user information. All such approaches have a common approach: they add additional sources of user data that Linux queries when it looks up a user. Once these lookups are successful, Linux queries a single set of user information, no matter where this information came from.

One technology that merges many data sources is the Name Service Switch (NSS). It provides various databases, including those holding user and group information. NSS passes queries on to various associated modules, which then implement the procurement of this information from a specific source such as a local file (think of /etc/passwd) or remote services (like our Active Directory domain). Similarly, Pluggable Authentication Modules (PAM) execute a series of modules to authenticate a user, prepare their session, or change their password. Again, individual modules handle users from different sources, including Active Directory.

User Identities and Authentication via LDAP

Each Active Directory domain controller runs an LDAP server which provides access to the directory’s contents. This allows the NSS and PAM modules (nss_ldap.so and pam_ldap.so respectively) to make the directory’s users available to Linux. Configuration includes adjusting the [ nsswitch.conf file and the PAM configuration, as well as creating the ldap.conf file that defines the properties of the directory.

Some more PAM modules come in handy when authenticating remote users. These modules allow users to authenticate using Kerberos, create a home directory during their login, lock accounts after too many failed login attempts, and enforce a miniimum complexity for new passwords. When experimenting with these modules, remember also to take a look at the chage command, which allows adjustments to the password expiry information for a specific user.

Authentication via SSSD

A modern approach to configuring user databases and authentication in Linux is the System Security Services Daemon (SSSD). SSSD provides NSS and PAM modules as part of the various Linux databases. However, instead of just querying, for example, Active Directory directly, these modules forward queries to the locally running SSSD. The SSSD documentation provides a comprehensive overview of SSSD’s architecture. SSSD itself has a configuration file that defines one or more sources of user information. One of the supported back ends is Active Directory.

Besides just forwarding queries, SSSD provides more features. Upon successful login of a user, SSSD can cache their credentials for a specific time to allow these users to log in again, even when there is no connection to the authentication back end. This is especially useful on mobile devices that might be offline from time to time.

SSSD comes with a set of command line tools. A special feature of these commands is the ability to overwrite specific aspects of user accounts. This feature allows you, for example, to adjust the UID, the path of the home directory, or the login shell for a directory user. These adjustments are injected by the local SSSD and do not affect other computers, even if they query the same directory. SSSD also allows the management of local accounts, which do not even appear in a remote repository.

Accessing SMB File Shares

Once a user is logged in, they usually want to somehow process data. We have already set up a file server which can store data of any kind. The easiest way to connect to an SMB server is the smbclient command. It provides an interactive command line, similar to common FTP or SFTP clients. You should practice the basic operations, such as uploading and downloading single files as well as multiple files, creating directories, and moving files. Take a special look at smbclient’s command-line options, which allow you to enumerate the shares available on a specific server or adjust the SMB protocol used.

Although smbclient is easy to use, it is inconvenient to download each file before using it and to upload it again once it is changed. The mount.cifs command mounts an SMB share into the Linux file system tree. Again, review all of the available mount options.

Keep in mind that each SMB connection is authenticated for one specific user. All operations performed over this connection are executed as the same user on the SMB server, no matter what user performs the change on the client. If multiple users need to access their respective data on the server, each user must mount this data on their own. The pam_mount module triggers the mount of a specific share whenever a user logs in.

Besides smbclient, some more commands interact with SMB shares. The exam objectives explicitly mention smbget, smbtar, smbcquotas, getcifsacl and setfactl, as well as cifsiostat. You should try all of these and, as usual, review their individual options.

Two More Linux Playgrounds

To practise the setup of the various authentication approaches, two additional Linux virtual machines would be helpful. We will need these systems only this week; you can delete them once you’ve completed your experiments. Don’t use the file server for your experiments, as it is already a domain member.

Set up one of the new virtual machines to use nss_ldap.so and pam_ldap.so to allow directory users to sign in. This is also a great chance to get familiar with the most important Kerberos tools, such as kinit and klist. Create a Kerberos configuration, procure a Kerberos ticket for the file server, and confirm that you are able to log into the server using the Kerberos ticket. You could also use this virtual machine to test the various PAM modules and, for example, extend this system’s PAM configuration to mount the user’s home directory from a SMB share upon login.

In the other virtual machine, install SSSD and configure it to recognize Active Directory users. Test the various SSSD commands mentioned in the exam objectives and see how they affect the appearance of the users on the Linux side. Add and modify some users in the Active Directory and see how these changes become available on the two virtual machines. Also test the overwrite features of SSSD and create some local users in SSSD.

Handling Windows Domain Members

Some organizations tend to run Windows on their desktop computers. We have already joined a Windows virtual machine to the domain. After the virtual machine is added, domain users are able to log into it. Using SMB shares is quite easy: after a user enters the UNC path to a share in the Explorer, a connection to the respective server is established and the share is opened.

When a Windows computer joins an Active Directory domain, it becomes subject to several management features of Active Directory. One such feature is logon scripts, which run on the client when a user logs in. Samba can host such logon scripts and instruct Windows clients to execute them.

A more complex approach to Windows management is Group Policy Objects (GPO). This is a complex topic. GPOs can specify a vast amount of properties of Windows systems. You can use various criteria to define whether a GPO applies to a specific computer or a specific user. Microsoft provides a Group Policy for Beginners guide, which is a good first step into GPOs.

Samba Active Directory controllers can host GPOs. GPOs are stored on the SYSVOL share, which is replicated between the domain controllers. In the case of Samba, this replication could be unidirectional from the domain controller holding the PDC emulator FSMO role. In this case, make sure to run the GPO Management utility against that specific server.

To learn more about GPOs, try to define a GPO that mounts a CIFS share and another GPO that restricts access to the Control Panel. Try to assign these GPOs to some of your users and confirm that they are effective after logging into the Windows client as the respective users. Take some time to review the various options and become familiar with the handling of GPOs.

For each user, Windows creates a profile that stores configuration information as well as files, such as those placed on the user’s desktop. When a user uses multiple computers, it is beneficial to make sure all computers access the same profile. The Samba wiki explains how to configure the necessary profile folder redirections.

One More Step to Take

Today, we have learned a lot about the configuration of Samba clients. As usual, don’t forget to review the exam objectives and take a look at the aspects that weren’t explicitly mentioned in this post.

The next post in this series will complete the preparations for the LPIC-3 Mixed Environments exam. We will see how we can use FreeIPA to create a domain that allows the centralized management of Linux authentication clients and how to set up that domain to coexist with Active Directory. We will also review the NFS protocol, which is an alternative to SMB, especially when serving files to clients running an operating system other than Windows.
 

<< Read the previous post of this series | Read the next post of this series >>