Externally managed nevisAppliance administrators using LDAP or ActiveDirectory

Introduction

An active digital identity consists of valuable assets and represents a key to company-owned internal data. Propagation of these assets across the organization's infrastructure lowers the control, integrity and confidentiality levels at which assets and thus internal data sets get protected. Centralized storage and processing of employee identities and access profiles helps to keep data secure and integer. It also makes accountability of actions taken by employees both predictable and non-repudiable.

Nevis provides support for centralized external sources of user data on nevisAppliance. It is possible to configure OpenLDAP and Active Directory of Microsoft as authentication and authorization backends for the administrators and operators of the Nevis Security Suite. Within the OpenLDAP or Active Directory infrastructure, authentication and authorization claims are forwarded to the central user repository; nevisAppliance acts solely as their consumer.

Access to nevisAppliance is possible via both the local console and the secure shell. Configuration of uplinks to OpenLDAP and Active Directory have been tested with LDAP(s). Other products and protocols may work too, but were neither tested nor verified. Therefore, they are not supported by Nevis Security.

After checking local administrators first, the nevisAppliance can be configured to login via OpenLDAP or ActiveDirectory.

Local administrators

To set up nevisAppliance for the first time or when no external directory is available, use the preinstalled local administrator accounts as described in Access to the nevisAppliance › Local administrator.

Requirements and preconditions

Before starting the setup on nevisAppliance, ensure to fulfill the following requirements:

• A working instance of the OpenLDAP server, version 2.4.x (or newer), or a working instance of Microsoft's Active Directory.
• Fully-qualified hostnames (FQDN) of the used OpenLDAP or Active Directory server, port, and protocol (ldap or ldaps). Ensure the FQDN is reachable from the nevisAppliance host. If not, check the network settings in the nevisAppliance menu. To open the menu, run nevisappliance on the command line.
• Support for the LDAP search base, the LDAP protocol version and the authentication scheme required by the LDAP server.
• For the ldaps protocol: The CA certificate and chain for the directory server (PEM format) must be available.

Preparing your directory

The next step is to give the users managed in the external directory the proper permissions on the nevisAppliance host. Therefore, add the users to one of the following groups:

caution

The mapping between the groups in the directory and on the nevisAppliance is based on the group ID (GID). Ensure you use the group IDs defined in this document. These group IDs are fixed in the nevisAppliance and cannot be changed.

• Administrators (GID: 20005) are granted full rights on all instances of Nevis components. This also includes the rights to restart the services or use sudo. Create a POSIX group "nevisadmin" with group ID "20005" in the directory.
• Read-only users (logs, configs) (GID: 30000) are granted read-only rights to read the configuration and log files created on nevisAppliance by all components of the Nevis Security Suite. Create a POSIX group "nvbgroup" with group ID "30000" in the directory.

Configuring the nevisAppliance for an OpenLDAP directory

Perform the following steps to connect nevisAppliance to an OpenLDAP directory, thus allowing the externally managed users to log in and manage the nevisAppliance host.

1. Configure your nevisAppliance to use central OpenLDAP directory by running authconfig on the nevisAppliance as root.

   • Note, that if you are running nevisAppliance on Rolling Release (RR), the base OS has been switched to Rocky Linux 8 recently, thus the command 'authconfig' has been replaced by 'authselect'.
   • See migration guides and the manual pages on how to use the new command.

   authconfig --enableldap --enableldaptls --enableldapauth \
    --ldapserver="ldaps://ldap.internal.example.corp:636" \
    --ldapbasedn="ou=people,o=example,c=net" \
    --enablemkhomedir --update

   and adding this to /etc/openldap/ldap.conf:

   # Set the default base dn
   BASE   ou=people,o=example,c=net
   
   # Set the default LDAP server
   URI    ldaps://ldap.internal.example.corp:636

   Adjust values like the FQDN of the OpenLDAP directory or the Base DN according to your environment.

   The equivalent on nevisAppliance RR (Rocky Linux 8 based) would be:

   systemctl enable --now sssd
   systemctl enable --now oddjobd
   authselect select sssd with-mkhomedir (adding '--force' if already existing)

   create a corresponding /etc/sssd/sssd.conf file matching your needs. Example:

   [domain/default]
   id_provider = ldap
   autofs_provider = ldap
   auth_provider = ldap
   chpass_provider = ldap
   ldap_uri = ldaps://ldap.internal.example.corp:636/
   ldap_search_base = ou=people,o=example,c=net
   sudo_provider = ldap
   ldap_id_use_start_tls = False
   
   [sssd]
   services = nss, pam, autofs, sudo
   domains = default
   
   [nss]
   homedir_substring = /home
   
   [sudo]

