Authenticating Active directory Users to a Linux Client

1.1        Introduction

Linux and Windows has always been separated environment from each other and rarely any interopretability was seen. Now a days as IT field grows rapidly, you got better chance if your company users more effective technologies and share the infrastructure which in turn become cost effective.
Our approach was to use the Active Directory Authentication for login in to a Linux client rather than using a separate directory service for Linux. Main reason for this was as most of the leading companies Srilankan Airlines use the Active Directory environment for authenticating their users. If we use two separate directory services, for Linux and Windows it become hard to manage and the user would have two identities on the network.

1.2        Authentication techniques in Linux and Windows

Before going for the integrated authentication, we consider the authentication used by each operating system. In Windows, users are authenticated to the network with Active Directory, which is a basic role that comes with the Windows server. Active Directory uses Kerberos for authentication and gives the user a single sign-on for services. Also, provide one directory service that can be used for many services and applications.
Linux on the other hand has less concern about single sign-on. Linux uses PAM and NSS for authentication. PAM gives modules for applications to authenticate users. NSS keeps the user information. Administrator could configure the PAM modules been used. PAM has included modules for using LDAP and Kerberos for authentication.
What we have to do is integrate these two authentication techniques so that AD user could log on to Linux client. Here available options were considered on hoe to integrate them. We can use LDAP or Kerberos for this or use Samba Winbind like middle ware. Then how these were implemented and what we get with each of them was considered.

1.2.1        Using LDAP for authentication

PAM and NSS should be configured to use LDAP for authentication. Although LDAP is the easiest way to go it has many fallbacks too. First LDAP send password username in clear text over the network. This can create many security problems. AD is LDAP service but it does not use LDAP for authentication. It uses Kerberos. You may use SSH for encrypting data but this adds more work to the administrator like managing the SSH certificates. In addition, LDAP is not capable of changing expired password.

1.2.2 Using Kerberos and LDAP for authentication

Figure 1: Using LDAP for Authentication

Figure 2: Using Kerberos and LDAP for Authentication

More secure and easy way is to configure PAM to use Kerberos for authentication and NSS to use LDAP for looking up user usernames and passwords. There are some drawbacks here also, like one DC that is been named before and not allowing to reset expired passwords.

1.2.3        Using Samba Winbind for Authentication

Winbind is a component that comes with Samba, which is an open source project provides the communication between AD and Linux. Samba is mainly used for sharing resources between Windows and Linux Environments.
It acts as a proxy and translates the NSS and PAM requests into relevant AD call using Kerberos LDAP, or RPC. Winbind uses Kerberos for authentication and LDAP for getting user credentials. It also provides locating of DC’s in the network, allowing authentication through any available DC. This increases reliability. It can reset the passwords communicating through RPC calls with AD. PAM and NSS will be configured to use Winbind for authentication.
We chose the Winbind as our strategy for this project.

Figure 3: Using Winbind for Authentication

1.3        Preparation

What we needed for this was listed as follows,

• Windows Active Directory with Users
• Linux Client
• Samba Winbind on Linux Client

We went through them one at a time. First, we need the Windows Active Directory where the user accounts are stored. We had a Windows Server 2008 that runs as DC, which was prepared by us for our other project. In that Active Directory, test group and test users were created for Linux Integration. Our Active Directory Domain was ‘SLA.COM’, and the Domain Controller is ‘SLADC2008’. This was assigned the static IP address 192.168.10.5.
Then the Linux client was prepared. RHEL5 was the Linux distribution available for us. RHEL5 was installed on another server. This is the latest Linux version available in most datacenters. Our Linux client hostname is ‘IT0006368Linux’.It was assigned the IP address 192.168.10.10.
Samba version that comes in the RHEL5 is Samba-3.0.25. However, we need newer version for this integration, because this is supported by Samba-3.0.28 or higher version only. Then we either have to update the samba version or could download and install the appropriate Samba version. As we need a login to update or download packages for RHEL5 from RH Linux website, and it was decided to download the Fedora Core packages that had the same base sources. Dependencies for Samba were downloaded as well.
Samba was not installed as we install RHEL5 as it may conflict with updates we install, that may result in failure of integration process. Samba (src.rpm) Source rpm was downloaded and Samba rpms were built. There were Samba rpms to download but by default, options needed for integration were not included in them. You should always be aware to select the correct Linux distribution and CPU architecture (bit version) matches your system.

1.4        Step by Step

1.4.1        Building Samba Source

