4 Setting Up Authentication Servers and Clients Using YaST #
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 6, Network Authentication with Kerberos.
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.
Start YaST as
root
and select › to invoke the configuration wizard.Configure the Figure 4.1, “YaST Authentication Server Configuration”:
of your LDAP server (you can change these settings later)—seeFigure 4.1: YaST Authentication Server Configuration #Set LDAP to be started.
If the LDAP server should announce its services via SLP, check
.Configure
.Click
.
Select the server type:
, , or .Select security options (
).It is strongly recommended to Procedure 4.2, “Editing Authentication Server Configuration”, Step 4.
. For more information, seeWarning: Authentication Without EncryptionWhen using authentication without enabling transport encryption using TLS, the password will be transmitted in the clear.
Also consider using LDAP over SSL with certificates.
Confirm Figure 4.2, “YaST LDAP Server—New Database”.
with entering an and then clicking —seeFigure 4.2: YaST LDAP Server—New Database #In the Figure 4.3, “YaST Kerberos Authentication”.
dialog, decide whether to enable Kerberos authentication or not (you can change these settings later)—seeFigure 4.3: YaST Kerberos Authentication #Choose whether Kerberos support is needed or not. If you enable it, also specify your
. Then confirm with .The
allows you to specify various aspects such as or ports to use.
Finally, check the
and click 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 Figure 4.4, “YaST Editing Authentication Server Configuration”:
to make subentries visible—seeWith
, 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.Configure which connection types the server should offer under
. 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.
- 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.
To configure secure communication between client and server, proceed with
:Activate
to enable TLS and SSL encryption of the client/server communication.- by specifying the exact path to its location or enable the . If the is not available, because it has not been created during installation, go for first—for more information, see
Add Schema files to be included in the server's configuration by selecting
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.
To configure the databases managed by your LDAP server, proceed as follows:
Select the
item in the left part of the dialog.Click
to add a new database.Specify the requested data:
Enter the base DN (distinguished name) of your LDAP server.
Enter the DN of the administrator in charge of the server. If you check
, only provide thecn
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.
In the next dialog, configure replication settings.
In the next dialog, enable enforcement of password policies to provide extra security to your LDAP server:
Check
to be able to specify a password policy.Activate
to have clear text passwords be hashed before they are written to the database whenever they are added or modified.- Warning: Locked Accounts in Security Sensitive Environments
Do not use the “Locked Account” error message provides security-sensitive information that can be exploited by a potential attacker.
option if your environment is sensitive to security issues, because the 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.
Complete the database configuration by clicking
.
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:
Enter the LDAP server password. In the navigation tree below
expand your database object and activate the item.Make sure
is activated. Then click .Configure the password change policies:
Determine the number of passwords stored in the password history. Saved passwords may not be reused by the user.
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).
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
, users are allowed to use encrypted passwords, even though the quality checks cannot be performed. If you opt for only those passwords that pass the quality tests are accepted as valid.
Configure the password time-limit policies:
Determine the minimum password time-limit (the time that needs to pass between two valid password changes) and the maximum password time limit.
Determine the time between a password expiration warning and the actual password expiration.
Set the number of postponement uses of an expired password before the password expires permanently.
Configure the lockout policies:
Enable password locking.
Determine the number of bind failures that trigger a password lock.
Determine the duration of the password lock.
Determine the length of time that password failures are kept in the cache before they are purged.
Apply your password policy settings with
.
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
, 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:
Use both an identity service (usually LDAP) and a user authentication service (usually Kerberos). This option is based on SSSD and in the majority of cases is best suited for joining Active Directory domains. .
This module is described in Section 7.3.2, “Joining Active Directory Using . ”
Join an Active Directory (which entails use of Kerberos and LDAP). This option is based on .
winbind
and is best suited for joining an Active Directory domain if support for NTLM or cross-forest trusts is necessary.This module is described in Section 7.3.3, “Joining Active Directory Using . ”
Allows setting up LDAP identities and Kerberos authentication independently from each other and provides fewer options. While this module also uses SSSD, it is not as well suited for connecting to Active Directory as the previous two options. .
This module is described in:
4.3 SSSD #
Two of the YaST modules are based on SSSD:
and .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.