Single point solution for SSH authentication

Content

Protocols

LDAP (Lightweight Directory Access Protocol) is an open protocol used to store and retrieve centrally stored data in a hierarchical and categorized manner using directory structure called a directory information tree over a network. LDAP is mostly commonly used to store and manage information about an organization and its assets and users. It is a flexible, lightweight in a written code solution to define any type of entity and its qualities. It is usually implemented as a component of a client/server system for managing sensitive information of account details.

LDAP as a communications protocol defines methods for a way to access directory service. LDAP represents data to users within a directory service and defines requirements for the components used to create data records.

Remote Authentication Dial-In User Service (RADIUS) is an authentication, authorization and accounting (AAA) protocol primarily used for user access control. Usually it is used in network services such as wireless networks, VPNs, and network infrastructure equipment. Radius clients contact servers with user credentials with an Access-Request message and servers in turn respond back with an Accept, Reject or Challenge message. To minimize flowing traffic authorization and authentication are generally performed in one step.

RADIUS has support of two-factor authentication or one-time password service and more complex forms of authentication, such as those described by the Extensible Authentication Protocol (EAP). Accounting services can also be performed by RADIUS to ensure that user information is properly tracked. Use RADIUS for: wireless networks, VPNs, network infrastructure equipment.

Security Assertion Markup Language (SAML) is the authentication and authorization protocol most often used for single sign-on (SSO) solutions generally in web applications. All needed for authorization data exchanges by digitally signed XML-based documents. Such kind of implementation provides seamless authentication between business and enterprises.

SAML is defined by two entities: a Service Provider and an Identity Provider. Service provider is usually a web application that can be accessed by users. It requests user authentication from Identity Provider. In return, the Identity Provider generates an authentication assertion, that will indicate that access for the user is authorized.

SAML has improved user experience such as only one-time signing to access multiple services. Excluding any additional authentication it will allow more faster and better experience for service providers and avoid issues with recovering and resetting passwords.

Increased security is also one of the SAML benefits that comes extremely important for enterprise applications. A single point of authentication provides a secure transfer of the identity to Service Providers. This is ensuring that sensitive data like credentials will always stay in the firewall area.

Use SAML for web applications.

Kerberos is a network authentication protocol that provides a secret-key encryption technology to enable strong authentication for client/server applications on an open network. There is a free implementation of Kerberos, as well as a part of many commercial products.

Authentication in Kerberos is done to avoid transmitting plain passwords over the wires. It uses a shared secret and a trusted third party arbitrator for validating the identity of clients. In Kerberos servers, users or pieces of software may be clients. The arbitrator is the server-side Key Distribution Center (KDC) that runs the Kerberos daemons. Shared secret is the user's password converted into a cryptographic key.

System based on Kerberos consists of the Kerberos software itself, secured authentication servers, a centralized data store, and systems configured to authenticate through the Kerberos protocol. It will prevent you from having to store sensitive data locally on a machine, reducing the probability of a single machine to compromise the entire infrastructure. It will also reduce administration costs of maintaining a large number of account databases and provides tools to solve network security problems such as password sniffing or stealing from database.

Protocol Encryption Method Server Identity Verification Tunnel Encryption Transport method Network load
LDAP End-to-End X.509 validation Full TCP Moderate
RADIUS Hop-to-Hop Shared key and X.509 validation Partial UDP Minimal
SAML End-to-End X.509 validation Full TCP Moderate
Kerberos End-to-End NTLM, Kerberos v5 Partial UDP Minimal

Authentication server applications

From our opinion, most popular authentication server applications could be divided into:

  1. Open source authentication applications.
  2. Proprietary authentication applications.
  3. Cloud authentication services.

See the review below

Open Source authentication applications

