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 Active Directory Support
    6. 7 Network Authentication with Kerberos
  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.2

4 Setting Up Authentication Servers and Clients Using YaST

Abstract

The Authentication Server is based on LDAP and optionally Kerberos. On SUSE Linux Enterprise Server, 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 7, Network Authentication with Kerberos.

4.1 Configuring an Authentication Server with YaST
4.2 Configuring an Authentication Client with YaST (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: Password Encryption

    Enabling TLS ensures passwords are sent encrypted over the network. If this option is not enabled, passwords are sent unencrypted.

    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 (DN or password). Enabling this option, however, 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 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. Enter the requested data:

    Base DN

    Enter the base DN 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.3, “Configuring LDAP Users and Groups in YaST”.

4.2 Configuring an Authentication Client with YaST (SSSD)

YaST includes the LDAP and Kerberos Client module that helps with defining authentication scenarios. Start the module by selecting Network Services › Authentication Client. The YaST Authentication Client is a shell for configuring the System Security Services Daemon (SSSD). SSSD then can talk to remote directory services that provide user data, and provide various authentication methods. This way, the host can be both, an LDAP or an Active Directory (AD) client. SSSD can locally cache these user data and then allow users to use of the data, even if the real directory service is (temporarily) unreachable. An NSS (Name Service Switch) and PAM (Pluggable Authentication Module) interface are also available.

Authentication Client Configuration
Figure 4.6: Authentication Client Configuration

First you must configure at least one authentication domain. An authentication domain is a database that contains user information. Click New Service/Domain, select Domain, and as the Domain Name of the new domain enter an arbitrary name (alphanumeric ASCII characters, dashes, and underscores are allowed). Then select one of the available identification providers and finally select the authentication provider to be used for that domain. For example, if you want to access an LDAP directory with kerberos authentication, select ldap as the identification provider and krb5 as the authentication provider and leave Activate Domain enabled (see Figure 4.7, “Authentication Client: Adding New Domain (LDAP and Kerberos)”).

Authentication Client: Adding New Domain (LDAP and Kerberos)
Figure 4.7: Authentication Client: Adding New Domain (LDAP and Kerberos)

In the next step you see that id_provider and auth_provider are properly selected. Now you need to set some mandatory parameters for these providers. In the LDAP/Kerberbos scenario for example, ldap://ldap.example.com as the URIs of LDAP Servers, the IP address of the Kerberbos server (192.168.1.114 as IP address or host names of Kerberos servers), and EXAMPLE.COM as Kerberos realm (normally, your Kerberos realm is your domain name in uppercase letters). Then confirm.

Authentication Client: Mandatory Parameters (LDAP and Kerberos)
Figure 4.8: Authentication Client: Mandatory Parameters (LDAP and Kerberos)

For more information and additional configuration option the SSSD man pages such as sssd.conf (man sssd.conf) and sssd-ldap (man sssd-ldap). It is also possible to select later all parameters available for the selected identification and authentication providers.

Note
Note: TLS

If you use LDAP, TLS is mandatory. Do not select ldap_tls_reqcert, if an official certificate is not available.

SSSD provides following identification providers:

proxy

Support a legacy NSS provider.

local

SSSD internal provider for local users.

ldap

LDAP provider. See sssd-ldap(5) for more information on configuring LDAP.

ipa

FreeIPA and Red Hat Enterprise Identity Management provider.

ad

Active Directory provider.

Supported authentication providers are:

ldap

Native LDAP authentication.

krb5

Kerberos authentication.

ipa

FreeIPA and Red Hat Enterprise Identity Management provider.

ad

Active Directory provider.

proxy

Relaying authentication to some other PAM target.

none

Disables authentication explicitly.

If you enter more than one authentication domain, SSSD will query one after the one in the order they appear in the /etc/sssd/sssd.conf configuration file. If a domain is rarely used and you need to avoid waiting for the timeout, remove it from the Domains list of the sssd section.

Clicking one of the listed Services at the left side, allows you to edit sssd.conf sections such as nss or pam.

If you click OK in the main Authentication Client dialog, YaST will enable and start the SSSD service. You can check it on the command line 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
   ...

To allow login when the authentication back-end is unavailable, SSSD will continue to use its cache even if it was invalidated. SSSD still operates 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
→Chapter 5 LDAP—A Directory Service←Chapter 3 Using NIS
Print this page

© 2018 SUSE