Samba 3.0.31-0.fc8.src.rpm was downloaded from the internet. A source file contain original source of the package. This can be installed and build options can be configured by our self. Then they can be linked and compiled to get binary files we want.
Downloaded samba source was placed in the “/usr/src/redhat/SRPMS” directory. It was installed by running the following command in terminal, “rpm -i /usr/src/redhat/SRPMS/samba-3.0.31-0.fc8.src.rpm”. ‘SAMBA.SPEC’ file was checked in the directory ‘/usr/src/redhat/SPECS’ for the option of ‘Id mapping’. SAMBA.SPEC is file where build options are defined. There should be a line saying “–with-shared-module = idmap_ad, idmap_rid” that come under “CFLAGS=”. Including this option in spec file, enable mapping between Linux UID and windows Active Directory.
To build Samba the libraries and utilities (dependencies) were updated because we are using newer version of Samba than that comes with the operating system. Following packages were updated.

• gnutls1.6.3-3.fc7.i386                    GNU Transport Layer Security (TLS) libraries
• gnutils-devel-1.6.3-3.fc7.i386        GNU TLS development files
• popt-1.12-3.fc8.i386                       Command-line argument parsing libraries
• popt-devel-1.12-3.fc8.i386             Command-line argument parsing development files
• cups-libs-1.2.12-11.fc7.i386           Common UNIX Printer System libraries
• cups-devel-1.2.12-11.fc7.i386        Common UNIX Printer System development files
• cups-1.2.12.11.fc7.i386                  Common UNIX Printer System binaries

RPM binaries of these packages were downloaded and installed with Redhat package manager or RPM. “rpm –install –force Package_Name” was the command used. To install packages with their dependencies YUM was also used. To use it local repository was created. First ‘createrepo’ package was installed in the machine. All the RPM packages were copied in to a local directory (Ex: /home/admin/local_repo). Local repository was created with the command “createrepo /home/admin/local_repo”. Directory called ‘repodata’ will be created inside local_repo. Entry was put in to the ‘/etc/yum.conf’ as follows
[local]
name = local
baseurl = file:///home/admin/local_repo
enable = 1
gpg check = 1
Now if the dependency packages are available in the local_repo they will be installed as required. (Ex: yum install package_name)
Samba rpms were then built entering the command “rpmbuild –bb /usr/src/redhat/SPECS/samba.spec” in the terminal. The rpms were created in the directory ‘/usr/scr/redhat/RPMS’.

1.4.2        Installing Samba

Many Samba binaries were created in the RPMS directory, but only samba, samba-common and samba-client were installed with “rpm –install” command.

• samba-3.0.31-0.i386.rpm
• samba-common-3.0.31-0.i386.rpm
• samba-client-3.0.31-0.i386.rpm

Now all the required packages were installed. Then the system should be configured according to our requirement.

1.4.3 Configuring network settings on Linux client

Figure 4: Configuring the Network Card

Networking configurations allow the communication between DC and Linux client. Three categories were configured the network adaptor, DNS settings and host names. They configured though the Network Configuration console that is on the System>Administration menu.
In the Device tab IP address was given. You may set it to get an IP address dynamically if a DHCP server is available on the network. ‘192.168.10.10’ was the IP address assigned. Then on the DNS tab DNS name server that AD DC use was given here. As we were using ‘Active Directory’ integrated DNS server it is same as the AD DC. In hostname field, ‘IT0006368Linux.sla.com’ was entered. In the ‘Primary DNS’ field, ‘192.168.10.5’ was entered as the IP address of the DNS server.
Finally, in the Hosts tab an entry was put for the Linux client. Entry may directly enter to the /etc/hosts file. It is more reliable because failure to do so will create incorrect computer object in the Active Directory when you join the Linux client.

1.4.4        Synchronizing the time on Linux client

Synchronizing the time on Linux system with the DC would be important as were using Kerberos authentication. Kerberos uses timestamps so the difference in the time in two systems may fail the authentication. This was acquired by setting AD DC as NTP server. In the Date and Time utility in the System>Administration menu IP address of the AD DC is entered. Network Time protocol box was checked.

Figure 5: Configuring NTP

1.4.5        Configuring PAM and NSS