OpenLDAP is an open source implementation of LDAP protocol developed by the OpenLDAP Project. It was derived from LDAP and designed to run on TCP/IP. OpenLDAP supports LDAPv3 which provides support for Simple Authentication and Security Layer (SASL), and Transport Layer Security (TLS). OpenLDAP also supports IPv6. OpenLDAP provides more security through inter process communication (IPC) instead of communicating over the network.

As the name suggests, it is a lightweight client-server protocol for accessing directory services, specifically X. 500-based directory services. LDAP runs over TCP/IP or other connection oriented transfer services. All the data in a directory service is stored and organized in a key-value type format. Directories are well optimized for searches, and read operations over write operations. So they function perfectly for the information which is generally much more often read that is written.

Stored in a directory service data is often a description used for defining the qualities of an entity. A good example of representation in a directory service physical object is an address book. There could be a lot of records represented for each user/person in the directory like phone number, address, place of business or any other information described with key-value pairs. Directory services are very helpful and useful when you want to make a well categorized and descriptive information accessible.

Features of OpenLDAP:

  • LDAPv3 Support: Simple Authentication, Security Layer and Transport Layer Security;
  • Supports Internet Protocol version 6;
  • Updated C API: Improves the way programmers can connect to and use LDAP directory servers;
  • DIFv1: full compliance with the LDAP Data Interchange Format (LDIF);
  • Enhanced Stand-Alone LDAP Server: updated access control system, thread pooling, better tools;
  • LDAP Over IPC: enhanced security by inter-process communication (IPC) eliminating the need to communicate over a network.

389 Directory Server is an open source enterprise solution based on the Lightweight Directory Access Protocol (LDAP). It is a highly reliable and secure server implementation that is designed to manage large directories of users and resources with capability to handle several thousands of operations per second.

389 DS has several advanced features including asynchronous multi-master replication for horizontal scaling and supports TLS and SASL for authentication and transport. In addition to that python-ldap provides an object-oriented API to access LDAP directory servers from Python programs.

389 DS includes Mozilla’s Certification Authorities (CA) system with a set of X.509v3 root certificates. The included certificates have their "trust bits" set for various purposes, so that the software can use the CA certificates to anchor a chain of trust for certificates used by SSL servers and S/MIME email users without having to ask users for further permission or information.

Key features of 389 Directory Server:

  • High performance with great scalability;
  • Active Directory user and group synchronization;
  • Four-way multi-master replication;
  • Secure authentication and transport (TLS and SASL);
  • Support for LDAPv3;
  • Graphical management console;
  • Extensive documentation;
  • Supports openLDAP API from Python.

Minuses:

  • Console writing in Java;
  • A bit informative web console, written in Java.

FreeIPA is an open-source identity management tool for Linux/Unix networked environments which provides a centralized solution for account authorization and authentication management. It is built on top of well known components and standard protocols with a strong focus on management and automation of installation and configuration tasks as well as storing data about users, groups, hosts, and other objects. FreeIPA provides simple to install and use command line and web based management tools for users and administrators in the Linux environment.

Data in the LDAP server can be modified with the help of a framework provided by FreeIPA. Both server and client sides are written in Python. Framework provides connection via CLI or a web-based user interface also it can be accessed in a programmatic way over HTTPS connection. It is possible to extend FreeIPA on multiple levels because core parts of the framework are implemented as pluggable modules.

For signing and publishing certificates for FreeIPA hosts and services there is an integrated PKI Service realized via the Dogtag project. For software validation of certificates also could be provided CRL and OCSP services. Requesting, showing and finding certificates available using API provided by the framework.

Infrastructure also needs to handle renewal of used by clients and services certificates because of its limited validity. This function is performed by Certmonger daemon running on all the clients.

FreeIPA is a combination of various open source technologies with both CLI and Web UI interfaces:

  • LDAP infrastructure based on the 389 Directory Server;
  • KDC - MIT Kerberos implementation;
  • PKI based on Dogtag certificate authority;
  • Samba libraries for Active Directory integration;
  • DNS Server based on BIND;
  • SSSD: a set of daemons to manage access to remote directories and authentication mechanism;
  • FreeIPA can be seamlessly integrated into an Active Directory environment via cross-realm Kerberos trust or user synchronization.

