SSH User Authentication using Windows Active Directory (WAD)

By default, SSH to StarlingX hosts supports authentication using the ‘sysadmin’ Local Linux Account and StarlingX Local LDAP Linux User Accounts. SSH can also be optionally configured to support authentication with 1 or more remote LDAP identity providers (such as WAD). Internally, SSH uses SSSD service to provide NSS and PAM interfaces and a backend system able to remotely connect to multiple different LDAP domains.

SSSD provides a secure solution by using data encryption for LDAP user authentication. SSSD supports authentication only over an encrypted channel.

In summary the SSH/SSSD solution for remote LDAP authentication includes:

  • Multi domain remote LDAP authentication

  • Extra security by using data encryption for LDAP user authentication

  • Offline authentication if a LDAP identity store is unavailable, by caching users and managing caching timeout and refresh

  • High authentication and authorization performance

In StarlingX a maximum of 3 LDAP WAD domains are supported besides the local Openldap domain.

Note

SSH/SSSD authentication configuration described in this section also applies to local console logins.

You can find more information about SSSD configuration at https://linux.die.net/man/5/sssd.conf and https://linux.die.net/man/5/sssd-ldap.

Install WAD CA Certificate

To be able to successfully connect to a WAD domain through a secure SSL connection, SSSD requires the SSL Certificate of the CA that signed the remote WAD server’s SSL Certificate to be installed on the StarlingX system. The WAD CA SSL certificate needs to be installed before the corresponding AD domain is added.

The command to add WAD CA certificate:

system certificate-install --mode ssl_ca <AD CA certificate file>

Add Remote WAD Domain

A maximum of three remote LDAP AD domains are supported in StarlingX: ldap-domain1, ldap-domain2, ldap-domain3. Each domain needs to be configured using mandatory and optional service parameters. Each parameter will be validated according to industry standard validation rules for correct syntax that apply to domain names, ldap url, and directory names. An error message will be displayed if the parameter does not have the standard syntax.

Mandatory parameters

To add a new remote ldap WAD domain the following mandatory SSSD parameters need to be added using system service parameter commands:

  • domain_name

  • ldap_uri

  • ldap_access_filter

  • ldap_search_base

  • ldap_default_bind_dn

  • ldap_default_authtok

If a mandatory parameter is missing, an error will be displayed, naming the missing parameter for the domain and the domain will not be created.

Commands to add mandatory parameters for a remote ldap domain:

system service-parameter-add <service_name> <section_name> parameter_name=<parameter_value>

# <service_name> is “identity” for all domains.
# <section_name> identifies a domain as either “ldap-domain1”, “ldap-domain2” or “ldap-domain3”.

E.g.:

system service-parameter-add identity ldap-domain1 domain_name=ad.wad-server.com

system service-parameter-add identity ldap-domain1 ldap_uri=ldaps://ad.wad-server.com

system service-parameter-add identity ldap-domain1 ldap_access_filter=memberOf=CN=WRCP_Admin,CN=Users,DC=wad-server,DC=com

system service-parameter-add identity ldap-domain1 ldap_search_base=CN=Users,DC=wad-server,DC=com

system service-parameter-add identity ldap-domain1 ldap_default_bind_dn=CN=Administrator,CN=Users,DC=wad-server,DC=com

system service-parameter-add identity ldap-domain1 ldap_default_authtok =Passw0rd*

Optional Parameters

There are two optional domain parameters that can be added using system service parameter commands:

  • ldap_user_search_base

  • ldap_group_search_base

For example:

system service-parameter-add identity ldap-domain1 ldap_user_search_base=CN=Users,DC=wad-server,DC=com

system service-parameter-add identity ldap-domain1 ldap_group_search_base=CN=Groups,DC=wad-server,DC=com

Note

When not set, the 2 optional service parameters, will have as default value, the value of ldap_search_base service parameter.

Apply parameters

After all the domain mandatory parameters are added and if needed, the optional ones, the parameters will be applied using service-parameter-apply command. Only after “apply” command the sssd domain configuration will be added to /etc/sssd/sssd.conf and becomes active, and the SSSD daemon will connect to the remote WAD server.

The system service-parameter-apply command has been enhanced for this feature to include a section parameter that did not exist in the previous release. The new section parameter is an optional parameter of the service-parameter-apply command. In the context of the identity service ldap domains it is needed to specify the domain section name, as follows:

system service-parameter-apply <service-name> --section <section-name>

E.g.:

system service-parameter-apply identity --section ldap-domain1

Default WAD Domain Configuration

The default WAD domain configuration parameters are pre-configured. Main SSSD default configuration settings include:

  • Offline Authentication is enabled, allowing users to still authenticate even if the ldap identity provider is unavailable. using their cached credentials. User credentials caching is enabled by parameter setting cache_credentials = true. After a successful login user credentials are stored as part of the user account in the SSSD cache.

  • WAD Domain enumeration is disabled by using the default setting enumerate = false for performance reasons.

  • User home directory on the StarlingX platform gets created after the first user login with the following path /home/<domain_name>/<user_name>.

  • CA server certificate verification is always required by using the default setting for ldap_tls_reqcert parameter as demand.

