Active Directory authentication for Linux

651

Linux has the capability to use a centralized authentication system ( LDAP). This article explains by example how to configure the authentication settings for Linux to use Active Directory authentication instead of the local password file. Thus, gives you the ability to manage users from like Active directory.

Contents.

• prepare the Linux machine.

Assumptions

You already have a network managed by Active directory 192.168.2.10. furthermore, the you have a local DNS.

Step1 : prepare the machine

There are few packages that are required for CentOS 8 / RHEL 8 to be integrated with Active Directory. Firstly, Install them on your system by running the following commands:

dnf install realmd sssd oddjob oddjob-mkhomedir adcli samba-common samba-common-tools krb5-workstation authselect-compat -y

Then, make sure that your CentOS/RHEL 8 machine can resolve and discover AD domain.

cat /etc/resolv.conf

In my example, it should have the IP of my local DNS server 192.168.2.10. After that, check if AD domain discovery is successful.

realm  discover cloudadminclub.local

Step2 : join AD

Next, make sure you have privileged username and password. Then, run the following command to allow your machine to join the Active Directory domain.

realm join cloudadminclub.local -U adminUsername

Confirm that the join was successful.

sudo realm list

Once the machine is joined, run the commands below. It will update the authentication mechanism to validate from AD instead of local files.

authselect select sssd
authselect select sssd with-mkhomedir

Your sssd.conf configuration file should look like below,

$ cat /etc/sssd/sssd.conf 

[sssd]
domains = gust.local config_file_version = 2 services = nss, pam default_domain_suffix = gust.local

[nss]
homedir_substring = /home

[pam]

[domain/cloudadminclub.local]
ad_domain = cloudadminclub.local
krb5_realm = CLOUDADMINCLUB.LOCAL
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 = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = ad

When a change is made in the config file, a service restart is required.

systemctl restart sssd

Status should be running.

If the integration is working, it should be possible to get AD user info.

Step 3: Access Control – to allow users/groups

As soon you joined the AD. Access to the machine became limited to allowed users only specific users/ and groups.

except for any sessions already active

Permit user by name

To permit a user or multiple users to access via SSH and console, use the command:

$ realm permit [email protected]
$ realm permit [email protected] [email protected]

Permit access to Active directory group – Examples

$ realm permit -g sysadmins
$ realm permit -g 'Security Users'

These commands will affect and modify sssd.conf file. So, you need to restart the service again.

Step 4: Configure Sudo Access

By default, the domain users won’t have permission to escalate their privilege to root. Users have to be granted access based on usernames or groups.

Let’s first create sudo permissions grants file.

$ sudo vi /etc/sudoers.d/domain_admins

Add single user:

[email protected]        ALL=(ALL)       ALL

or Add multiple users :

[email protected]     ALL=(ALL)   ALL
[email protected]     ALL=(ALL)   ALL

Adding a group is easy as users, however, I didn’t test it, as i prefer to assign access by user

%[email protected]     ALL=(ALL)   ALL

Finally, update the SSH service to allow authentication from the active directory. make sure the /etc/ssh/sshd_confing contains the following

#Allow Authentication using password
PasswordAuthentication yes

# To allow a Group Enable the following line
#AllowGroups "adGroup1"

# Kerberos options
KerberosAuthentication yes
KerberosTicketCleanup yes   

# GSSAPI options
GSSAPIAuthentication yes

UsePAM yes

Finally, restart the ssh service to activate the changes.

systemctl restart sshd

Conclusion

The machine should be ready and accessible using active Directory passwords. You can easily test within the same session using the following ssh example to test the connectivity of coolUsername.

ssh coolUsername@localhost

,