Capabilities:

  • Multiple servers can be configured in a domain;
  • Scalable from small office environments up to large enterprise installations;
  • Full multi-master infrastructure based on LDAP server as a main data store;
  • Single-Sign-on authentication is provided via the MIT Kerberos KDC;
  • Domain Names managing based on Bind DNS server;
  • Centralized management of security mechanisms like passwords, SSH Public Keys, SUDO rules, Access Control Rules, etc;
  • Advanced grouping mechanisms for network access restriction to services for specific users;
  • Delegation of administrative tasks to power users;
  • Integration into Active Directory environments;
  • Access all the machines with the same credentials and security settings for all users;
  • Ability for users to access personal files transparently from any machine in an authenticated and secure way;
  • Web UI and a command line interface to provide fully centralized management of administrative tasks and all the security aspects related to access control;
  • Python Framework to command LDAP server.

Minuses:

  • Need minimum 4GB Ram to install and work;
  • Console writing in Java.

FreeRADIUS is a modular, high performance free RADIUS suite.

This software provides authentication and authorization for a network in a centralized way, and minimizes the number of changes that have to be done when adding or deleting new users to a network. FreeRADIUS can authenticate users on systems such as 802.1x (WiFi), dialup, PPPoE, VPN’s, VoIP, and many others.

RADIUS suite is a standard package with numerous Operating Systems. It has binary packages for many others and available source which is known to build on almost anything. Production deployments include large scale installations comprising multiple AAA servers with over ten million users with millions of requests per day. It supports proxying requests, with load balancing and fail-over, also the ability for accessing different back-end databases. A lot of classes of authentication requests can trigger access to authorization databases (with cascaded fall back). Accounting data can be simultaneously recorded and stored in multiple databases and directories.

Features include:

  • Many vendor-specific attributes;
  • Supports all common authentication protocols;
  • Authentication on system passwd, SQL, Kerberos, LDAP, users file, or PAM;
  • PHP-based web user administration tool;
  • Request proxying with fail-over and load balancing;
  • Accesses many types of back-end databases such as MySQL, PostgreSQL, Oracle, Microsoft Active Directory, OpenLDAP, and many more;
  • Different classes of Authentication requests can trigger access to different Authentication and Authorization databases;
  • Virtual servers;
  • IPv6 support;
  • Proxying and replicating requests by any criteria;
  • VMPS support;
  • Limited support for HUP;
  • Server core is event based;
  • Simple policy language;
  • Multiple default configurations;
  • Access-based huntgroups;
  • Caching of all config files in memory;
  • Regexp matching in string attributes.

Proprietary authentication applications

Active Directory (AD) is a Microsoft company product that consists of several services that run on Windows Server. It helps to manage permissions and access to different resources in the network.

Data in Active Directory stored as objects. All the objects in AD, such as a user, group, application or device is a single element. Objects are normally defined as either resources -- such as printers or computers -- or security principals -- such as users or groups.

All the objects in AD are categorized by name and attributes. The name of a user might include the name string, along with information associated with the user, such as passwords and Secure Shell (SSH) keys.

Active Directory Domain Services (AD DS) are the core functions in Active Directory. Domain Service (AD DS) is main. It stores directory information and helps to handle interactions of the user with the domain. When a user signs into a device or tries to connect to a server over a network AD DS responsible for verifying access. AD DS manages access for users to specified resources. As an example, an administrator generally has more levels of access to data than an end user.

There are several benefits to using AD DS for your basic network user and computer management:

  • Possibility to customize how your data is organized to meet your companies needs;
  • Abling to manage AD DS from any computer on the network;
  • Built in replication and redundancy: if one Domain Controller (DC) fails, another DC picks up the load;
  • Access to network resources passing through AD DS, that making your network management centralized.