SSH using the WAD domain user

Verify SSSD is Connected to the Domain

If the SSSD is connected to a WAD domain, then the domain users have been discovered and cached on the host. The same applies to the domain groups.

Run getent passwd <user_login_name>@<domain_name>, to see if the user has been cached on the host.

getent passwd pvtest1@ad.wad-server.com

Run getent group <group_name>@<domain_name> to see the group and its members.

getent passwd eng@ad.wad-server.com

Remote SSH

Once the SSSD is connected to the domain, a domain user can be used to SSH to the StarlingX host. If a user has the same user login name in multiple domains, the domain name can be used to distinguish between the common name users.

ssh -l <domain_user_name>@<domain_name> <host_IP_address>

The automatically created home directory for the user is /home/<domain_name>/<user_name>.

Modify/Delete WAD Domain parameters

Modify an SSSD parameter for an ldap domain using system service parameter command.

The service-parameter-apply needs to follow the service-parameter-modify so the parameter value change can take effect.

For example:

system service-parameter-modify identity ldap-domain1 ldap_group_search_base=CN=Users,DC=wad-server,DC=com

system service-parameter-apply identity --section ldap-domain1

Regarding deleting WAD domain parameters, only optional SSSD service parameters can be individually deleted:

system service-parameter-delete <parameter-uuid>

system service-parameter-apply identity --section <domain_section_name>

Delete a WAD Domain configuration

Optional domain parameters can be deleted individually.

Mandatory parameters cannot be deleted individually, is all or none.

To fully delete a domain, delete all the mandatory parameters and the configured optional parameters. After that, execute the service-parameter-apply` command.

system service-parameter-delete <parameter-uuid>

------------ delete all parameters of the domain-----------

system service-parameter-apply identity --section <domain_section_name>

Deleting a domain will cause the users to not show up with getent passwd command anymore even if they may have not been removed from cache just yet. The users will be removed from cache according to cache expiration configuration. The cache expiry configuration for this release, uses default values.

The WAD users home directories created on the platform will not be removed after the WAD domain configuration is removed. It is administrator’s responsibility to clean up users’ home directories that are no longer used.

SUDO Capability and Local Group Membership

This section describes how to enable the sudo and sys_protected privileges for configured users in WAD servers.

The Linux specification stipulates that the GUID values in the range 0 to 99 should be statically allocated by the system and shall not be created by applications. Therefore, a sudo group with GUID 27 and the root group GUID 0 are special groups that cannot be created by the SSSD client interfacing with the WAD server.

The sudo privileges can be assigned to WAD users using the sudo rules mechanism.

Sudo rules are access control rules that define the users who are granted access, the commands a user has access to, and the target hosts to which the rules apply.

Enable Sudo Privileges for WAD Users

You can enable sudo All privileges for LDAP users from a remote WAD server. Enabling sudo privileges allows the LDAP users to execute the following operations:

  • sw_patch to unauthenticated endpoint

  • docker and/or crictl commands to communicate with the respective daemons

  • Utilities show-certs.sh and license-install (recovery only)

  • IP configuration for local network setup

  • Password change of local openldap users

  • Access to restricted files, example: restricted logs

  • Manual reboots

Load Sudo Schema in WAD LDAP Server

The sudo rules schema is not a part of standard WAD installation. For WAD servers, the schema needs to be loaded and installed using the ldifde utility.

LDAP sudo rules schema is contained in the package libsss-sudo. The schema will be loaded in /usr/share/doc/sudo-ldap/schema.ActiveDirectory.gz during system installation.

Install Schema

Procedure

  1. Extract the schema from schema.ActiveDirectory.gz and copy it in a file on the WAD server.

  2. Install the schema by running the following command on the WAD server:

    ldifde -v -i -f ``schema.ActiveDirectory.txt`` -j

Results

The following shows the successful loading of a schema:

Importing directory from file ``schema.ActiveDirectory.txt``
Loading entries
…….
12 entries modified successfully.
The command has completed successfully

Create Directory Entry for Sudo Rules in WAD Server

The sudoers OU needs to be created on the domain root. This OU will hold all the sudo rules defined using sudoRole object.

Note

The sudoers OU directory path will be automatically set as the ldap_sudo_search_base parameter value in the sssd configuration file /etc/sssd/sssd.conf. The ldap_search_base parameter must be set at the same level in the domain root as shown in the following example:

ldap_search_base = CN=Users,DC=domain,DC=com  (set using ``system service-parameter`` command)
ldap_sudo_search_base = OU=sudoers,DC=domain,DC=com (pre-configured in sssd configuration)

Procedure

  1. Create an ldif file with the following content:

    dn: OU=sudoers,DC= dc=domain,DC=com
changetype: add
objectClass: top
objectClass: organizationalUnit
ou: sudoers

  2. Import the file by running the following command on the WAD server:

    ldifde -v -i -f "sudoers_ou.txt" -j

    where, sudoers_ou.txt is the ldif file created in the previous step.

Results

The following shows the successful loading of the ldif file:

Connecting to ``ad.domain.com``
Logging in as current user using SSPI
Importing directory from file "sudoers_ou.txt"
Loading entries
1: OU=sudoers,DC=domain,DC=com
Entry modified successfully

Create a Sudo Rule for a WAD User

Procedure

  1. To assign sudo All privileges to a WAD user with name techadmin, create and load the following ldif file content:

    dn: CN=techadmin,OU=sudoers,DC=domain,DC=com
changetype: add
objectClass: top
objectClass: sudoRole
cn: techadmin
distinguishedName: CN=techadmin,OU=sudoers,DC=domain,DC=com
name: techadmin
sudoUser: techadmin
sudoHost: ALL
sudoRunAsUser: ALL
sudoCommand: ALL

  2. Load the ldif file by running the following command on the WAD server:

       ldifde -v -i -f "sudo-rule.txt" -j

where, ``sudo-rule.txt`` is the ``ldif`` file created in the previous step.

Results

The following shows the successful loading of the ldif file:

Connecting to "ad.domain.com"
Logging in as current user using SSPI
Importing directory from file "sudo-rule.txt"
Loading entries
1: CN=techadmin,OU=sudoers,DC=domain,DC=com
Entry modified successfully.
1 entry modified successfully.
The command has completed successfully

The sudo rules will be discovered by sssd service and cached in the StarlingX platform. The sssd logs in /var/log/sssd/sssd_ad.domain.log will show the number of rules downloaded from WAD server that indicates that the sudo rules were received.

(2023-02-28 22:35:16): [be[ad.domain.com]] [sdap_search_bases_ex_donee] (0x0400): Receiving data from base [OU=sudoers,DC=domain,DC=com]
(2023-02-28 22:35:16): [be[ad.domain.com]] [sdap_sudo_load_sudoers_done] (0x0200): Received 1 sudo rules
(2023-02-28 22:35:16): [be[ad.domain.com]] [sdap_sudo_refresh_done] (0x0400): Received 1 rules

Verify Sudo All Privileges for the WAD Sudo User

SSH to the StarlingX platform using the sudo user and verify that the user has sudo All privileges.

techadmin@controller-0:~$ sudo -l
Password:
Matching Defaults entries for techadmin on controller-0:
  env_reset, mail_badpass,
  secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin,
  lecture=never,
  secure_path=/usr/local/bin\:/usr/bin\:/bin\:/usr/local/sbin\:/usr/sbin\:/sbin,
  lecture=never,
  secure_path=/usr/local/bin\:/usr/bin\:/bin\:/usr/local/sbin\:/usr/sbin\:/sbin,
  passprompt="Password: "

User techadmin may run the following commands on controller-0:
(ALL) ALL
techadmin@controller-0:~$

Creating a User in the Linux Sys_protected Group on a WAD Server

Create a sys_protected group in the WAD server and set the gidNumber to 345 to be the same as Linux sys_protected group. Add a WAD user (example: techadmin) as a member in the sys_protected group. The sys_protected LDAP group and its member will be discovered and cached in the StarlingX platform by SSSD service.

To check if the WAD user has been added to the sys_protected group, SSH to StarlingX as the WAD user and check the groups the user is a member of.

Linux controller-0 5.10.0-6-amd64 #1 SMP PREEMPT StarlingX Debian 5.10.162-1.stx.64 (2023-02-16) x86_64
Last login: Fri Mar 10 22:20:16 2023 from 10.10.10.254
techadmin@controller-0:~$ groups
domain users sys_protected
techadmin@controller-0:~$

Note

When creating a WAD user that will be discovered and created on the StarlingX Linux host as part of the users group, set the WAD user GUID value to 100 that is the same as that of the Linux users group. The WAD user UID should be set to a unique value within the Linux users group.

When a new WAD user is created using the Active Directory Users and Group Administration tool, the User must change password at next login checkbox must be unchecked, otherwise the user login to the StarlingX host will fail.

Default Local OpenLDAP Domain Configuration

The configuration for the local OpenLDAP domain is part of the default SSSD configuration.

All the local OpenLDAP domain parameters are pre-configured. Main SSSD default configuration settings include:

  • Domain enumeration is enabled as the local domain number of users is not as large to pose performance issues. The use of command getent passwd will list all the remote domain discovered users.

  • The user home directory on the StarlingX platform gets created after the first user login and has the following path /home/<user_name>.

  • CA server certificate verification is always required by using the default setting for ldap_tls_reqcert parameter as demand.

The OpenLDAP SSL certificate is created and managed internally by StarlingX platform.

SSSD logs

SSSD logs can be viewed on the host, in directory /var/log/sssd/sssd.log. Each domain also has its own log file: /var/log/sssd/sssd_<domain_name>.log.