openSUSE Leap Documentation › Security Guide › Authentication › Setting Up Authentication Servers and Clients Using YaST
ContentsContents
Security Guide
  1. About This Guide
  2. 1 Security and Confidentiality
  3. I Authentication
    1. 2 Authentication with PAM
    2. 3 Using NIS
    3. 4 Setting Up Authentication Servers and Clients Using YaST
    4. 5 LDAP—A Directory Service
    5. 6 Network Authentication with Kerberos
    6. 7 Active Directory Support
  4. II Local Security
    1. 8 Configuring Security Settings with YaST
    2. 9 Authorization with PolKit
    3. 10 Access Control Lists in Linux
    4. 11 Encrypting Partitions and Files
    5. 12 Certificate Store
    6. 13 Intrusion Detection with AIDE
  5. III Network Security
    1. 14 SSH: Secure Network Operations
    2. 15 Masquerading and Firewalls
    3. 16 Configuring a VPN Server
    4. 17 Managing X.509 Certification
  6. IV Confining Privileges with AppArmor
    1. 18 Introducing AppArmor
    2. 19 Getting Started
    3. 20 Immunizing Programs
    4. 21 Profile Components and Syntax
    5. 22 AppArmor Profile Repositories
    6. 23 Building and Managing Profiles with YaST
    7. 24 Building Profiles from the Command Line
    8. 25 Profiling Your Web Applications Using ChangeHat
    9. 26 Confining Users with pam_apparmor
    10. 27 Managing Profiled Applications
    11. 28 Support
    12. 29 AppArmor Glossary
  7. V SELinux
    1. 30 Configuring SELinux
  8. VI The Linux Audit Framework
    1. 31 Understanding Linux Audit
    2. 32 Setting Up the Linux Audit Framework
    3. 33 Introducing an Audit Rule Set
    4. 34 Useful Resources
  9. A GNU Licenses
Navigation←→
openSUSE Leap Documentation › Security Guide › Authentication › Setting Up Authentication Servers and Clients Using YaST
Top
←→
Applies to openSUSE Leap 42.3

4 Setting Up Authentication Servers and Clients Using YaST

Abstract

The Authentication Server is based on LDAP and optionally Kerberos. On openSUSE Leap you can configure it with a YaST wizard.

For more information about LDAP, see Chapter 5, LDAP—A Directory Service, and about Kerberos, see Chapter 6, Network Authentication with Kerberos.

4.1 Configuring an Authentication Server with YaST
4.2 Configuring an Authentication Client with YaST
4.3 SSSD

4.1 Configuring an Authentication Server with YaST

4.1.1 Initial Configuration of an Authentication Server

To set up an authentication server for user account data, make sure the yast2-auth-server, openldap2, krb5-server, and krb5-client packages are installed; YaST will remind you and install them if one of these packages is missing. For Kerberos support, the krb5-plugin-kdb-ldap package is required.

The first part of the Authentication Server configuration with YaST is setting up an LDAP server, then you can enable Kerberos.

Procedure 4.1: Authentication Server Configuration with YaST

  1. Start YaST as root and select Network Services › Authentication Server to invoke the configuration wizard.

  2. Configure the Global Settings of your LDAP server (you can change these settings later)—see Figure 4.1, “YaST Authentication Server Configuration”:

    YaST Authentication Server Configuration
    Figure 4.1: YaST Authentication Server Configuration

    1. Set LDAP to be started.

    2. If the LDAP server should announce its services via SLP, check Register at an SLP Daemon.

    3. Configure Firewall Settings.

    4. Click Next.

  3. Select the server type: Stand-alone server, Master server in a replication setup, or Replica (slave) server.

  4. Select security options (TLS Settings).

    It is strongly recommended to Enable TLS. For more information, see Procedure 4.2, “Editing Authentication Server Configuration”, Step 4.

    Warning
    Warning: Authentication Without Encryption

    When using authentication without enabling transport encryption using TLS, the password will be transmitted in the clear.

    Also consider using LDAP over SSL with certificates.

  5. Confirm Basic Database Settings with entering an LDAP Administrator Password and then clicking Next—see Figure 4.2, “YaST LDAP Server—New Database”.

    YaST LDAP Server—New Database
    Figure 4.2: YaST LDAP Server—New Database

  6. In the Kerberos Authentication dialog, decide whether to enable Kerberos authentication or not (you can change these settings later)—see Figure 4.3, “YaST Kerberos Authentication”.

    YaST Kerberos Authentication
    Figure 4.3: YaST Kerberos Authentication

  7. Choose whether Kerberos support is needed or not. If you enable it, also specify your Realm. Then confirm with Next.

    1. The Advanced Configuration allows you to specify various aspects such as Maximum ticket life time or ports to use.

  8. Finally, check the Authentication Server Configuration Summary and click Finish to exit the configuration wizard.

4.1.2 Editing an Authentication Server Configuration with YaST

For changes or additional configuration start the Authentication Server module again and in the left pane expand Global Settings to make subentries visible—see Figure 4.4, “YaST Editing Authentication Server Configuration”:

YaST Editing Authentication Server Configuration
Figure 4.4: YaST Editing Authentication Server Configuration
Procedure 4.2: Editing Authentication Server Configuration

  1. With Log Level Settings, configure the degree of logging activity (verbosity) of the LDAP server. From the predefined list, select or deselect logging options according to your needs. The more options are enabled, the larger your log files grow.

  2. Configure which connection types the server should offer under Allow/Disallow Features. Choose from:

    LDAPv2 Bind Requests

    This option enables connection requests (bind requests) from clients using the previous version of the protocol (LDAPv2).

    Anonymous Bind When Credentials Not Empty

    Normally, the LDAP server denies any authentication attempts with empty credentials, that is, a distinguished name (DN) or a password. However, enabling this option makes it possible to connect with a password and no DN to establish an anonymous connection.

    Unauthenticated Bind When DN Not Empty

    Enabling this option makes it possible to connect without authentication (anonymously) using a distinguished name (DN) but no password.

    Unauthenticated Update Options to Process

    Enabling this option allows non-authenticated (anonymous) update operations. Access is restricted according to ACLs and other rules.

  3. Allow/Disallow Features also lets you configure the server flags. Choose from:

    Disable Acceptance of Anonymous Bind Requests

    The server will no longer accept anonymous bind requests. Note, that this does not generally prohibit anonymous directory access.

    Disable Simple Bind Authentication

    Completely disable Simple Bind authentication.

    Disable Forcing Session to Anonymous Status upon StartTLS Operation Receipt

    The server will no longer force an authenticated connection back to the anonymous state when receiving the StartTLS operation.

    Disallow the StartTLS Operation if Authenticated

    The server will disallow the StartTLS operation on already authenticated connections.

  4. To configure secure communication between client and server, proceed with TLS Settings:

    1. Activate Enable TLS to enable TLS and SSL encryption of the client/server communication.

    2. Either Import Certificate by specifying the exact path to its location or enable the Use Common Server Certificate. If the Use Common Server Certificate is not available, because it has not been created during installation, go for Launch CA Management Module first—for more information, see Section 17.2, “YaST Modules for CA Management”.

Add Schema files to be included in the server's configuration by selecting Schema Files in the left part of the dialog. The default selection of schema files applies to the server providing a source of YaST user account data.

YaST allows to add traditional Schema files (usually with a name ending in .schema) or LDIF files containing Schema definitions in OpenLDAP's LDIF Schema format.

YaST Authentication Server Database Configuration
Figure 4.5: YaST Authentication Server Database Configuration

To configure the databases managed by your LDAP server, proceed as follows:

  1. Select the Databases item in the left part of the dialog.

  2. Click Add Database to add a new database.

  3. Specify the requested data:

    Base DN

    Enter the base DN (distinguished name) of your LDAP server.

    Administrator DN

    Enter the DN of the administrator in charge of the server. If you check Append Base DN, only provide the cn of the administrator and the system fills in the rest automatically.

    LDAP Administrator Password

    Enter the password for the database administrator.

    Use This Database as the Default for OpenLDAP Clients

    For convenience, check this option if wanted.

  4. In the next dialog, configure replication settings.

  5. In the next dialog, enable enforcement of password policies to provide extra security to your LDAP server:

    1. Check Enable Password Policies to be able to specify a password policy.

    2. Activate Hash Clear Text Passwords to have clear text passwords be hashed before they are written to the database whenever they are added or modified.

    3. Disclose "Account Locked" Status provides a relevant error message for bind requests to locked accounts.

      Warning
      Warning: Locked Accounts in Security Sensitive Environments

      Do not use the Disclose "Account Locked" Status option if your environment is sensitive to security issues, because the “Locked Account” error message provides security-sensitive information that can be exploited by a potential attacker.

    4. Enter the DN of the default policy object. To use a DN other than the one suggested by YaST, enter your choice. Otherwise, accept the default settings.

  6. Complete the database configuration by clicking Finish.

If you have not opted for password policies, your server is ready to run at this point. If you have chosen to enable password policies, proceed with the configuration of the password policy in detail. If you have chosen a password policy object that does not yet exist, YaST creates one:

  1. Enter the LDAP server password. In the navigation tree below Databases expand your database object and activate the Password Policy Configuration item.

  2. Make sure Enable Password Policies is activated. Then click Edit Policy.

  3. Configure the password change policies:

    1. Determine the number of passwords stored in the password history. Saved passwords may not be reused by the user.

    2. Determine if users can change their passwords and if they will need to change their passwords after a reset by the administrator. Require the old password for password changes (optional).

    3. Determine whether and to what extent passwords should be subject to quality checking. Set the minimum password length that must be met before a password is valid. If you select Accept Uncheckable Passwords, users are allowed to use encrypted passwords, even though the quality checks cannot be performed. If you opt for Only Accept Checked Passwords only those passwords that pass the quality tests are accepted as valid.

  4. Configure the password time-limit policies:

    1. Determine the minimum password time-limit (the time that needs to pass between two valid password changes) and the maximum password time limit.

    2. Determine the time between a password expiration warning and the actual password expiration.

    3. Set the number of postponement uses of an expired password before the password expires permanently.

  5. Configure the lockout policies:

    1. Enable password locking.

    2. Determine the number of bind failures that trigger a password lock.

    3. Determine the duration of the password lock.

    4. Determine the length of time that password failures are kept in the cache before they are purged.

  6. Apply your password policy settings with OK.

To edit a previously created database, select its base DN in the tree to the left. In the right part of the window, YaST displays a dialog similar to the one used for the creation of a new database (with the main difference that the base DN entry is grayed out and cannot be changed).

After leaving the Authentication Server configuration by selecting Finish, you are ready to go with a basic working configuration for your Authentication Server. To fine-tune this setup, use OpenLDAP's dynamic configuration back-end.

The OpenLDAP's dynamic configuration back-end stores the configuration in an LDAP database. That database consists of a set of .ldif files in /etc/openldap/slapd.d. There is no need to access these files directly. To access the settings you can either use the YaST Authentication Server module (the yast2-auth-server package) or an LDAP client such as ldapmodify or ldapsearch. For more information on the dynamic configuration of OpenLDAP, see the “OpenLDAP Administration Guide”.

4.1.3 Editing LDAP Users and Groups

For editing LDAP users and groups with YaST, see Section 5.4, “Configuring LDAP Users and Groups in YaST”.

4.2 Configuring an Authentication Client with YaST

YaST allows setting up authentication to clients using different modules:

4.3 SSSD

Two of the YaST modules are based on SSSD: User Logon Management and LDAP and Kerberos Authentication.

SSSD stands for System Security Services Daemon. SSSD talks to remote directory services that provide user data and provides various authentication methods, such as LDAP, Kerberos, or Active Directory (AD). It also provides an NSS (Name Service Switch) and PAM (Pluggable Authentication Module) interface.

SSSD can locally cache user data and then allow users to use the data, even if the real directory service is (temporarily) unreachable.

4.3.1 Checking the Status

After running one of the YaST authentication modules, you can check whether SSSD is running with: 

systemctl status sssd
sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled)
   Active: active (running) since Thu 2015-10-23 11:03:43 CEST; 5s ago
   [...]

4.3.2 Caching

To allow logging in when the authentication back-end is unavailable, SSSD will use its cache even if it was invalidated. This happens until the back-end is available again.

To invalidate the cache, run sss_cache -E (the command sss_cache is part of the package sssd-tools).

To completely remove the SSSD cache, run: 

systemctl stop sssd
rm -f /var/lib/sss/db/*
systemctl start sssd

4.3.3 For More Information

For more information, see the SSSD man pages sssd.conf (man sssd.conf) and sssd (man sssd). There are also man pages for most SSSD modules.

→Chapter 5 LDAP—A Directory Service←Chapter 3 Using NIS
Print this page

© 2018 SUSE