Here are the services that AD DS provides as the core functionality:

  • Domain Services: manages communications between the users and the DC and stores data;
  • Certificate Services: serving digital certificates, signatures, and public key cryptography;
  • Lightweight Directory Services: provides LDAP support for cross platform domain services, like any Linux computers;
  • Directory Federation Services: providing of SSO authentication for multiple applications in the same session for users;
  • Rights Management: controlling rights and data access policies and determining an access to a folder or sending an email.

Red Hat Directory Server consists of several components. Server implemented with LDAP protocol is the core of the directory. Red Hat DS supports a client-side GUI on top of the LDAP server that allows users to search and change records in the directory. Different LDAP clients, third-party and custom programs, written using the Mozilla LDAP SDK or the OpenLDAP SDK, can be used with Red Hat DS or could be integrated in it like applications.

Eliminating redundancy and automating data maintenance provides simplified user management. RedHat DS also improves security, enabling to store policies and access control information in the directory for a single authentication source across the network.

Installed Red Hat Directory Server has several elements:

  • The core Directory Server LDAP server: the LDAP v3-compliant network daemon with associated plug-ins, CLI tools, and configuration and schema files;
  • Administration Server: a web server to control the different portals that access the LDAP server;
  • Directory Server Console: a graphical management console to reduce the effort of setting up and maintaining the directory service;
  • SNMP agent: monitoring the DS with the usage of the Simple Network Management Protocol (SNMP).

Features overview:

  • Centralized management of users and their profiles to reduce administrative costs;
  • Multi-master replication of data across the environment, with a centralized, consistent data source available for enterprise applications;
  • Single sign-on (SSO) access;
  • Centralized repository for user profiles and preferences, with personalization of applications and systems enabled;
  • Scalability for massive numbers of users by containing the data control for developing extranet applications.

Cloud directory services is a cloud-based service for authorizing, managing, and authenticating user access to IT resources through device type, operating system, or with any web-based applications. Generally, it is an implementation of identity management and directory services. This service connects employees and users to IT resources and helps companies in storing and managing information about individual identities in a workflow.

Cloud directory services solutions support all main operating system platforms and provide secure connection to a unified cloud-based directory. With the help of Directory cloud-based solution admins can easier bond their employees to the IT resources. Directory services usually are at the center of the network, and are critical for a company's overall success as the primary network infrastructure itself.

Deploying software as a managed service delivered via the cloud means lower maintenance costs, increased uptime, faster feature rollout, and the reduced need for on-site hardware. Those are just some of the reasons why cloud-based SaaS solutions are making deep and fast inroads to tasks that were formerly dominated solely by in-house IT staff.

Cloud authentication applications

AWS boasts a huge, ever-growing range of products and services, and arguably the most comprehensive network of data centers the market currently has to offer.

Strengths
Weaknesses
Extensive range of infrastructure applications
Range of infrastructure options can be overwhelming for more traditional enterprises
Highly flexible
Hybrid options available, but not a priority
Easy transition for users with existing digital infrastructure
Organizations operating on legacy systems may experience longer migration times
Frequently updated and maintained
 
Free tier available
 
Greater control over security
 
Scalability
 
Cost-effective pricing model
 
Rapid deployment
 
Support for large enterprises
 

As a Microsoft product, Azure no doubt benefits from user familiarity with the brand, which creates an immediate preference for Azure among loyal Microsoft customers.

Strengths
Weaknesses
High availability
Requires considerable management
Strong focus on Security
Requires platform expertise
Scalability
More limited backward compatibility
Cost-effective
Comparatively more costly than other leading vendors
Strong IaaS and PaaS options
Additional charge for pay-as-you-go option
Support for open source
Customer service
Hybrid cloud
Less enterprise-ready

