Linux Authentication with Active Directory

Active Directory allows easy and secure management of directory Objects from a centralized and scalable database. The objects such as users, groups, systems and many others are stored in a hierarchy.

I would simply say Active Directory (AD) is a Directory Service that uses customized version of the standard protocols that is also available in Linux system such as:

  • Lightweight Directory Access Protocol (LDAP)
  • Kerberos

Lightweight Directory Access Protocol (LDAP)

In a very simple terms, it is a set of open protocols which is used to access centrally stored information over a network. So it is a protocol (language) that enable a service (client, server,..) to talk to another service (client, server,..), as simple as this.

But when we are talking about LDAP server, we mean a central place that store some entities which are usually Username/Password and it allows others (applications, services,..) to connect to it using LDAP protocol. So basically as soon as others speak the same language as us (ldap), we can communicate with them. The main benefit of Ldap server is easy management of Username/Passwords in central location. I would simply say LDAP server is a Directory Service.

As you have noticed, I used Directory Service terms for both AD and Ldap server. But what is the difference between them. Very simple, AD is Directory service that is a proprietary of Microsoft and support several standard protocols such as LDAP & Kerberos. So if we want to talk with AD, we can use LDAP protocol from Linux machines (Ldap version 3).


There are lots of confusion out there regarding this part in AD and LDAP server. Let’s consider simply a Directory Service which stores lots of Username/Passwords. So if we are managing this directory, we can decide how to let other users to authenticate against this Directory and based on that define a protocol (language) for talking. As an example, we can say there is no need for any specific protocol and only send Username/Password (clear text) through the line (Network) and authenticate. Or as another example, we can define a protocol such as Kerberos, SSL/TLS and any other for this purpose.


This is a network-based authentication protocol which is freely available. Many Directory services such as Active Directory from Microsoft adopt it as a default authentication protocol. So this means if we want to authenticate from a Linux machine to AD, we can use kerberos for authentication.

Authorization information

Another important point after successful authentication with Active Directory is authorization information. As an example, User X is a member of which groups and have what kind of access permission in different directories, files,… These kind of information is managed completely different in Windows environments and Linux environments. In windows we have a concept which is called SID (windows security identifiers) and in Linux we have UID/GID concept. But what is important for us is the Identity Mapping of SIDs to UIDs/GIDs. But Why?

The reason is quite simple. Let’s consider a scenario that we have a Shared Storage between Linux and Windows environment and have a lots of Access List rules in place on different files and different directories. Same rules have to be in place no matter a user comes from Windows environment or Linux environment.

There are 2 ways for ID mapping between AD and Linux using sssd:

a. Using sssd deamon to create may between SIDs in AD and uid/gid in Linux server. It requires no further configuration on AD. For this purpose we put following line in sssd.conf file:

  • ldap_id_mapping = True

b. Using POSIX attribute. We need to configure for each user in AD the given uid/gid numbers, unixhomedir and loginshell which helps to have a great control over the specific uid/gid values, specially when we have several domains. In this case we write following in sssd.conf:

  • ldap_id_mapping = False

It is important to notice that POSIX attributes are stored in the local domain. And if we want to use it through sssd for identity information, we need to replicate them to global catalog.

Explanation: Linux/Unix systems use a local user ID number (UID) and group ID number (GID) to identify users on the system. These numbers are simply integeres like 1000:1200. But in windows area we have SID which is constructed of different segments that identify security version, the machine, the issuing authority type and etc.

Linux Authentication

Before moving to our solution for authentication with AD, let’s understand some concepts. Originally there was not any built-in single mechanism for authentication in Linux and as a result different people handle this differently such as using /etc/passwd file. Eventually a mechanism proposed called Pluggable Authentication Modules (PAM) which provides a set of APIs that can be used for authentication. So basically by using PAM, we can completely customize the authentication. As an example, we can configure it to look up password (authenticate) in Ldap server (local or remote server).

In parallel there is another entity which is useful to know (nothing to do with authentication), called Name Server Switch (NSS). It is a file which is located usually at /etc/nsswitch.conf and can be configured to resolve different type of names (name resolution mechanism). So here we can configure to tell the system that what services is needed to be used for this purpose. The names can be usernames, group names, passwords or whatever (such as /etc/passwd, /etc/group, and /etc/hosts), the DNS, the NIS, and Ldap.