PAM and NSS are used in Linux to authenticate users. PAM provides authentication facilities for application that uses it. We need to use Winbind for authentication. So PAM was configured to use wind bind for authentication then the application using PAM for authentication will use Winbind.
In /etc/pam.d directory, a text file is kept for every application that uses PAM. There the authentication process for each application was defined. These files contain four types of authenticating facilities or management groups. Authentication or auth is the first type that let the application determines which user can use it. The Account facility provides account management facilities. Password facility provide password management and session facility tear down the task for the application.
The format of a PAM file will be <management group> <control keyword> <shared module> <module parameters>. Management groups are auth, account, password and session. Control keywords are required, requisite, sufficient, optional and include. These describe how module should do the evaluation Modules are dynamically loadable executable codes that do the evaluating of entries under that management group.
Required keyword     If succeed continue evaluating and result depend on other modules. If fails, continue the evaluation and return failure to the application
Requisite keyword     If succeed continue evaluation
If fails end evaluating return failure to the application
Sufficient keyword    If succeed end the evaluation return success to the application
If fails continue evaluation, result depend on other modules
Optional keyword      Ignore the result if no other module for the management group
Include keyword        Include referenced PAM configurations.
System-auth file was included in every PAM file. This provides the default authentication behavior for PAM.
NSS allow the system administrators to decide how system database are stored. In addition, hides the specifics of data storage from application developer. We configure NSS to use Active Directory for looking up user information that applications require.
We use the graphical applet provided by RHEL5 ‘Authentication Configuration’ in System Administration menu. ‘System-auth’ and ‘nss.conf’ were configured through this applet. However, some changes were directly made to the system-auth file.
In the user information authentication tabs in this applet, Winbind is checked and configured as follows.
Winbind Domain is the domain that we want user are in and Winbind ADS Realm is DNS name of the Active Directory Domain. Keeping the Domain Controller field as ‘*’ will make Winbind to locate the DC.
Every Linux user has home folder that user specific information used by the system. However, as our users are created in the Active Directory they do not have a home directory in Linux. Therefore, we an entry was put in the system-auth file configuring Pam to make a home directory for the user when he login to the system if he does not have one. In /etc/pam.d/system-auth “session optional pam_mkhomedir.so skel=/etc/skel umask=0644″ this line says make a home directory if does not have on using /etc/skel as template assigning the permission level 0644.

1.4.6        Configuring Samba and Winbind

Configurations of Samba are kept in /etc/samba/smb.conf file. There the security model is set to ‘ads’ making samba use Active Directory for authentication. “security = ads”. Then to map the user ID’s in Linux with user ID’s in active directory another entry was put in the smb.conf file. That is in the global tag “idmap backend = rid for single domain and “idmap backend = ad” for multi domain Active Directory.

Figure 6: Configuring Winbind

Within a Linux or Windows, users are not identified by their usernames but from unique identifiers. In Linux, system 32-bit integer called UID is used. It is unique within the local system only. Therefore, Linux administrators use NIS (network Information System) or share LDAP library to identify users in network. Otherwise, same UID in two Linux machine s will not be the same user.
In Windows, it uses 128-bit integer called SID (Security Identifier). This uniquely identifies a user within the Active Directory forest. In addition, another called RID (Relative Identifier) uniquely identifies a user within the Active Directory Domain. It is also a 32-bit number.
So in order to identify a user uniquely from both of the systems these ID’s should be mapped with other system. We used rid mapping because we had a single AD domain and there is no configuration to be done in the Active Directory. There RID is directly taken as the UID in Linux. However, if you have multi domain ad mapping must be used. There a user ID should be uniquely defined in the forest group ID’s are set to groups. These attribute are available in AD services for UNIX.

Figure 7: RID mapping and SID mapping

Where to make the home directory and how to name it of the user was configured in the smb.conf file by putting an entry as “template homedir = /home/%D/%U”. This says to create home directory like /home/domain_name/user_name.

1.4.7        Joining the Linux client

As all the configurations are been made now the Linux machine was joined with the Active Directory domain. Command “net ads join –U <administrator>” was entered in the terminal. An administrator account name should be entered to <administrator>. Then it was prompted for the administrator’s password. It was indicated that Linux client was successfully joined with the Active Directory.
The trust between Linux client and AD domain was checked by the command “wbinfo –t”. AD users and groups were listed by entering “wbinfo -u” and “wbinfo -g” to check whether the Linux client could see all the user account and groups in AD.
As everything was working correctly you machine was restarted login with an AD user account. We were able to login successfully.

Figure 18: Testing the Trust

Figure 8: Testing the Trust

1.5        Advantages and disadvantages

Integrating Linux with Active Directory we were able to manage all the user accounts with centralize database. There will not be multiple identities for the same user in the network. Users do not have to remember different user names and passwords. This provides better security than NIS or LDAP. This solution is free and all source codes are available to us so we can make it to our requirement.
On the other hand, there is not any official support available for integration of Linux with Active Directory. Forums are there to help you but that depend on who read your post. Also with Winbind, you cannot apply Group Policies and there are not any tools available to migrating existing users to Active Directory. To overcome these drawbacks there are commercial solutions available (Likewise, Centrify, Quest and Symark). They have tools for migrating and applying Group Policies. However, if you are looking free solution Winbind is the way to go.

1.6        Problems encountered and overcome them

Samba 3.0.25 was installed by us when we installed RHEL5, as it is samba version available in the DVD. However, when we try joining the Linux client with Active Directory after configuring everything it failed. We found out that this Active Directory integration is only supported by samba versions higher than 3.0.28. We decided to go with samba 3.0.31.
Installing newer version conflicted with the existing version giving RPC failures. Therefore, we had to remove the older version. Nevertheless, with it some dependents were removed. Installing them again and depending libraries and utilities for newer version was very difficult as there were many dependencies. So installed YUM and created a local repository with all rpms that will ease our work.

Prepared By : W.P.A.S. Perera (Shan Perera)