It gives customers a highly-specialized service in three main streams: big data, machine learning, and analytics, with good scale and stable load balancing, as well as those famously low response times.

Strengths
Weaknesses
Excellent integration with other Google services
Majority of components based on Google proprietary tech; no real control over Virtual Machines
Fast I/O
Limited choice of programming languages
Strong data analytics and storage
Complex transition away from the platform to another vendor
Facilitates easy collaboration
Fewer features/services
Designed for cloud-native business
Fewer global data centers
Good portability and open source integration
 

Comparison table of most popular server central authentication applications

  OpenLDAP 389 DS FreeIPA FreeRadius MS AD
SELinux partially full full no no
SSH keys optional optional yes yes yes
Sudo rules yes yes, sudo schemas yes, sudo schemas yes yes
Password policies yes yes yes yes yes, Domain Policy
Certificate handling (TLS) yes yes yes yes yes
Multi factor authentication yes yes yes yes yes

Authentication client applications

The System Security Services Daemon (SSSD) is a system service to provide access to remote directories and authentication mechanisms. It’s primary function is providing a connection between a local system and an external back-end system. This provides the SSSD client with access to identity and authentication remote services using an SSSD provider. For example, it could be: an LDAP directory, an Identity Management (IdM) or Active Directory (AD) domain, or a Kerberos realm. It can also ensure caching and offline support for the system using Name Service Switch (NSS) or Pluggable Authentication Modules (PAM).

For this purpose, SSSD:

  • Provides connection for the client to an identity store for retrieving authentication information;
  • Obtain authentication information to create a local cache of users and credentials on the client;
  • Provides ability to authenticate users on the local system using stored in the external back-end system accounts;
  • Instead of creating user accounts on the local system, SSSD uses identities from the external database for providing access to the local system.

Some of the benefits:

  • Load on identity and authentication servers is reduced. While requests, SSSD clients contact SSSD, which checks its cache. SSSD contacts the servers only if the information is not available in the cache;
  • Ability for offline authentication. SSSD can optionally keep a cache of user identities and credentials retrieved from remote services. This setup gives a possibility for successful authentication to resources even if the remote server or the SSSD client are in offline state;
  • A single user account. A central account and a local user account don’t need to be both maintained for offline authentication with SSSD;
  • With caching and offline authentication support, remote users have connection to network resources simply by authenticating to their local machine. Their network credentials will be maintained by SSSD.

SSSD could be run on different Linux platforms:

  • Fedora Project - platform used by the original developers;
  • Red Hat Enterprise Linux;
  • Ubuntu;
  • Debian;
  • CentOS;
  • OpenSUSE;
  • Mandriva;
  • Gentoo;
  • Arch Linux via AUR.

Another daemon which can be interposed between the LDAP client and server is the Name Service LDAP Connection Daemon (nslcd). It is specifically designed as an interface between LDAP clients and servers; nothing else. Principal difference from SSSD is that it is not a caching daemon.

The suite of OpenLDAP libraries and tools for LDAP directory management:

  • Openldap—necessary libraries to run the OpenLDAP server and client applications;
  • Openldap-clients — command line tools for viewing and modifying directories on an LDAP server;
  • Openldap-servers — servers and other utilities necessary to configure and run an LDAP server.

The openldap-clients package installs are used to add, modify, and delete entries in an LDAP directory.

Comparison table of most popular client central authentication applications

  NSCD NSLCD SSSD
SSO yes yes yes
Offline login no no yes
Connect to multiple different account sources no no yes
Secure LDAP connection yes yes yes
Support filter (who can connect) no no yes

How we test and configure central authentication server for internal use

We start to think about internal central authentication systems when the number of servers starts to increase into a large number. Very often, you have to manage a lot of ssh keys on a large amount of servers when employees leave or enter a company and it takes a lot of time. Also, users can personally create multiple accounts on internal or external servers and the problem often is in missing information about the user's access rights when he leaves a company. In such situations administrators have to check all the servers for personal user accounts and delete them. Central authentication server greatly assists system administrators during every-day workflow because all the needed information is stored in one centralized place.

Our requirements for central authorization software

  1. Abling to store all user accounts in one place.
  2. Сontrol for SSH keys.
  3. Control for access to servers via SSH.
  4. Possibility to disable access to servers for users in one place.
  5. Storing authentication logs in one place.
  6. Control sudo access rights.

The FreeIPA server installation process is very simple on Fedora, Centos and Ubuntu systems because all packages are placed in repositories. Minimum hardware system requirements for FreeIPA server installation is 4 GB RAM. FreeIPA server includes an openldap directory for storing users data.

Restricting or granting access rights for users to specific resources in the network is managed by ACL (Access Control List). ACL provides a flexible mechanism to manage access rights for network resources with the possibility to organize users and servers to groups. So, permission settings can be applied to a whole group and not only for a one user or server.

We tested the FreeIPA server on Ubuntu and CentOS systems. CentOS system showed better performance.

To install FreeIPA server packages on ubuntu, perform next steps:

  1. Set hostname;
  2. Update system;
  3. Install and configure rng-tools to achieve high entropy, because of a big amount of cryptographic operations performing on running Freeipa server. Your VM must have enough entropy to ensure that FreeIPA cryptographic operations won’t stall. To configure rng-tools: in /etc/default/rng-tools file should be added string HRNGDEVICE=/dev/urandom to use /dev/urandomas input source for random data;
  4. Enable and start rng-tool;
  5. Install FreeIPA server with command:
    sudo apt install -y Freeipa-server
  6. To setup FreeIPA server execute next command, this will prompt you to a number of configuration options for FreeIPA server installation:
    sudo ipa-server-install
  7. When FreeIPA server setup is completed, open required ports for FreeIPA server services through the firewall. If ufw already installed, enable it and start with command:
    sudo systemctl enable ufw
    sudo systemctl start ufw
  8. Next, open all required TCP ports for FreeIPA:
    for i in 80 443 389 636 88 464; do sudo ufw allow proto tcp from any to any port $i; done
    Also, do the same for UDP ports:
    for i in 88 464 123; do sudo ufw allow proto udp from any to any port $i; done
  9. After finishing with configuration of required open ports reload ufw:
    sudo ufw reload
    

After installing and configuring FreeIPA, all machines in the network can be easily connected to the server with client application. Hostname will be automatically added to the directory when the client machine connects to FreeIPA server. All hosts could be viewed and managed through the FreeIPA console.

Freeipa-client installation package already includes dependencies to sssd, krb5 and nsswitch applications. SSSD provides an access from the client machine to FreeIPA directory and returns authentication data from the server. Krb5 package provides authentication mechanism for kerberos protocol if it is enabled in FreeIPA server configuration.

To setup freeip-client you need to execute next command, this will prompt you to a number of configuration options for setting up freeipa-client for FreeIPA server connection:

ipa-client-install --mkhomedir --force-ntpd

Nsswitch, sssd and krb5 packages will be set up automatically during the installation process without any additional configuration.

After completing tests of FreeIPA functionality, we analyzed all the received information and came to the conclusion that some of the functionality is very demanding for resources used.

FreeIPA is flexible software with useful functionality and suitable cli application, but has a heavy-weight java console which is too demanding to hardware.

The 389 Directory server has a very simple installation process in Fedora and CentOS based distributives. For CentOS 7 system, first of all, perform pre-requirements steps to configure base system:

  1. Configure hostname and add hostname record to /etc/hostsfile;
  2. Create /etc/sysctl.d/10-ldap.conffile and add config lines to it:
    net.ipv4.tcp_keepalive_time = 300
    net.ipv4.ip_local_port_range = 1024 65000
    fs.file-max = 64000
  3. Edit /etc/security/limits.conf file, add lines at the bottom of it:
    * soft nofile 8192
    * hard nofile 8192
  4. Edit /etc/profile file, add line at the end of it:
    ulimit -n 8192
  5. At the end of /etc/pam.d/login file add string:
    session required /lib/security/pam_limits.so
  6. Restart the server.

To install 389 Directory server packages perform next steps:

  1. Install epel & remi repository:
    yum install -y epel-release
    wget http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
    rpm -Uvh remi-release-7.rpm
  2. Add LDAP user with a password set:
    useradd ldapadmin
    passwd ldapadmin
  3. Install 389-ds and required dependency packages:
    yum install -y \
    389-ds-base \
    openldap-clients \
    idm-console-framework \
    389-adminutil \
    389-admin \
    389-admin-console \
    389-console \
    389-ds-console
  4. Setup 389-ds and admin servers with executing perl script: setup-ds-admin.pl This will prompt you to a number of configuration options for setting up 389 DS and admin servers;
  5. After completing the setup of admin and directory servers, enable and start them with commands:
    systemctl enable dirsrv.target
    systemctl enable dirsrv-admin
    systemctl start dirsrv.target
    systemctl start dirsrv-admin
  6. After starting 389-ds services, check that ldap directory is available with command:
    ldapsearch

Next, security for ldap connection must be enabled and configured. It could be done in 2 ways:

  • From the 389-ds console.
  • With ldapmodify command from terminal.
  1. To start ldap secure connection, add CA certificate to ldap directory server. CA certificates can be configured with Let’s encrypt utility program;
  2. Add recently created CA certificates to a specific certificate directory, and for security reasons this directory should be protected by pin or password;
  3. On client own servers we are using SSSD daemon. SSSD daemon has a very simple installation process, just need to install next packages:
    sssd
    sssd-client
    libpam-sss
    libnss-sss
  4. After completing the installation of the packages, edit /etc/nsswitch.conf file, need to add the ldap directive to the passwd, group and shadow databases;
  5. After completing the nsswitch configuration, edit /etc/sssd/sssd.conffile. In the domain section specify settings for connection to ldap server. Add a path to the certificate file toldap_tls_cacertfield to use a secure ldap connection;
  6. When the sssd configuration file is ready, go for /etc/ldap/ldap.conffile for some edit. Add a fieldTLS_CACERTto it with a path to certificate file;
  7. To enable PAM (Pluggable Authentication Modules) for SSSD daemon:
    Edit /etc/pam.d/password-authfile, add strings below:
    auth sufficient pam_sss.so use_first_pass
    account [default=bad success=ok user_unknown=ignore] pam_sss.so
    password sufficient pam_sss.so use_authtok
    session optional pam_sss.so
    Edit/etc/pam.d/system-authfile, add strings below:
    auth sufficient pam_sss.so use_first_pass
    account [default=bad success=ok user_unknown=ignore] pam_sss.so
    password sufficient pam_sss.so use_authtok
    session optional pam_sss.so
  8. To start connection to server with ldap user just restart sssd service:
    systemctl restart sssd.service

Conclusion

In our company we chose to work with 389 Directory Server (389DS), because it is lightweight in amount of written code solution that fully meets our requirements. We use 389DS to manage accounts and provide for users access to servers via ssh security protocol. 389DS has ACL (access control list) rules that provide mechanisms to control access rights for each user. It also has GUI and CLI support to manage LDAP databases.

From the client side we use SSSD (System Security Services Daemon). Once configured, it provides access to the client machine using LDAP users database. In SSSD you can add a feature to archive user data during programmable time. With this feature enabled users could be authorized on the server using 389DS archived accounts even if the server doesn’t respond.

We added a new object “sshPublicKey” to the 389DS database to add users' public keys for LDAP accounts records. On the client side, a custom written bash script gets ssh public keys from 389DS and adds new configuration strings in sshd_config using ldapsearch command.