No matter what solution you use for authentication with AD, usually PAM API for authentication and NSS for loading user information (such as UID/GID) is being used at the back-end in Linux side.


There are practically 3 ways of integrating Linux with AD for Authentication

1. Using LDAP/Kerberos PAM and NSS modules

Here PAM is being configured to use Kerberos for authentication and NSS is configured to use LDAP protocol for querying User/Group information (uid, gid). So we should have nss_ldap, pam_ldap, and pam_krb5 modules. Problems associated with this way:

  • no cashing of the credentials
  • no offline supports

2. Using Winbind

Samba Winbind had been a traditional way of connecting Linux systems to AD. Winbind emulates a Windows client on a Linux system and is able to communicate to AD servers. So basically here we have winbind daemon that will receive calls from PAM and NSS, and it will translate them into corresponding Active Directory calls using either LDAP, Kerberos, or RPC depending on which is the most appropriate. I have seen lots of problem with this solution, specially it is very slow and I discourage people from using it.


3. System Security Services Daemon (SSSD)

sssd is a service which plays the role of Bridge. So basically it connects local system/applications to (usually remote) Directory Service (such as AD, Ldap server, IdM,..). So sssd can provide access to a Directory Service for authentication purpose and plus retrieve some information back (usually uid,gid) and create a local cache of those data.


RedHat documentation defines SSSD like this:

“SSSD configures a way to connect to an identity store to retrieve authentication information and then uses that to create a local cache of users and credentials. SSSD can also pull in group information. Authorization information is gathered by SSSD by using host-based access control (HBAC) in IdM and group policy object (GPO) settings in AD.”

The main advantages of using sssd includes:

  • create local cache of credentials that allow a local service to authenticate locally
  • authenticate/provide info even if Directory service is offline due to local cache
  • Decrease the load on Directory Service

sssd daemon provides lots of different services for different purposes. As a result, we have a configuration file called sssd.conf which determine the tasks sssd needs to do. The file has 2 main parts as we can see here:

domains = WIN.EXAMPLE.COM 
services = nss, pam
config_file_version = 2

id_provider = ad
auth_provider = ad
access_provider = ad

The first part [sssd] defines which services on the system must use sssd. Here we put nss and pam. The second part [domain/Windows] defines the Directory Service (also called Identity provider such as AD, Ldap server,…) which sssd needs to connect for different purposes such as querying the information, authentication, password changes and many others. By default, only the identity provider (id_provider) and authorization provider (access_provider) options need to be configured. The id_provider option is used for the authentication (auth_provider) and password provider (chpass_provider) options if no other types or servers are set.

So in short the sssd.conf configure:

  • configures the SSSD service ([sssd])
  • configures the identity domains ([domain/NAME])
  • Optionally might be additional sections that configure system services which use SSSD as an identity cache; for example [nss] or [pam].

As we explaned before, we need someone/something convert the AD style users identity to Linux type (uid/gid). The easiest way is to use sssd for this id mapping between AD and Linux system.

Based on what I described, my focus here is on using 3th solution (sssd) for authentication with AD.


Using SSSD for Integrating with Active Directory

From my point of view the windows Domain Controller is simply a Kerberos/LDAP server. However, there are few things need to be done in Domain Controller side:

a. Make sure that DNS is working properly – both forward and reverse lookups.

b. Time synchronization. NTP should work properly, otherwise kerberos will fail. It is usually the case that people configure AD to host NTP server as well and Linux systems also sync with it.

c. The AD needs to be configured to include the relevant info for Linux systems, mainly UID/GID, login shell (/bin/bash, /bin/sh,…) and home directory. For this purpose, we need to add the role service “Identity Management” for Linux.

Now let’s go to Linux side and configure that part. Since Redhat 7 series some new features has been added that simplify the process of configuring the SSSD. I will explain first the automatic way and then manual way and afterward how to do it for group of computer (compute nodes in Cluster).

RedHat 7.2 (Centos 7.2) Automatic SSSD configuration

1. Make sure DNS and NTP is working properly in both AD and our centos 7.2 server and both can resolve the name of each other.