Advanced OpenLDAP Configuration

Your OpenLDAP server may require additional settings to be configured on the client side, for instance, if your LDAP server only accepts authenticated requests and/or requires TLS connections only. If this is the case, edit and configure the file /etc/openldap/ldap.conf on nevisAppliance to meet requirements of your LDAP environment.

Common properties missing in the file could be (for example):

TLS_CACERT /etc/openldap/certs/corp-CA.pem
ldap_version 3
ssl on
binddn cn=some-user,ou=required,ou=for-ldap-bind,o=example, c=corp
bindpw xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
bind_policy soft
idle_timelimit 60
pam_lookup_policy yes
nss_initgroups_ignoreusers root,ldap
nss_schema rfc2307bis

If you are in doubt, ask your LDAP administrators how to proceed.

2. For the changes to take effect, a restart of the System Security Services Daemon (SSSD) is required:

   systemctl restart sssd.service

   Ensure that /etc/sssd/sssd.conf has the right ownership (chown root:root /etc/sssd/sssd.conf) and file permissions (chmod 600 /etc/sssd/sssd.conf) before sssd.service restart.

   Ensure that the sssd and oddjobd (for Rocky Linux 8) services are up and running after the restart. If not, check the journalctl and SSSD logs for details.

3. As a last step, test your setup by executing one of the following commands locally:

   # 1) Lookup via LDAP should deliver one hit
   #    EXPECTED: <some-user>:*:11192:102:<Firstname> <Lastname>:/home/<some-user>:/bin/bash
   getent passwd <some-user>
   
   # 2) groups an LDAP based user belongs to are imported from LDAP, too
   #    EXPECTED: uid=11192(<some-user>) gid=11550(<some-primary-group>)
   #              groups=10200(staff),20005(nevisadmin),10740(wlan)
   id <some-user>

   If you do not get the expected output or if the command fails, double-check your configuration and the system logs.

4. If everything works fine, the nevisAppliance is successfully connected to your OpenLDAP directory.

Configuring the nevisAppliance for Active Directory

Perform the next steps to connect nevisAppliance to an Active Directory of Microsoft. This enables the externally managed users to log in and manage the nevisAppliance host.

1. Configure your nevisAppliance to use central Active Directory, by running authconfig (or the appropriate 'authselect', see previous comment) on the nevisAppliance as root:

   authconfig --enableldap --enableldapauth \
    --ldapserver=ad.internal.example.corp \
    --ldapbasedn="ou=people,o=example,c=net" \
    --enablemkhomedir --update

   Adjust values like the FQDN of the Active Directory or the Base DN according to your environment.

   nevisAppliance uses the parameters uidNumberand gidNumberto determine a user's user ID and group ID.

   If you are on RR nevisAppliance (Rocky Linux 8 based), the appropriate commands on the nevisAppliance would be

   realm discover <realm>   # to find out/check the AD command you'd like to connect to
   realm join <realm>       # to connect to that realm; the entries go into /etc/sssd/sssd.conf; provide Administrator password here when asked

   You might then adjust the values in /etc/sssd/sssd.conf according to your shop and add the entries needed for the nevisAppliance.

   Refer to the sample provided here, as a starting point:

   /etc/sssd/sssd.conf file (which connects to an AD 'NEVIS-SECURITY.COM')

   ...
   [sssd]
   domains = nevis-security.com
   config_file_version = 2
   services = nss, pam
   
   [domain/nevis-security.com]
   ad_domain = nevis-security.com
   krb5_realm = NEVIS-SECURITY.COM
   realmd_tags = manages-system joined-with-adcli 
   cache_credentials = True
   id_provider = ad
   krb5_store_password_if_offline = True
   default_shell = /bin/bash
   ldap_id_mapping = False
   ldap_user_uid_number = uidNumber   # needed for nevisAppliance
   ldap_user_gid_number = gidNumber   # needed for nevisAppliance
   use_fully_qualified_names = True
   fallback_homedir = /home/%u@%d
   access_provider = ad
   ...

