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

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

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 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 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.

2. Restart the System Security Services Daemon (SSSD) for the changes to take effect:

   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.