06. 06. 2023 Andrea Mariani NetEye, Service Management

SSSD for Active Directory Authentication

We all know that NetEye can grant access to its Web Interface through local users, or through the use of LDAP queries that can filter and grant GUI access to users or groups of a given Active Directory domain.

What I would like to explore today is the possibility of granting SSH access and elevating one’s privileges to root (sudo) using an Active Directory domain user.

There are several tools available on Red Hat to manage authentication, for example:

Winbind: a daemon that supports Active Directory directory authentication via the SMB protocol.

LDAP: a standard protocol for accessing network directories. Red Hat offers the option of using the OpenLDAP package for authentication and authorization.

Kerberos: a network authentication protocol that uses secure cryptography to authenticate users and services.

FreeIPA: an open source identity, access and security management software service for both local and Active Directory-based authentication.

Quest Authentication Services: a commercial enterprise authentication program that supports different platforms such as LDAP, Active Directory and Kerberos.

Choosing the right tool depends on your organization’s specific authentication needs.

The authentication system that I’d like to take a look about today, and which has been available since NetEye version 4.23, is SSSD.

SSSD (System Security Services Daemon) is a system daemon that offers an authentication and authorization management solution for Linux and Unix systems.

It’s usually used in environments with Active Directory infrastructure or other enterprise authentication solutions. It provides an easy way to integrate Linux and Unix systems into a centralized authentication environment, and simplifies the configuration and management of authentication across multiple servers.

There are several advantages to using SSSD, such as:

Support for different authentication solutions: SSSD supports different authentication adjustment solutions, including LDAP, Kerberos and Active Directory. This means that users can use the same credentials to log in to different systems in a network environment.

Centralized management of user accounts: SSSD centralizes user account management, simplifying their creation and management across multiple servers. In addition, SSSD supports authentication caching, which means that user credentials can be cached locally for a period of time, improving the speed of authentication for the next user. This is useful in environments with unstable or slow network connections.

Support for authorization services: SSSD provides support for authorization management on various services. For example, you can use SSSD to manage file access on NFS (Network File System) servers without having to configure the NIS (Network Information Services) daemon.

There are also some disadvantages to using SSSD, including:

Dependence on authentication infrastructure: SSSD depends on the authentication and authorization infrastructure of the central server. This means that problems in the central servers can cause problems throughout the entire network, including Linux and Unix systems.

Complex configuration: Configuration of SSSD can be complicated and time-consuming.

Dependence on an Active Directory server means that the system becomes less portable.

Any changes made to the Active Directory configuration may require changes to the SSSD configuration.

At this point, let’s see how to configure the SSSD daemon so that it can register a NetEye machine within a given domain and grant access to a user or group of users defined on Active Directory.

Usage Example

Before proceeding with the installation of the necessary packages you’ll need to ensure that the following prerequisites are in place:

Ensure that the hosts file defines the resolution of the Domain controller, for example:

[root@neteye-425 ~]# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.1.234 wp-test.com w2k19-srv.wp-test.com w2k19-srv

The file resolve.conf points to the correct DNS, for instance:

[root@neteye-425 ~]# cat /etc/resolv.conf
; generated by /usr/sbin/dhclient-script
search wp-test.com
nameserver 192.168.1.234

You will now be able to proceed with installing the necessary packages and their dependencies:

dnf install sssd sssd-tools adcli samba-common samba-common-tools authselect-compat krb5-workstation

Next, set the system policy to DEFAULT:AD-SUPPORT:

update-crypto-policies --set DEFAULT:AD-SUPPORT

After that you’ll need to perform a system reboot. Once done, verify that the policy has applied correctly:

[root@neteye-425 ~]# update-crypto-policies --show
DEFAULT:AD-SUPPORT

Then check domain reachability and configuration information:

[root@neteye-425 ~]# realm discover -v wp-test.com
 * Resolving: _ldap._tcp.wp-test.com
 * Resolving: wp-test.com
 * Performing LDAP DSE lookup on: 192.168.1.234
 * Successfully discovered: wp-test.com
wp-test.com
  type: kerberos
  realm-name: WP-TEST.COM
  domain-name: wp-test.com
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: oddjob
  required-package: oddjob-mkhomedir
  required-package: sssd
  required-package: adcli
  required-package: samba-common-tools
  login-formats: %U@wp-test.com
  login-policy: allow-realm-logins

NetEye Join to Active Directory Domain:

[root@neteye-425 ~]# realm join wp-test.com
Password for Administrator:

[root@neteye-425 ~]# realm join wp-test.com -U Administrator
Password for Administrator:

Verification of successful join:

[root@neteye-425 ~]# realm list
wp-test.com
  type: kerberos
  realm-name: WP-TEST.COM
  domain-name: wp-test.com
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: oddjob
  required-package: oddjob-mkhomedir
  required-package: sssd
  required-package: adcli
  required-package: samba-common-tools
  login-formats: %U@wp-test.com
  login-policy: allow-realm-logins

By default, the SSSD service is configured with just the option to create the user home directory, verifiable by the following command:

[root@neteye-425 ~]# authselect current
Profile ID: sssd
Enabled features:
- with-mkhomedir

To add the ability to run the sudo command, you’ll need to run the following command:

[root@neteye-425 ~]# authselect select sssd with-mkhomedir with-sudo
Profile "sssd" was selected.
The following nsswitch maps are overwritten by the profile:
- passwd
- group
- netgroup
- automount
- services
- sudoers

Make sure that the SSSD service is configured and enabled. See the SSSD documentation for more information.

Select with-mkhomedir, make sure the pam_oddjob_mkhomedir module is present and that the oddjobd service is enabled and active:

systemctl enable --now oddjobd.service

Verify that the changes have been incorporated:

[root@neteye-425 ~]# authselect current
Profile ID: sssd
Enabled features:
- with-mkhomedir
- with-sudo

And apply our changes persistently:

[root@neteye-425 ~]# authselect apply-changes
Changes were successfully applied.

At this point we’ll need to add the AD user groups that will have access to the NetEye system. For example, in the test environment I created two specific groups, one for administrative and one for access-only users:

[root@neteye-425 ~]# realm permit -g neteye_admin@wp-test.com
[root@neteye-425 ~]# realm permit -g neteye_users@wp-test.com

Once the groups or individual users have been added, a restart of the SSD service will need to be carried out. Then we’ll be able to view the added users or groups.

[root@neteye-425 ~]# systemctl restart sssd

[root@neteye-425 ~]# realm list
wp-test.com
  type: kerberos
  realm-name: WP-TEST.COM
  domain-name: wp-test.com
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: oddjob
  required-package: oddjob-mkhomedir
  required-package: sssd
  required-package: adcli
  required-package: samba-common-tools
  login-formats: %U@wp-test.com
  login-policy: allow-permitted-logins
  permitted-logins:
  permitted-groups: neteye_admin@wp-test.com, neteye_users@wp-test.com

You can now run a test login on the system.

Summary of SSSD

The configuration files affected by the changes made by the above commands are as follows:
– /etc/nsswitch.conf
– /etc/sssd/sssd.conf
Below are the parameters that can be used with the realm command:

Command	Description
realmd Commands
discover	Run a discovery scan for domains on the network
join	Add the system to the specified domain
leave	Remove the system from the specified domain
list	List all configured domains for the system or all discovered and configured domains.
domains
Login Commands
permit	Enable access for specific users or for all users within a configured domain to access the local system
deny	Restrict access for specific users or for all users within a configured domain to access the local system

You may find the documentation on using the Authselect command to be helpful.

Using the authselect command, you can preconfigure the sssd.conf and nsswitch.conf configuration files:

authselect current (to display the current profile and enabled features)
authselect select sssd (to select the profile to use, in this case sssd is the default profile name)
authselect select sssd with-mkhomedir with-sudo (added features to automatically create the home directory on the AD user’s linux system at first login and settings to elevate users to root)

Other features available are:

with-sudo
with-mkhomedir
with-smartcard
with-faillock
with-fingerprint

Once the profile has been changed, the sssd.conf and nsswitch.conf files will be rewritten using the following command:

authselect apply-changes

Here you can find the RedHat documentation for Access Control for Users and Groups.

Configure Sudo Access

By default, domain users do not have the necessary permissions to elevate themselves to root. To do so, you must add the individual user or a specific group to a file within the /etc/sudoers.d/ directory.

Within the file you can add the individual users or groups who will have the permissions to run the sudo command, for example:

vi /etc/sudoers.d/domain_admins
user1@example.com ALL=(ALL) ALL
%group1@example.com ALL=(ALL) ALL
“%linux_admin” ALL=(ALL) ALL

Save and exit, after which you should test ssh access and sudo.
Alternatively you can edit the file /etc/sudoers

The above was tested in a NetEye environment installed from scratch and without previous configuration. I hope it can be of help to those who want to implement a higher level of security in their system.

These Solutions are Engineered by Humans

Did you like this article? Does it reflect your skills? We often get interesting questions straight from our customers who need customized solutions. In fact, we’re currently hiring for roles just like this and others here at Würth Phoenix.