If the name of external domain is different from internal domain (maybe have a cluster here9, then we need to add the name of external domain also in /etc/hosts of the server: hrz-master hrz-master.hpc.cluster

2. We need to add DC name and IP to /etc/resolve.con file

  • search
  • nameserver

3. There is a new tool in Redhat 7 series called ‘realmd’ which can automatically configure initial SSSD and related/needed packages for us. I will use it here for the configuration.

We need to make sure it has been already being installed, otherwise can simply install it.

  • root@hrz ~ # yum list installed | grep -i realmd
  • realmd.x86_64 0.14.6-6.el7

4. Discovery process: There is a command called ‘realm discover’ that can return complete domain configuration and a list of packages that must be installed for our Linux server.

root@hrz ~ # realm discover

  • type: kerberos
  • realm-name: AD.HRZ.COM
  • domain-name:
  • configured: no
  • server-software: active-directory
  • client-software: sssd
  • required-package: oddjob
  • required-package: oddjob-mkhomedir
  • required-package: sssd
  • required-package: adcli
  • required-package: samba-common

As we can see, the domain still has not configured (configured: no) and also we see the packages that need to be installed.

  • yum install oddjob oddjob-mkhomedir sssd adcli samba-common

5. Joining to the domain which can use ‘realm join DomainName ‘ command. By default the command join use administrator account. However we can have a control over it with using -U option. It will prompt for user password (if needed) that after successful entering, we will join. Similar to windows environment, after successful joining, the name of the Server will be created automatically in Active directory.

realm join (will use administrator as default account)

or :

realm join -U ‘\UserAccount’

to be sure that we have joined, we can use again the discovery command.

root@hrz ~ # realm discover

now we should see ‘configured: ‘kerberos-member’

6. Allow login access to our Linux server to all users in AD domain

root@hrz ~ #realm permit –realm –all

This should change sshd_config file, otherwise we do manually

  • root@hrz ~ # vim /etc/ssh/sshd_config
  • #Kerberos options
  • KerberosAuthentication yes
  • KerberosOrLocalPasswd yes
  • KerberosTicketCleanup yes
  • KerberosGetAFSToken no
  • KerberosUseKuserok yes
  • # GSSAPI options
  • GSSAPIAuthentication yes
  • GSSAPICleanupCredentials yes

and then simply restart the sshd daemon as wel as sssd.

At the end I noticed that the range of uid/gid that we have is very big and not appropriate for our purpose.

[root@hrz-master ~]# getent passwd tom
tom:*:22074787:151367473:Aaron tom:/home/tom:/bin/tcsh

Also I noticed that Credential didn’t cached internally. So I changed the default sssd.conf file which has been created for us and added following lines:

  • cache_credentials = True
  • enumerate = true

And I also changed the id mapping strategy from Ldap id mapping to AD id mapping with POSIX. So I also added:

  • ldap_id_mapping = False

Important:  each time we change something specially in sssd.conf file, we need to flush the cashing of databases before restarting the sssd service. For this purpose we remove everything from this directory: /var/lib/sss/db , simply by using rm -rf *.*


RedHat 7.2 (Centos 7.2) Manuall SSSD configuration

1. Make sure DNS and NTP is working properly in both AD and our centos 7.2 server.

2. We need to add DC name and IP to /etc/resolve.con file


  • search
  • nameserver


3. Install following package to allow sssd create automatically home directory for users

yum install oddjob oddjob-mkhomdir

enable the service to start on boot (oddjobd).

4. Configuring Kerberos: basically the Linux server will be the AD client and need to register with AD domain, therefore we need to configure kerberos and samba.

The kerberos client configuration file is located in /etc/krb5.conf

root@hrz ~ # vim /etc/krb5.conf

default = FILE:/var/log/krb5libs.log

default_realm = HROUHANI.ORG
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
rdns = false
forwardable = yes

kdc = (DC IP address)
admin_server =

[domain_realm] = HROUHANI.ORG = HROUHANI.ORG

5. Configure samba server to connect to AD

we need to change the [global] part in /etc/samba/smb.conf file.

workgroup = HROUHANI
client signing = yes
client use spnego = yes
kerberos method = secrets and keytab
log file = /var/log/samba/%m.log
password server = AD.HROUHANI.ORG
security = ads

we assume that our Domain Controller is also Kerberos server, otherwise if we have a separate kerberos server, we can set the password server the IP or name of the kerberos server.

Explanation: samba is a free open-source tool that allows for communication between windows and Linux systems. So basically it is a daemon that run on non-windows systems and uses TCP/IP protocol for interacting with windows server/clients as it is a windows server/client.

6. Adding the Linux Server to AD domain

a. we need first get the kerberos credentials for Windows domain Administrator (by default is Administrator account)

root@hrz ~ # kinit Administrator (or kinit

Explanation: The kinit command is a Kerberos initialization script that references the Active Directory administrator account and Kerberos realm. Since Active Directory requires Kerberos tickets, kinit obtains and caches a Kerberos ticket-granting ticket for client/server authentication.

b. Adding the Linux Server Machine to the domain

root@hrz ~ # net ads join -k

Explanation: the net command connects to the Active Directory server using its required administrator account and password. This creates the appropriate machine account on the Active Directory and grants permissions to the Samba domain member server to join the domain

c. Make sure that the host priciple key in already here:

klist -k

7. In order to tell the system that use sssd for authentication, we can use authoconfig and beside also enable sssd to create home directory for us.

root@hrz ~ # authconfig –update –enablesssd –enablesssdauth –enablemkhomedir

This will automatically change the /etc/nsswitch.conf for us. There are some parts in the file that sss has been written and that means use sssd for that purpose, like this:

  • passwd: files sss
  • shadow: files sss
  • group: files sss


Important: If we modify the nsswitch.conf file manually, then there is no need for using authconfig command as shown in above.

8. Modify the /etc/sssd.conf file:

config_file_version = 2
domains =
services = nss, pam, pac
id_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = ad
cache_credentials = true

pac: this enables SSSD to set and use MS-PAC information on tickets used to communicate with the Active Directory domain.

ad: means active directory

cache_credentials: this make a cache of credential which enable users to log into the local system using cached information (even if DC is off)

9. We need to restart the ssh service and sssd service. Restarting the sssd service helps to load the new PAM configuration.

systemctl restart sshd.service
systemctl restart sssd.service


RedHat 7.2 (Centos 7.2) Manual SSSD configuration for Compute nodes (let’s consider compute nodes image)

Consider the stateless cluster that we implemented with xCAT. The target is to have same uid/gid that we have in Master node (using manual or automatic sssd) in all compute nodes. Obviously we have to change the compute image and reboot all of them. As soon as sssd come up, we should be able to have all Active Directory credentials locally cached.

1. I assume that all compute nodes have access to Domain Controller/Kerberos server whether directly or through Master node.

2.  First we copy the kerberos ticket from Master node to compute image.

cp  /etc/krb5.keytab   /install/netboot/centos7.2/x86_64/compute/rootimg/etc/krb5.keytab

3. Also the kerberos config file need to be copied.

cp /etc/krb5.conf /install/netboot/centos7.2/x86_64/compute/rootimg/etc/krb5.conf

[root@hrz-master ~]# cat /etc/krb5.conf
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

 dns_lookup_realm = true
 dns_lookup_kdc = true
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 rdns = false
 default_realm = HROUHANI.ORG
 default_ccache_name = KEYRING:persistent:%{uid}

kdc =
admin_server =

4. We copy the the samba config file:

cp /etc/samba/smb.conf /install/netboot/centos7.2/x86_64/compute/rootimg/etc/samba/smb.conf

The main parts are following in the config file

workgroup = HROUHANI.ORG
client signing = yes
client use spnego = yes
kerberos method = secrets and keytab
log file = /var/log/samba/%m.log
password server =
security = ads
server string = Samba Server Version %v

5. Also the sssd.conf file

cp /etc/sssd.conf /install/netboot/centos7.2/x86_64/compute/rootimg/etc/sssd.conf

domains = q.intern
config_file_version = 2
services = nss, pam, pac

#filter_groups = root
#filter_users = root
reconnection_retries = 3
entry_cache_timeout = 300
entry_cache_nowait_percentage = 75

ad_domain =
auth_provider = ad
chpass_provider = ad
krb5_realm = HROUHANI.ORG
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = False
use_fully_qualified_names = False
fallback_homedir = /home/%u@%d
access_provider = ad
entry_cache_timeout = 5400
enumerate = true
You have new mail in /var/spool/mail/root

6. And also the nsswitch.conf file.

passwd:     files sss
shadow:     files sss
group:      files sss
hosts:      files dns
bootparams: nisplus [NOTFOUND=return] files

ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files sss

netgroup:   files sss

publickey:  nisplus

automount:  files sss
aliases:    files nisplus







%d bloggers like this: