Integrating a Linux server into an Active Directory

2023-03-28 2234 words 11 minutes

Contents

Introduction

A few months ago, I was given the task of integrating all Linux VMs (RHEL8) into a domain managed by two Active Directories. This may be an aberration for some, but it provides a common and secure authentication between Linux and Windows for all system administrators. I’m writing these few lines because I couldn’t find any working documentation at the time and I’m sure the subject will be of interest to many people.

Prerequisites

This procedure has not been tested only on Red Hat 7 & 8.
Your Active Directory has already been installed and configured.
You have a DNS and NTP server configured and operational.
Your Linux machine has already been installed.
You are able to install several packages.
You understand how Kerberos works, because I won’t go into that again in this article.

If these prerequisites have been met, you can start the procedure!

1 Installing the necessary packages

To integrate your Linux machines into an Active Directory, you will need 3 packages:

SSSD (System Security Services Daemon) is a service daemon that provides authentication, authorisation and name resolution for Linux and Unix systems using external data sources such as LDAP, Kerberos or Active Directory (AD) servers. SSSD provides centralised identity management for users and groups, as well as network connection management for clients.
Samba is a software suite for sharing files, printers and other resources between Windows and Linux/Unix computers. Samba can also function as a domain controller to manage users and computers in a Windows environment, as well as integrating authentication and authorisation with Active Directory. Samba is often used to provide file and print services over heterogeneous networks.
Oddjob is a service that provides security infrastructure services for Linux systems. Oddjob manages encryption keys, certificates and certification authorities (CAs) for Linux clients, as well as password management tasks and disk encryption access. Oddjob can also provide user and group account management services.
krb5 (Kerberos version 5) is security software that provides strong authentication for applications and services in a corporate network environment. Kerberos is an authentication and encryption key management protocol that allows users to authenticate once and access multiple services without having to provide their credentials each time.

To install the packages, you can run the following command:

yum install sssd samba oddjob-mkhomedir.x86_64 krb5-workstation krb5-libs

2.DNS check

Next you need to modify the /etc/resolv.conf file by adding your domain and your DNS servers.

As a reminder: “The /etc/resolv.conf file is a text file that stores the addresses of the system’s DNS servers."

Your file should look like this:

search  domain.local
nameserver      A.B.C.D
nameserver      A.B.C.D

The search field will allow you to search for a host in your automatic domain. Instead of ping myhost.domain.local you can simply ping myhost.

3.Kerberos configuration

Next, you need to configure krb5. This config file will contain the client configuration information needed to communicate with the master Kerberos server (our AD). To be on the safe side, you can copy the original file using the command below, to recover the contents in the event of an error.

cp -p /etc/krb5.conf /etc/krb5.conf.orig

Next you will edit the /etc/krb5.conf file so that it has the following configuration:

vim /etc/krb5.conf

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
default_realm = DOMAIN.LOCAL # <!> A remplacer par votre domaine.
default_ccache_name = KEYRING:persistent:%{uid}

[realms]
# EXAMPLE.COM = {
#  kdc = kerberos.example.com
#  admin_server = kerberos.example.com
# }

[domain_realm]
# .example.com = EXAMPLE.COM
# example.com = EXAMPLE.COM

I’m not going to go through each of the fields again, but I’ll explain the main ones:

dns_lookup_realm: This option defines whether the domain names of the KDC servers should be resolved to determine the Kerberos domain name (realm) when requesting a security ticket. If this option is enabled, the system will attempt to resolve the Kerberos domain name via DNS.
dns_lookup_kdc: This option defines whether the domain names of KDC servers should be resolved to find the KDC servers that manage the requested services. If this option is enabled, the system will try to resolve the KDC server names via DNS.
ticket_lifetime: This option defines the lifetime of Kerberos security tickets. Once a ticket has expired, the user must reconnect and request a new one.
renew_lifetime: This option defines the lifetime during which a security ticket can be renewed. If a user logs in and has a ticket that is about to expire, they can renew their ticket if it is still within the lifetime of the ticket.
forwardable: This option defines if a security ticket can be forwarded to another user or another service.
rdns: This option defines whether the system should attempt to resolve the hostnames of the IP addresses of KDC servers and application servers.
default_realm: This option defines the default Kerberos realm for Kerberos clients. If a Kerberos domain name is not specified, the client will use this option to determine the default Kerberos domain.

4.Samba configuration

As before, you can copy the original file with the command below, in order to recover the contents in the event of an error.

/etc/samba/smb.conf /etc/samba/smb.conf.orig

Next, you’ll need to edit the configuration in /etc/samba/smb.conf with your favourite editor to get a configuration like this:

workgroup = DOMAIN

   client signing = yes
   client use spnego = yes
   kerberos method = secrets and keytab

           ;       security = user

    security = ads
    realm = DOMAIN.LOCAL

    password server = AD.DOMAIN.LOCAL

    load printers = no

   ;[homes]
   ;     comment = Home Directories
   ;     browseable = no
   ;     writable = yes


   ;[printers]
   ;     comment = All Printers
   ;     path = /var/spool/samba
   ;     browseable = no
   ;     guest ok = no
   ;     writable = no
   ;     printable = yes

The 4 main points to remember:

kerberos method: This option defines the Kerberos authentication method used to authenticate users. Common values for this option include “secrets and keytab” and “system keytab”, which determine how authentication information is stored and retrieved.
security: This option sets the security level for Samba client connections. Common values include “user”, “share” and “ads”. The value “user” means that authentication is based on Samba users, “share” means that authentication is based on resource sharing, and “ads” means that authentication is based on an Active Directory server.
realm: This option defines the Kerberos domain for user authentication. This option must match the Kerberos domain configured on clients and servers to enable successful authentication.
password server: This option specifies the server that stores authentication information for Samba users. This option is used to provide redundancy and high availability in large-scale Samba environments. Authentication information includes usernames and passwords for Samba users.

ℹ️ ; are comments

Type the commands below to start the samba service when the machine boots, start it now and check its status:

systemctl enable smb
systemctl start smb
service smb status

5.Check the machine name in /etc/hostname and /etc/sysconfig/network

The hostname of your Linux VMs is very important for this system to work, so I recommend that you check or write the name of your server in the following files /etc/hostname & /etc/sysconfig/network.

Si ce n’est pas déjà fait, ajouter la ligne suivante dans /etc/hostname: template-linux.domain.local

Et celle-ci dans /etc/sysconfig/network: HOSTNAME=template-linux

6.Add the domain controller to /etc/hosts

Please add a static record with the full name of the domain controller at the end of the /etc/hosts file. The translation between the IP address and the server name is necessary so that you can use the host name instead of the IP address.

A.B.C.D contoller.domain.local template-linux

At this point, you should need to restart the service in charge of your server’s network to take your config into account.

systemctl restart network

By executing the following command you can create a mapping between a Windows SID (Security Identifier) and a Unix group. By adding this mapping entry, the command allows Windows users who are members of the “Built-in Guests” group to access shared resources on a Unix system. This can be useful in an environment where Windows and Unix users need to collaborate and share files or other resources.

net -s /dev/null groupmap add sid=S-1-5-32-546 unixgroup=nobody type=builtin

7.oddjob-mkhomedir configuration with authconfig

Please run the following command to configure authentication on a Linux system using SSSD (System Security Services Daemon) services and automatically creating user directories (home directories).

authconfig --update --enablesssd --enablesssdauth --enablemkhomedir

9.sssd configuration

/etc/sssd/sssd.conf

[sssd]
config_file_version = 2
domains = domain.local
services = nss, pam, pac

# le premier "domain" est à conservé, il faut juste adapté "domain.local"
[domain/domain.local]
id_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = ad
cache_credentials = true
override_homedir = /home/%d/%u
default_shell = /bin/bash

I’m not going to go back over the domains, override_homedir & default_shell parameters, which are self-explanatory, but I will take the time to detail the following:

id_provider: specifies the identification source for users and groups. There are several options for this parameter, such as ldap to query an LDAP server, ad to query an Active Directory, or local to use local accounts on the machine.
auth_provider: specifies the authentication source for users. This determines how SSSD verifies the authentication credentials of users to allow them to log in. The options for this parameter are similar to those for id_provider.
chpass_provider: specifies the source for changing the password. This parameter determines how SSSD handles password change requests from users.
access_provider: specifies the source for managing user access to system resources. This parameter determines how SSSD manages user access requests and permissions.
cache_credentials: specifies whether SSSD should cache user credentials. When enabled, SSSD stores credentials in a local cache to avoid having to query authentication sources for each access request.

Then change the permissions on the /etc/sssd/sssd.conf file:

# chown root:root /etc/sssd/sssd.conf
# chmod 600 /etc/sssd/sssd.conf

10.Update sshd_config

Edit your sshd config to allow user groups in your AD to connect to your Linux machine using ssh:

/etc/ssh/sshd_config

Addressfamily inet
Protocol 2
PermitRootLogin no
AllowGroups XXXX XXXX XXXX XXXX
DenyUsers root
DenyGroups root

11.Updating sudoers with visudo

You may need to adjust your sudoers configuration via ```visudo``, to do this simply add your group(s).

[...]
## Allows people in group wheel to run all commands
# %wheel        ALL=(ALL)       ALL
% XXXXX     ALL=(ALL)       ALL

## Same thing without a password
# %wheel        ALL=(ALL)       NOPASSWD: ALL

12 Restarting all services

You can run these commands to restart all services:

# systemctl restart sshd
# systemctl restart sssd
# systemctl restart smb
# systemctl restart oddjobd

13 Initialization with AD

Run the following command:

kinit <username_ad>
Password for username_ad@DOMAIN.LOCAL:

The kinit command is used to obtain a Kerberos ticket for a user. A Kerberos ticket is an authentication token that allows a user to prove their identity to a server in a Kerberos environment.

The kinit command is generally used when the user needs to access network services that require Kerberos authentication, such as authenticating a user when connecting to a remote system, accessing shared resources on a network or executing automated scripts.

When a user executes the kinit command, they are prompted to enter their username and password. Once authentication has been successfully completed, kinit asks the Kerberos server for a security ticket for the user. This ticket is stored in a local cache on the user’s system, and can be used to access network services that require Kerberos authentication.

14.AD integration and DNS implementation

Run the following command:

# net ads join -k -U username_ad
Enter username_ad's password:
Using short domain name -- DOMAIN
Joined 'TEMPLATE-LINUX' to dns domain 'domain.local'

The net ads join -k -U command is used to join a Linux computer to an Active Directory (AD) domain using Kerberos for authentication.

Here is the meaning of the options used in the command:

ads: specifies that the Active Directory domain will be used as the authentication and access control source.
join : specifies that the Linux server will join the Active Directory domain. -k : specifies that the command should use Kerberos for authentication. -U: specifies the user executing the command. The user must be a member of the Active Directory domain administrators group in order to join the Linux computer to the domain. When the net ads join command is run, the user is prompted for the user password specified in the -U option. After successful authentication, the command uses the user’s account information to join the Linux computer to the Active Directory domain.

After the command succeeds, the Linux server can be used to access Active Directory domain resources such as shared files and applications that use Kerberos authentication. Active Directory domain users can also access the Linux computer using their Active Directory domain account.

A little further

Although the procedure is functional and can be implemented in production, it is possible to go further in configuring Active Directory in order to validate the security audits that can be carried out in large groups. I won’t go into detail about this part, as I feel it is outside the scope of this article, which is more concerned with AD.

Conclusion

Now your first Linux VM should be linked to your domain controlled by an Active Directory. Of course you’ve done this by hand, which is great for learning, but you’ll certainly want to industrialise this task, which can be time-consuming, so all that’s left for you to do is write an ansible role 😀 Let me know if you need to!