2. Restart the System Security Services Daemon (SSSD) for the changes to take effect. Also, clearing the cache using rm -f /var/lib/sss/db/* might be useful.

   systemctl restart sssd.service

   Ensure that the sssd service is up and running after the restart. If not, check the journalctl and SSSD logs for details.

3. As a last step, test your setup by executing one of the following commands locally:

   # 1) Lookup via LDAP should deliver one hit
   # EXPECTED: <some-user>:*:11192:102:<Firstname> <Lastname>:/home/<some-user>:/bin/bash
   getent passwd <some-user>
   
   # 2) groups an LDAP based user belongs to are imported from LDAP, too
   # EXPECTED: uid=11192(<some-user>) gid=11550(<some-primary-group>)
   # groups=10200(staff),20005(nevisadmin),10740(wlan)
   id <some-user>

   If you do not get the expected output or the command fails, double-check your configuration and the system logs.

4. If everything works fine, the nevisAppliance is successfully connected to your Active Directory.

Configuring login with Public Key (sshPublicKey)

Since the SSSD is provided and enabled on the nevisAppliance, it's possible to configure password-less authentication using SSH public keys, stored in OpenLDAP or ActiveDirectory. This further enhances security, by avoiding people having to remember passwords, by using strong certificates. It requires the directory to store the SSH public key.

Requirements

• Ensure you have configured OpenLDAP or ActiveDirectory, as described in the previous two chapters.
• Make sure the users have the following attributes in the directory; mainly the ldapPublicKey class and the sshPublicKey attribute:

ldap parameters

objectClass: posixAccount
objectClass: ldapPublicKey
uid: <userID>
uidNumber: <some number>
gidNumber: 30000
homeDirectory: /home/<userID>
loginShell: /bin/bash
mail: <userID>@<your.company.domain>
sshPublicKey: <a public ssh key of user is to be entered here>

The following OpenSSH LDAP schema can be used for this:

openssh-ldap.schema

#
# LDAP Public Key Patch schema for use with openssh-ldappubkey
#                              useful with PKA-LDAP also
#
# Adjusted: Dennis Leeuw <[email protected]>
#           Making the uid a MUST, but the sshPublicKey a MAY
#           so we can add the objectClass and later add the key
#
# Author: Eric AUGE <[email protected]>
#
# Based on the proposal of : Mark Ruijter
#

# octetString SYNTAX
attributetype ( 1.3.6.1.4.1.24552.500.1.1.1.13 NAME   'sshPublicKey'
    DESC 'MANDATORY: OpenSSH Public key'
    EQUALITY octetStringMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )

# printableString SYNTAX yes|no
objectclass ( 1.3.6.1.4.1.24552.500.1.1.2.0 NAME  'ldapPublicKey' SUP top AUXILIARY
    DESC 'MANDATORY: OpenSSH LPK objectclass'
    MUST uid
    MAY sshPublicKey
    )

• SSSD service is to be started and activated on boot with 'systemctl enable sssd'

Finally, to enable passwordless log-in via ssh to nevisAppliance it is necessary to activate two parameters within /etc/ssh/sshd_config on nevisAppliance:

/etc/ssh/sshd_config

#AuthorizedKeysCommand           /root/tools/ldap/fetch-ssh-pubkey.sh
#AuthorizedKeysCommandUser       root

and to restart ssh daemon afterwards with systemctl restart sshd.service

Limitations

• Users home directories get deleted during every nevisAppliance reboot.
• Other directory products than OpenLDAP and Active Directory are not supported.
• Access to OpenLDAP and Active Directory with protocols other than LDAP(s) is not supported.
• GID numbers (nevisadmin and nvbgroup) are pre-defined in nevisAppliance and cannot be changed.
• Kerberos-based session tickets are not supported. The user has to provide a username and password every time an interactive shell is to be started.

External documentation

SSSD using the LDAP provider is well-documented open source standard. You find more information, among others, at Using authconfig.