Ce contenu n'est pas disponible dans la langue sélectionnée.
System-Level Authentication Guide
Using applications and services to configure authentication on local systems
Abstract
The Linux Domain Identity, Authentication, and Policy Guide documents Red Hat Identity Management, a solution that provides a centralized and unified way to manage identity stores as well as authentication and authorization policies in a Linux-based domain.
The Windows Integration Guide documents how to integrate Linux domains with Microsoft Windows Active Directory (AD) using Identity Management. Among other topics, the guide covers various aspects of direct and indirect AD integration, using SSSD to access a Common Internet File System (CIFS), and the realmd
system.
Chapter 1. Introduction to System Authentication
1.1. Confirming User Identities
- Password-based authentication. Almost all software permits the user to authenticate by providing a recognized name and password. This is also called simple authentication.
- Certificate-based authentication. Client authentication based on certificates is part of the SSL protocol. The client digitally signs a randomly generated piece of data and sends both the certificate and the signed data across the network. The server validates the signature and confirms the validity of the certificate.
- Kerberos authentication. Kerberos establishes a system of short-lived credentials, called ticket-granting tickets (TGTs). The user presents credentials, that is, user name and password, that identify the user and indicate to the system that the user can be issued a ticket. TGT can then be repeatedly used to request access tickets to other services, like websites and email. Authentication using TGT allows the user to undergo only a single authentication process in this way.
- Smart card-based authentication. This is a variant of certificate-based authentication. The smart card (or token) stores user certificates; when a user inserts the token into a system, the system can read the certificates and grant access. Single sign-on using smart cards goes through three steps:
- A user inserts a smart card into the card reader. Pluggable authentication modules (PAMs) on Red Hat Enterprise Linux detect the inserted smart card.
- The system maps the certificate to the user entry and then compares the presented certificates on the smart card, which are encrypted with a private key as explained under the certificate-based authentication, to the certificates stored in the user entry.
- If the certificate is successfully validated against the key distribution center (KDC), then the user is allowed to log in.
Smart card-based authentication builds on the simple authentication layer established by Kerberos by adding certificates as additional identification mechanisms as well as by adding physical access requirements.
1.2. As Part of Planning Single Sign-On
- Kerberos-based authentication, through both Kerberos realms and Active Directory domains
- Smart card-based authentication
1.3. Available Services
- Authentication Setup
- The Authentication Configuration tool (
authconfig
) sets up different identity back ends and means of authentication (such as passwords, fingerprints, or smart cards) for the system.
- Identity Back End Setup
- The Security System Services Daemon (SSSD) sets up multiple identity providers (primarily LDAP-based directories such as Microsoft Active Directory or Red Hat Enterprise Linux IdM) which can then be used by both the local system and applications for users. Passwords and tickets are cached, allowing both offline authentication and single sign-on by reusing credentials.
- The
realmd
service is a command-line utility that allows you to configure an authentication back end, which is SSSD for IdM. Therealmd
service detects available IdM domains based on the DNS records, configures SSSD, and then joins the system as an account to a domain. - Name Service Switch (NSS) is a mechanism for low-level system calls that return information about users, groups, or hosts. NSS determines what source, that is, which modules, should be used to obtain the required information. For example, user information can be located in traditional UNIX files, such as the
/etc/passwd
file, or in LDAP-based directories, while host addresses can be read from files, such as the/etc/hosts
file, or the DNS records; NSS locates where the information is stored.
- Authentication Mechanisms
- Pluggable Authentication Modules (PAM) provide a system to set up authentication policies. An application using PAM for authentication loads different modules that control different aspects of authentication; which PAM module an application uses is based on how the application is configured. The available PAM modules include Kerberos, Winbind, or local UNIX file-based authentication.
Part I. System Logins
authconfig
, ipa-client-install
, and realmd
tools.
Chapter 2. Configuring System Authentication
- the
ipa-client-install
utility and therealmd
system for Identity Management systems; see Section 2.1, “Identity Management Tools for System Authentication” for more information - the
authconfig
utility and the authconfig UI for other systems; see Section 2.2, “Usingauthconfig
” for more information
2.1. Identity Management Tools for System Authentication
ipa-client-install
utility and the realmd
system to automatically configure system authentication on Identity Management machines.
ipa-client-install
- The
ipa-client-install
utility configures a system to join the Identity Management domain as a client machine. For more information aboutipa-client-install
, see the Installing a Client in the Linux Domain Identity, Authentication, and Policy Guide.Note that for Identity Management systems,ipa-client-install
is preferred overrealmd
. realmd
- The
realmd
system joins a machine to an identity domain, such as an Identity Management or Active Directory domain. For more information aboutrealmd
, see the Using realmd to Connect to an Active Directory Domain section in the Windows Integration Guide.
2.2. Using authconfig
authconfig
tool can help configure what kind of data store to use for user credentials, such as LDAP. On Red Hat Enterprise Linux, authconfig
has both GUI and command-line options to configure any user data stores. The authconfig
tool can configure the system to use specific services — SSSD, LDAP, NIS, or Winbind — for its user database, along with using different forms of authentication mechanisms.
Important
ipa-client-install
utility or the realmd
system instead of authconfig
. The authconfig
utilities are limited and substantially less flexible. For more information, see Section 2.1, “Identity Management Tools for System Authentication”.
authconfig
utilities are available for configuring authentication settings:
authconfig-gtk
provides a full graphical interface.authconfig
provides a command-line interface for manual configuration.authconfig-tui
provides a text-based UI. Note that this utility has been deprecated.
root
.
2.2.1. Tips for Using the authconfig CLI
authconfig
command-line tool updates all of the configuration files and services required for system authentication, according to the settings passed to the script. Along with providing even more identity and authentication configuration options than can be set through the UI, the authconfig
tool can also be used to create backup and kickstart files.
authconfig
options, check the help output and the man page.
authconfig
:
- With every command, use either the
--update
or--test
option. One of those options is required for the command to run successfully. Using--update
writes the configuration changes. The--test
option displays the changes but does not apply the changes to the configuration.If the--update
option is not used, then the changes are not written to the system configuration files. - The command line can be used to update existing configuration as well as to set new configuration. Because of this, the command line does not enforce that required attributes are used with a given invocation (because the command may be updating otherwise complete settings).When editing the authentication configuration, be very careful that the configuration is complete and accurate. Changing the authentication settings to incomplete or wrong values can lock users out of the system. Use the --test option to confirm that the settings are proper before using the --update option to write them.
- Each enable option has a corresponding disable option.
2.2.2. Installing the authconfig UI
authconfig
UI is not installed by default, but it can be useful for administrators to make quick changes to the authentication configuration.
authconfig-gtk
package. This has dependencies on some common system packages, such as the authconfig
command-line tool, Bash, and Python. Most of those are installed by default.
[root@server ~]# yum install authconfig-gtk Loaded plugins: langpacks, product-id, subscription-manager Resolving Dependencies --> Running transaction check ---> Package authconfig-gtk.x86_64 0:6.2.8-8.el7 will be installed --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: authconfig-gtk x86_64 6.2.8-8.el7 RHEL-Server 105 k Transaction Summary ================================================================================ Install 1 Package ... 8< ...
2.2.3. Launching the authconfig UI
- Open the terminal and log in as root.
- Run the
system-config-authentication
command.
Important
authconfig
UI is closed.
- Identity & Authentication, which configures the resource used as the identity store (the data repository where the user IDs and corresponding credentials are stored).
- Advanced Options, which configures authentication methods other than passwords or certificates, like smart cards and fingerprint.
- Password Options, which configures password authentication methods.
Figure 2.1. authconfig Window
2.2.4. Testing Authentication Settings
--test
option prints all of the authentication configuration for the system, for every possible identity and authentication mechanism. This shows both the settings for what is enabled and what areas are disabled.
test
option can be run by itself to show the full, current configuration or it can be used with an authconfig
command to show how the configuration will be changed (without actually changing it). This can be very useful in verifying that the proposed authentication settings are complete and correct.
[root@server ~]# authconfig --test caching is disabled nss_files is always enabled nss_compat is disabled nss_db is disabled nss_hesiod is disabled hesiod LHS = "" hesiod RHS = "" nss_ldap is disabled LDAP+TLS is disabled LDAP server = "" LDAP base DN = "" nss_nis is disabled NIS server = "" NIS domain = "" nss_nisplus is disabled nss_winbind is disabled SMB workgroup = "MYGROUP" SMB servers = "" SMB security = "user" SMB realm = "" Winbind template shell = "/bin/false" SMB idmap range = "16777216-33554431" nss_sss is enabled by default nss_wins is disabled nss_mdns4_minimal is disabled DNS preference over NSS or WINS is disabled pam_unix is always enabled shadow passwords are enabled password hashing algorithm is sha512 pam_krb5 is disabled krb5 realm = "#" krb5 realm via dns is disabled krb5 kdc = "" krb5 kdc via dns is disabled krb5 admin server = "" pam_ldap is disabled LDAP+TLS is disabled LDAP server = "" LDAP base DN = "" LDAP schema = "rfc2307" pam_pkcs11 is disabled use only smartcard for login is disabled smartcard module = "" smartcard removal action = "" pam_fprintd is disabled pam_ecryptfs is disabled pam_winbind is disabled SMB workgroup = "MYGROUP" SMB servers = "" SMB security = "user" SMB realm = "" pam_sss is disabled by default credential caching in SSSD is enabled SSSD use instead of legacy services if possible is enabled IPAv2 is disabled IPAv2 domain was not joined IPAv2 server = "" IPAv2 realm = "" IPAv2 domain = "" pam_pwquality is enabled (try_first_pass local_users_only retry=3 authtok_type=) pam_passwdqc is disabled () pam_access is disabled () pam_mkhomedir or pam_oddjob_mkhomedir is disabled (umask=0077) Always authorize local users is enabled () Authenticate system accounts against network services is disabled
2.2.5. Saving and Restoring Configuration Using authconfig
--savebackup
option.
[root@server ~]# authconfig --savebackup=/backups/authconfigbackup20200701
--restorebackup
option, with the name of the backup to use.
[root@server ~]# authconfig --restorebackup=/backups/authconfigbackup20200701
authconfig
command saves an automatic backup every time the configuration is altered. It is possible to restore the last backup using the --restorelastbackup
option.
[root@server ~]# authconfig --restorelastbackup
Chapter 3. Selecting the Identity Store for Authentication with authconfig
authconfig
UI sets how users should be authenticated. The default is to use local system authentication, meaning the users and their passwords are checked against local system accounts. A Red Hat Enterprise Linux machine can also use external resources which contain the users and credentials, including LDAP, NIS, and Winbind.
3.1. IPAv2
authconfig
. For previous IdM versions and for community FreeIPA servers, these are configured as LDAP providers.
3.1.1. Configuring IdM from the UI
- Open the
authconfig
UI. - Select User Account Database drop-down menu.in the
Figure 3.1. Authentication Configuration
- Set the information that is required to connect to the IdM server.
- IPA Domain gives the DNS domain of the IdM domain.
- IPA Realm gives the Kerberos domain of the IdM domain.
- IPA Server gives the host name of any IdM server within the IdM domain topology.
- Do not configure NTP optionally disables NTP services when the client is configured. This is usually not recommended, because the IdM server and all clients need to have synchronized clocks for Kerberos authentication and certificates to work properly. This could be disabled if the IdM servers are using a different NTP server rather than hosting it within the domain.
- Click thebutton.This runs the
ipa-client-install
command and, if necessary, installs theipa-client
packages. The installation script automatically configures all system files that are required for the local system and contacts the domain servers to update the domain information.
3.1.2. Configuring IdM from the Command Line
authconfig
(much like realmd
in Chapter 8, Using realmd
to Connect to an Identity Domain) can be used to enroll a system in the IdM domain. That runs the ipa-client-install
command and, if necessary, installs the ipa-client
packages. The installation script automatically configures all system files that are required for the local system and contacts the domain servers to update the domain information.
--ipav2domain
), the Kerberos realm name (--ipav2realm
), and the IdM server to contact (--ipav2server
). The --ipav2join
option gives the administrator user name to use to connect to the IdM server; this is typically admin
.
[root@server ~]# authconfig --enableipav2 --ipav2domain=IPAEXAMPLE --ipav2realm=IPAEXAMPLE --ipav2server=ipaexample.com --ipav2join=admin
--disableipav2nontp
option to prevent the setup script to use the IdM server as the NTP server. This is generally not recommended, because the IdM server and all clients need to have synchronized clocks for Kerberos authentication and certificates to work properly.
3.2. LDAP and IdM
3.2.1. Configuring LDAP Authentication from the UI
- Open the
authconfig
UI, as in Section 2.2.3, “Launching the authconfig UI”. - Select User Account Database drop-down menu.in the
- Set the information that is required to connect to the LDAP server.
- LDAP Search Base DN gives the root suffix or distinguished name (DN) for the user directory. All of the user entries used for identity or authentication exist below this parent entry. For example,
ou=people,dc=example,dc=com
.This field is optional. If it is not specified, the System Security Services Daemon (SSSD) attempts to detect the search base using thenamingContexts
anddefaultNamingContext
attributes in the LDAP server's configuration entry. - LDAP Server gives the URL of the LDAP server. This usually requires both the host name and port number of the LDAP server, such as
ldap://ldap.example.com:389
.Entering the secure protocol by using a URL starting withldaps://
enables the button, which retrieves the issuing CA certificate for the LDAP server from whatever certificate authority issued it. The CA certificate must be in the privacy enhanced mail (PEM) format. - If you use a insecure standard port connection (URL starting with
ldap://
), you can use the Use TLS to encrypt connections check box to encrypt communication with the LDAP server usingSTARTTLS
. Selecting this check box also enables the button.Note
You do not need to select the Use TLS to encrypt connections check box if the server URL uses the LDAPS (LDAP over SSL) secure protocol as the communication is already encrypted.
- Select the authentication method. LDAP allows simple password authentication or Kerberos authentication.Using Kerberos is described in Section 4.3.1, “Configuring Kerberos Authentication from the UI”.The LDAP password option uses PAM applications to use LDAP authentication. This option requires a secure connection to be set either by using LDAPS or TLS to connect to the LDAP server.
3.2.2. Configuring LDAP User Stores from the Command Line
--enableldap
. To use LDAP as the authentication source, use --enableldapauth
and then the requisite connection information, like the LDAP server name, base DN for the user suffix, and (optionally) whether to use TLS. The authconfig
command also has options to enable or disable RFC 2307bis schema for user entries, which is not possible through the authconfig
UI.
ldap
or ldaps
) and the port number. Do not use a secure LDAP URL (ldaps
) with the --enableldaptls
option.
authconfig --enableldap --enableldapauth --ldapserver=ldap://ldap.example.com:389,ldap://ldap2.example.com:389 --ldapbasedn="ou=people,dc=example,dc=com" --enableldaptls --ldaploadcacert=https://ca.server.example.com/caCert.crt --update
--ldapauth
for LDAP password authentication, it is possible to use Kerberos with the LDAP user store. These options are described in Section 4.3.2, “Configuring Kerberos Authentication from the Command Line”.
3.3. NIS
Important
- A NIS server must be fully configured with user accounts set up.
- The
ypbind
package must be installed on the local system. This is required for NIS services, but is not installed by default. - The
portmap
andypbind
services are started and enabled to start at boot time. This should be configured as part of theypbind
package installation.
3.3.1. Configuring NIS Authentication from the UI
- Open the
authconfig
UI, as in Section 2.2.3, “Launching the authconfig UI”. - Select User Account Database drop-down menu.in the
- Set the information to connect to the NIS server, meaning the NIS domain name and the server host name. If the NIS server is not specified, the
authconfig
daemon scans for the NIS server. - Select the authentication method. NIS allows simple password authentication or Kerberos authentication.Using Kerberos is described in Section 4.3.1, “Configuring Kerberos Authentication from the UI”.
3.3.2. Configuring NIS from the Command Line
--enablenis
. This automatically uses NIS authentication, unless the Kerberos parameters are explicitly set (Section 4.3.2, “Configuring Kerberos Authentication from the Command Line”). The only parameters are to identify the NIS server and NIS domain; if these are not used, then the authconfig
service scans the network for NIS servers.
[root@server ~]# authconfig --enablenis --nisdomain=EXAMPLE --nisserver=nis.example.com --update
3.4. Winbind
3.4.1. Enabling Winbind in the authconfig GUI
- Install the
samba-winbind
package. This is required for Windows integration features in Samba services, but is not installed by default.[root@server ~]# yum install samba-winbind
- Open the
authconfig
UI.[root2server ~]# authconfig-gtk
- In the Identity & Authentication tab, select in the User Account Database drop-down menu.
- Set the information that is required to connect to the Microsoft Active Directory domain controller.
- Winbind Domain gives the Windows domain to connect to.This should be in the Windows 2000 format, such as
DOMAIN
. - Security Model sets the security model to use for Samba clients.
authconfig
supports four types of security models:- ads configures Samba to act as a domain member in an Active Directory Server realm. To operate in this mode, the
krb5-server
package must be installed and Kerberos must be configured properly. - domain has Samba validate the user name and password by authenticating it through a Windows primary or backup domain controller, much like a Windows server.
- server has a local Samba server validate the user name and password by authenticating it through another server, such as a Windows server. If the server authentication attempt fails, the system then attempts to authenticate using
user
mode. - user requires a client to log in with a valid user name and password. This mode does support encrypted passwords.The user name format must be domain\user, such as
EXAMPLE\jsmith
.Note
When verifying that a given user exists in the Windows domain, always use thedomain\user_name
format and escape the backslash (\) character. For example:[root@server ~]# getent passwd domain\\user DOMAIN\user:*:16777216:16777216:Name Surname:/home/DOMAIN/user:/bin/bash
This is the default option.
- Winbind ADS Realm gives the Active Directory realm that the Samba server will join. This is only used with the ads security model.
- Winbind Domain Controllers gives the host name or IP address of the domain controller to use to enroll the system.
- Template Shell sets which login shell to use for Windows user account settings.
- Allow offline login allows authentication information to be stored in a local cache. The cache is referenced when a user attempts to authenticate to system resources while the system is offline.
3.4.2. Enabling Winbind in the Command Line
--winbindjoin
parameter sets the user to use to connect to the Active Directory domain, and --enablelocalauthorize
sets local authorization operations to check the /etc/passwd
file.
authconfig
command, join the Active Directory domain.
[root@server ~]# authconfig --enablewinbind --enablewinbindauth --smbsecurity=user|server --enablewinbindoffline --smbservers=ad.example.com --smbworkgroup=EXAMPLE --update --enablelocauthorize --winbindjoin=admin [root@server ~]# net join ads
Note
EXAMPLE\jsmith
.
[root@server ~]# getent passwd domain\\user DOMAIN\user:*:16777216:16777216:Name Surname:/home/DOMAIN/user:/bin/bash
[root@server ~]# authconfig --enablewinbind --enablewinbindauth --smbsecurity ads --enablewinbindoffline --smbservers=ad.example.com --smbworkgroup=EXAMPLE --smbrealm EXAMPLE.COM --winbindtemplateshell=/bin/sh --update
authconfig
help.
Chapter 4. Configuring Authentication Mechanisms
authconfig
tool or, in some cases, also using Identity Management tools.
4.1. Configuring Local Authentication Using authconfig
/etc/security/access.conf
). Otherwise, authorization policies can be defined within the identity provider or the services themselves.
4.1.1. Enabling Local Access Control in the UI
/etc/security/access.conf
file for local user authorization rules. This is PAM authorization.
Figure 4.1. Local Accounts Fields
4.1.2. Configuring Local Access Control in the Command Line
authconfig
to enable local authorization controls. --enablelocauthorize
skips network authentication and only checks local files for system users. --enablepamaccess
configures the system to look for system authorization policies in /etc/security/access.conf
.
[root@server ~]# authconfig --enablelocauthorize --enablepamaccess --update
4.2. Configuring System Passwords Using authconfig
4.2.1. Password Security
Important
4.2.1.1. Configuring Password Hashing in the UI
- Open the
authconfig
UI, as in Section 2.2.3, “Launching the authconfig UI”. - Open the Advanced Options tab.
- Select the algorithm to use in the Password Hashing Algorithm drop-down menu.
- Click thebutton.
4.2.1.2. Configuring Password Hashing on the Command Line
--passalgo
option and the short name for the algorithm. The following example uses the SHA-512 algorithm:
[root@server ~]# authconfig --passalgo=sha512 --update
4.2.2. Password Complexity
4.2.2.1. Configuring Password Complexity in the UI
- Open the
authconfig
UI, as in Section 2.2.3, “Launching the authconfig UI”. - Open the Password Options tab.
- Set the minimum requirements for the password:
- The minimum length of the password
- The minimum number of character classes which must be used in the password.
- Enable characters classes which must be used for passwords. For example, an uppercase letter can be used with any password, but if the Uppercase check box is selected, then an uppercase letter must be used in every password.
- Set the number of times that a character or character class can be repeated consecutively. (If this is set to zero, then there is no repeat limit.)For the Same Character field, this sets how often a single letter or character can be repeated. If this is set to 2, for example, then ssecret is allowed but sssecret is rejected.Likewise, Same Class sets a limit on how many times any character from a character class (uppercase, number, special character) can be repeated. If this is set to 3, for example, secret!! is allowed but secret!!@ or secret1234 would be rejected.
- Click thebutton.
4.2.2.2. Configuring Password Complexity in the Command Line
- The minimum length (
--passminlen
). - The minimum number of different types of characters which must be used (
--passminclass
). - The number of times a character can be repeated consecutively (
--passmaxrepeat
). Setting this to zero means there is no repeat limit. - The number of time the same type of character (such as a number) can be used in a row (
--passmaxclassrepeat
). Setting this to zero means there is no repeat limit.
--enablereq
Type option means that a given class is absolutely required or the password is rejected. (Conversely, types can be explicitly denied, as well.)
- Uppercase letters (
--enablerequpper
) - Lowercase letters (
--enablereqlower
) - Numbers (
--enablereqdigit
) - Special characters (
--enablereqother
)
[root@server ~]# authconfig --passminlen=9 --passminclass=3 --passmaxrepeat=2 -passmaxclassrepeat=2 --enablerequpper --enablereqother --update
4.3. Configuring Kerberos (with LDAP or NIS) Using authconfig
- It uses a security layer for communication while still allowing connections over standard ports.
- It automatically uses credentials caching with SSSD, which allows offline logins.
Note
krb5-libs
and krb5-workstation
packages.
4.3.1. Configuring Kerberos Authentication from the UI
Figure 4.2. Kerberos Fields
- Realm gives the name for the realm for the Kerberos server. The realm is the network that uses Kerberos, composed of one or more key distribution centers (KDC) and a potentially large number of clients.
- KDCs gives a comma-separated list of servers that issue Kerberos tickets.
- Admin Servers gives a list of administration servers running the
kadmind
process in the realm. - Optionally, use DNS to resolve server host name and to find additional KDCs within the realm.
4.3.2. Configuring Kerberos Authentication from the Command Line
[root@server ~]# authconfig NIS or LDAP options --enablekrb5 --krb5realm EXAMPLE --krb5kdc kdc.example.com:88,server.example.com:88 --krb5adminserver server.example.com:749 --enablekrb5kdcdns --enablekrb5realmdns --update
4.4. Smart Cards
Important
4.4.1. Configuring Smart Cards Using authconfig
Figure 4.3. Smart Card Options
Note
- nss-tools
- nss-pam-ldapd
- esc
- pam_pkcs11
- pam_krb5
- opensc
- pcsc-lite-ccid
- gdm
- authconfig
- authconfig-gtk
- krb5-libs
- krb5-workstation
- krb5-pkinit
- pcsc-lite
- pcsc-lite-libs
4.4.1.1. Enabling Smart Card Authentication from the UI
- Log into the system as root.
- Download the root CA certificates for the network in base 64 format, and install them on the server. The certificates are installed in the appropriate system database using the
certutil
command. For example:[root@server ~]# certutil -A -d /etc/pki/nssdb -n "root CA cert" -t "CT,C,C" -i /tmp/ca_cert.crt
Note
Do not be concerned that the imported certificate is not displayed in theauthconfig
UI later during the process. You cannot see the certificate in the UI; it is obtained from the/etc/pki/nssdb/
directory during authentication. - In the top menu, select themenu, select , and then click .
- Open the Advanced Options tab.
- Click the Enable Smart Card Support check box.
- There are two behaviors that can be configured for smart cards:
- The Card removal action menu sets the response that the system takes if the smart card is removed during an active session. The
Ignore
option means that the system continues functioning as normal if the smart card is removed, whileLock
immediately locks the screen. - The Require smart card for login check box sets whether a smart card is required for logins. When this option is selected, all other methods of authentication are blocked.
Warning
Do not select this until after you have successfully logged in using a smart card.
- By default, the mechanisms to check whether a certificate has been revoked (Online Certificate Status Protocol, or OCSP, responses) are disabled. To validate whether a certificate has been revoked before its expiration period, enable OCSP checking by adding the
ocsp_on
option to thecert_policy
directive.- Open the
pam_pkcs11.conf
file.vim /etc/pam_pkcs11/pam_pkcs11.conf
- Change every
cert_policy
line so that it contains theocsp_on
option.cert_policy = ca,
ocsp_on,
signature;Note
Because of the way the file is parsed, there must be a space betweencert_policy
and the equals sign. Otherwise, parsing the parameter fails.
- If the smart card has not yet been enrolled (set up with personal certificates and keys), enroll the smart card.
- If the smart card is a CAC card, create the
.k5login
file in the CAC user's home directory. The.k5login
file is required to have the Microsoft Principal Name on the CAC card. - Add the following line to the
/etc/pam.d/smartcard-auth
and/etc/pam.d/system-auth
files:auth optional pam_krb5.so use_first_pass no_subsequent_prompt preauth_options=X509_user_identity=PKCS11:/usr/lib64/pkcs11/opensc-pkcs11.so
If the OpenSC module does not work as expected, use the module from the coolkey package:/usr/lib64/pkcs11/libcoolkeypk11.so
. In this case, consider contacting Red Hat Technical Support or filing a Bugzilla report about the problem. - Configure the
/etc/krb5.conf
file. The settings vary depending on whether you are using a CAC card or a Gemalto 64K card.- With CAC cards, specify all the root certificates related to the CAC card usage in
pkinit_anchors
. In the following example/etc/krb5.conf
file for configuring a CAC card, EXAMPLE.COM is the realm name for the CAC cards, and kdc.server.hostname.com is the KDC server host name.[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 1h renew_lifetime = 6h forwardable = true default_realm = EXAMPLE.COM [realms] EXAMPLE.COM = { kdc = kdc.server.hostname.com admin_server = kdc.server.hostname.com pkinit_anchors = FILE:/etc/pki/nssdb/ca_cert.pem pkinit_anchors = FILE:/etc/pki/nssdb/CAC_CA_cert.pem pkinit_anchors = FILE:/etc/pki/nssdb/CAC_CA_email_cert.pem pkinit_anchors = FILE:/etc/pki/nssdb/CAC_root_ca_cert.pem pkinit_cert_match = CAC card specific information } [domain_realm] EXAMPLE.COM = EXAMPLE.COM .EXAMPLE.COM = EXAMPLE.COM .kdc.server.hostname.com = EXAMPLE.COM kdc.server.hostname.com = EXAMPLE.COM [appdefaults] pam = { debug = true ticket_lifetime = 1h renew_lifetime = 3h forwardable = true krb4_convert = false mappings = username on the CAC card Principal name on the card }
- In the following example
/etc/krb5.conf
file for configuring a Gemalto 64K card, EXAMPLE.COM is the realm created on the KDC server, kdc-ca.pem is the CA certificate, and kdc.server.hostname.com is the KDC server host name.[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 15m renew_lifetime = 6h forwardable = true default_realm = EXAMPLE.COM [realms] EXAMPLE.COM = { kdc = kdc.server.hostname.com admin_server = kdc.server.hostname.com pkinit_anchors = FILE:/etc/pki/nssdb/kdc-ca.pem pkinit_cert_match = <KU>digitalSignature pkinit_kdc_hostname = kdc.server.hostname.com } [domain_realm] EXAMPLE.COM = EXAMPLE.COM .EXAMPLE.COM = EXAMPLE.COM .kdc.server.hostname.com = EXAMPLE.COM kdc.server.hostname.com = EXAMPLE.COM [appdefaults] pam = { debug = true ticket_lifetime = 1h renew_lifetime = 3h forwardable = true krb4_convert = false }
Note
pklogin_finder
utility, when run in debug mode, first maps the login ID to the certificates on the card and then attempts to output information about the validity of certificates:
pklogin_finder debug
4.4.1.2. Configuring Smart Card Authentication from the Command Line
--enablesmartcard
option:
[root@server ~]# authconfig --enablesmartcard --update
0
instructs the system to lock out a user immediately if the smart card is removed; a setting of 1
ignores it if the smart card is removed:
[root@server ~]# authconfig --enablesmartcard --smartcardaction=0 --update
[root@server ~]# authconfig --enablerequiresmartcard --update
Warning
--enablerequiresmartcard
option until you have successfully authenticated to the system using a smart card. Otherwise, users may be unable to log into the system.
4.4.2. Smart Card Authentication in Identity Management
4.5. One-Time Passwords
One-Time Passwords in Red Hat Enterprise Linux
4.6. Configuring Fingerprints Using authconfig
4.6.1. Using Fingerprint Authentication in the UI
Figure 4.4. Fingerprint Options
4.6.2. Configuring Fingerprint Authentication in the Command Line
authconfig
settings, like LDAP user stores.
[root@server ~]# authconfig --enablefingerprint --update
Chapter 5. Managing Kickstart and Configuration Files Using authconfig
--update
option updates all of the configuration files with the configuration changes. There are a couple of alternative options with slightly different behavior:
--kickstart
writes the updated configuration to a kickstart file.--test
displays the full configuration with changes, but does not edit any configuration files.
authconfig
can be used to back up and restore previous configurations. All archives are saved to a unique subdirectory in the /var/lib/authconfig/
directory. For example, the --savebackup
option gives the backup directory as 2011-07-01
:
[root@server ~]# authconfig --savebackup=2011-07-01
/var/lib/authconfig/backup-2011-07-01
directory.
--restorebackup
option, giving the name of the manually saved configuration:
[root@server ~]# authconfig --restorebackup=2011-07-01
authconfig
automatically makes a backup of the configuration before it applies any changes (with the --update
option). The configuration can be restored from the most recent automatic backup, without having to specify the exact backup, using the --restorelastbackup
option.
Chapter 6. Enabling Custom Home Directories Using authconfig
/home
and the system is configured to create home directories the first time users log in, then these directories are created with the wrong permissions.
- Apply the correct SELinux context and permissions from the
/home
directory to the home directory that is created on the local system. For example:[root@server ~]# semanage fcontext -a -e /home /home/locale
- Install the
oddjob-mkhomedir
package on the system.This package provides thepam_oddjob_mkhomedir.so
library, which theauthconfig
command uses to create home directories. Thepam_oddjob_mkhomedir.so
library, unlike the defaultpam_mkhomedir.so
library, can create SELinux labels.Theauthconfig
command automatically uses thepam_oddjob_mkhomedir.so
library if it is available. Otherwise, it will default to usingpam_mkhomedir.so
. - Make sure the
oddjobd
service is running. - Run the
authconfig
command and enable home directories. In the command line, this is done through the--enablemkhomedir
option.[root@server ~]# authconfig --enablemkhomedir --update
In the UI, there is an option in the Advanced Options tab (Create home directories on the first login) to create a home directory automatically the first time that a user logs in.Figure 6.1. Home Directory Option
This option is beneficial with accounts that are managed centrally, such as with LDAP. However, this option should not be selected if a system like automount is used to manage user home directories.
[root@server ~]# semanage fcontext -a -e /home /home/locale # restorecon -R -v /home/locale
Part II. Identity and Authentication Stores
System Security Services Daemon
(SSSD
), how to use the realmd
tool to connect to an identity domain, and how to install, configure and run the OpenLDAP
server.
Chapter 7. Configuring SSSD
7.1. Introduction to SSSD
7.1.1. How SSSD Works
- Connects the client to an identity store to retrieve authentication information.
- Uses the obtained authentication information to create a local cache of users and credentials on the client.
Figure 7.1. How SSSD works
7.1.2. Benefits of Using SSSD
- Reduced load on identity and authentication servers
- When requesting information, SSSD clients contact SSSD, which checks its cache. SSSD contacts the servers only if the information is not available in the cache.
- Offline authentication
- SSSD optionally keeps a cache of user identities and credentials retrieved from remote services. In this setup, users can successfully authenticate to resources even if the remote server or the SSSD client are offline.
- A single user account: improved consistency of the authentication process
- With SSSD, it is not necessary to maintain both a central account and a local user account for offline authentication.Remote users often have multiple user accounts. For example, to connect to a virtual private network (VPN), remote users have one account for the local system and another account for the VPN system.Thanks to caching and offline authentication, remote users can connect to network resources simply by authenticating to their local machine. SSSD then maintains their network credentials.
7.2. Using Multiple SSSD Configuration Files on a Per-client Basis
/etc/sssd/sssd.conf
. Apart from this file, SSSD can read its configuration from all *.conf
files in the /etc/sssd/conf.d/
directory.
/etc/sssd/sssd.conf
file on all clients and add additional settings in further configuration files to extend the functionality individually on a per-client basis.
How SSSD Processes the Configuration Files
- The primary
/etc/sssd/sssd.conf
file - Other
*.conf
files in/etc/sssd/conf.d/
, in alphabetical order
Note
.
) in the conf.d
directory.
7.3. Configuring Identity and Authentication Providers for SSSD
7.3.1. Introduction to Identity and Authentication Providers for SSSD
SSSD Domains. Identity and Authentication Providers
- An identity provider (for user information)
- An authentication provider (for authentication requests)
- An access control provider (for authorization requests)
- A combination of these providers (if all the corresponding operations are performed within a single server)
access_provider
option in the /etc/sssd/sssd.conf
file sets the access control provider used for the domain. By default, the option is set to permit
, which always allows all access. See the sssd.conf(5) man page for details.
Proxy Providers
- Alternative authentication methods, such as a fingerprint scanner
- Legacy systems, such as NIS
- A local system account defined in
/etc/passwd
and remote authentication
Available Combinations of Identity and Authentication Providers
Identity Provider | Authentication Provider |
---|---|
Identity Management [a] | Identity Management [a] |
Active Directory [a] | Active Directory [a] |
LDAP | LDAP |
LDAP | Kerberos |
proxy | proxy |
proxy | LDAP |
proxy | Kerberos |
[a]
An extension of the LDAP provider type.
|
- To configure an SSSD client for Identity Management, Red Hat recommends using the
ipa-client-install
utility. See Installing and Uninstalling Identity Management Clients in the Linux Domain Identity, Authentication, and Policy Guide. - To configure an SSSD client for Identity Management manually without
ipa-client-install
, see Installing and Uninstalling an Identity Management Client Manually in Red Hat Knowledgebase. - To configure Active Directory to be used with SSSD, see Using Active Directory as an Identity Provider for SSSD in the Windows Integration Guide.
7.3.2. Configuring an LDAP Domain for SSSD
Prerequisites
- Install SSSD.
# yum install sssd
Configure SSSD to Discover the LDAP Domain
- Open the
/etc/sssd/sssd.conf
file. - Create a
[domain]
section for the LDAP domain:[domain/LDAP_domain_name]
- Specify if you want to use the LDAP server as an identity provider, an authentication provider, or both.
- To use the LDAP server as an identity provider, set the
id_provider
option toldap
. - To use the LDAP server as an authentication provider, set the
auth_provider
option toldap
.
For example, to use the LDAP server as both:[domain/LDAP_domain_name]
id_provider = ldap
auth_provider = ldap
- Specify the LDAP server. Choose one of the following:
- To explicitly define the server, specify the server's URI with the
ldap_uri
option:[domain/LDAP_domain_name] id_provider = ldap auth_provider = ldap
ldap_uri = ldap://ldap.example.com
Theldap_uri
option also accepts the IP address of the server. However, using an IP address instead of the server name might cause TLS/SSL connections to fail. See Configuring an SSSD Provider to Use an IP Address in the Certificate Subject Name in Red Hat Knowledgebase. - To configure SSSD to discover the server dynamically using DNS service discovery, see Section 7.4.3, “Configuring DNS Service Discovery”.
Optionally, specify backup servers in theldap_backup_uri
option as well. - Specify the LDAP server's search base in the
ldap_search_base
option:[domain/LDAP_domain_name] id_provider = ldap auth_provider = ldap ldap_uri = ldap://ldap.example.com
ldap_search_base = dc=example,dc=com
- Specify a way to establish a secure connection to the LDAP server. The recommended method is to use a TLS connection. To do this, enable the
ldap_id_use_start_tls
option, and use these CA certificate-related options:ldap_tls_reqcert
specifies if the client requests a server certificate and what checks are performed on the certificateldap_tls_cacert
specifies the file containing the certificate
[domain/LDAP_domain_name] id_provider = ldap auth_provider = ldap ldap_uri = ldap://ldap.example.com ldap_search_base = dc=example,dc=com
ldap_id_use_start_tls = true
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt
Note
SSSD always uses an encrypted channel for authentication, which ensures that passwords are never sent over the network unencrypted. Withldap_id_use_start_tls = true
, identity lookups (such as commands based on theid
orgetent
utilities) are also encrypted. - Add the new domain to the
domains
option in the[sssd]
section. The option lists the domains that SSSD queries. For example:domains =
LDAP_domain_name
, domain2
Additional Resources
- the sssd.conf(5) man page, which describes global options available for all types of domains
- the sssd-ldap(5) man page, which describes options specific to LDAP
7.3.3. Configuring the Files Provider for SSSD
files
provider mirrors the content of the /etc/passwd
and /etc/groups
files to make users and groups from these files available through SSSD. This enables you to set the sss
database as the first source for users and groups in the /etc/nsswitch.conf
file:
passwd: sss files group: sss files
files
provider is configured in /etc/sssd/sssd.conf
, Red Hat Enterprise Linux sends all queries for users and groups first to SSSD. If SSSD is not running or SSSD cannot find the requested entry, the system falls back to look up users and groups in the local files. If you store most users and groups in a central database, such as an LDAP directory, this setting increases speed of users and groups lookups.
Prerequisites
- Install SSSD.
# yum install sssd
Configure SSSD to Discover the Files Domain
- Add the following section to the
/etc/sssd/sssd.conf
file:[domain/files] id_provider = files
- Optionally, set the
sss
database as the first source for user and group lookups in the/etc/sssd/sssd.conf
file:passwd: sss files group: sss files
- Configure the system in the way that the
sssd
service starts when the system boots:# systemctl enable sssd
- Restart the
sssd
service:# systemctl restart sssd
Additional Resources
files
provider. For more details, see:
- the sssd.conf(5) man page, which describes global options available for all types of domains
- the sssd-files(5) man page, which describes options specific to the
files
provider
7.3.4. Configuring a Proxy Provider for SSSD
Prerequisites
- Install SSSD.
# yum install sssd
Configure SSSD to Discover the Proxy Domain
- Open the
/etc/sssd/sssd.conf
file. - Create a
[domain]
section for the proxy provider:[domain/proxy_name]
- To specify an authentication provider:
- Set the
auth_provider
option toproxy
. - Use the
proxy_pam_target
option to specify a PAM service as the authentication proxy.
For example:[domain/proxy_name]
auth_provider = proxy
proxy_pam_target = sssdpamproxy
Important
Ensure that the proxy PAM stack does not recursively includepam_sss.so
. - To specify an identity provider:
- Set the
id_provider
option toproxy
. - Use the
proxy_lib_name
option to specify an NSS library as the identity proxy.
For example:[domain/proxy_name]
id_provider = proxy
proxy_lib_name = nis
- Add the new domain to the
domains
option in the[sssd]
section. The option lists the domains that SSSD queries. For example:domains =
proxy_name
, domain2
Additional Resources
7.3.5. Configuring a Kerberos Authentication Provider
Prerequisites
- Install SSSD.
# yum install sssd
Configure SSSD to Discover the Kerberos Domain
- Open the
/etc/sssd/sssd.conf
file. - Create a
[domain]
section for the SSSD domain.[domain/Kerberos_domain_name]
- Specify an identity provider. For example, for details on configuring an LDAP identity provider, see Section 7.3.2, “Configuring an LDAP Domain for SSSD”.If the Kerberos principal names are not available in the specified identity provider, SSSD constructs the principals using the format username@REALM.
- Specify the Kerberos authentication provider details:
- Set the
auth_provider
option tokrb5
.[domain/Kerberos_domain_name] id_provider = ldap
auth_provider = krb5
- Specify the Kerberos server:
- To explicitly define the server, use the
krb5_server
option. The options accepts the host name or IP address of the server:[domain/Kerberos_domain_name] id_provider = ldap auth_provider = krb5
krb5_server = kdc.example.com
- To configure SSSD to discover the server dynamically using DNS service discovery, see Section 7.4.3, “Configuring DNS Service Discovery”.
Optionally, specify backup servers in thekrb5_backup_server
option as well. - If the Change Password service is not running on the KDC specified in
krb5_server
orkrb5_backup_server
, use thekrb5_passwd
option to specify the server where the service is running.[domain/Kerberos_domain_name] id_provider = ldap auth_provider = krb5 krb5_server = kdc.example.com krb5_backup_server = kerberos.example.com
krb5_passwd = kerberos.admin.example.com
Ifkrb5_passwd
is not used, SSSD uses the KDC specified inkrb5_server
orkrb5_backup_server
. - Use the
krb5_realm
option to specify the name of the Kerberos realm.[domain/Kerberos_domain_name] id_provider = ldap auth_provider = krb5 krb5_server = kerberos.example.com krb5_backup_server = kerberos2.example.com krb5_passwd = kerberos.admin.example.com
krb5_realm = EXAMPLE.COM
- Add the new domain to the
domains
option in the[sssd]
section. The option lists the domains that SSSD queries. For example:domains =
Kerberos_domain_name
, domain2
Additional Resources
- the sssd.conf(5) man page, which describes global options available for all types of domains
- the sssd-krb5(5) man page, which describes options specific to Kerberos
7.4. Additional Configuration for Identity and Authentication Providers
7.4.1. Adjusting User Name Formats
7.4.1.1. Defining the Regular Expression for Parsing Full User Names
user_name@domain_name
based on the following regular expression in Python syntax:
(?P<name>[^@]+)@?(?P<domain>[^@]*$)
Note
user_name@domain_name
or NetBIOS_name\user_name
.
- Open the
/etc/sssd/sssd.conf
file. - Use the
re_expression
option to define a custom regular expression.- To define the regular expressions globally for all domains, add
re_expression
to the[sssd]
section ofsssd.conf
. - To define the regular expressions individually for a particular domain, add
re_expression
to the corresponding domain section ofsssd.conf
.
[domain/LDAP]
[... file truncated ...]
re_expression = (?P<domain>[^\\]*?)\\?(?P<name>[^\\]+$)
re_expression
in the SPECIAL SECTIONS
and DOMAIN SECTIONS
parts of the sssd.conf(5) man page.
7.4.1.2. Defining How SSSD Prints Full User Names
use_fully_qualified_names
option is enabled in the /etc/sssd/sssd.conf
file, SSSD prints full user names in the format name@domain
based on the following expansion by default:
%1$s@%2$s
Note
use_fully_qualified_names
is not set or is explicitly set to false
for trusted domains, only the user name is printed, without the domain component.
- Open the
/etc/sssd/sssd.conf
file. - Use the
full_name_format
option to define the expansion for the full user name format:- To define the expansion globally for all domains, add
full_name_format
to the[sssd]
section ofsssd.conf
. - To define the expansion individually for a particular domain, add
full_name_format
to the corresponding domain section ofsssd.conf
.
full_name_format
in the SPECIAL SECTIONS
and DOMAIN SECTIONS
parts of the sssd.conf(5) man page.
full_name_format
to a non-standard value, a warning will prompt you to change it to a more standard format.
7.4.2. Enabling Offline Authentication
Important
- Open the
/etc/sssd/sssd.conf
file. - In a domain section, add the
cache_credentials = true
setting:[domain/domain_name]
cache_credentials = true
- Optional, but recommended. Configure a time limit for how long SSSD allows offline authentication if the identity provider is unavailable.
- Configure the PAM service to work with SSSD. See Section 7.5.2, “Configuring Services: PAM”.
- Use the
offline_credentials_expiration
option to specify the time limit. For example, to specify that users are able to authenticate offline for 3 days since the last successful login:[pam]
offline_credentials_expiration = 3
offline_credentials_expiration
, see the sssd.conf(5) man page.
7.4.3. Configuring DNS Service Discovery
/etc/sssd/sssd.conf
file, SSSD can discover the server dynamically using DNS service discovery [1].
sssd.conf
includes the id_provider = ldap
setting, but the ldap_uri
option does not specify any host name or IP address, SSSD uses DNS service discovery to discover the server dynamically.
Note
Configuring SSSD for DNS Service Discovery
- Open the
/etc/sssd/sssd.conf
file. - Set the primary server value to
_srv_
. For an LDAP provider, the primary server is set using theldap_uri
option:[domain/domain_name] id_provider = ldap
ldap_uri = _srv_
- Enable service discovery in the password change provider by setting a service type:
[domain/domain_name] id_provider = ldap ldap_uri = _srv_
chpass_provider = ldap
ldap_chpass_dns_service_name = ldap
- Optional. By default, the service discovery uses the domain portion of the system host name as the domain name. To use a different DNS domain, specify the domain name in the
dns_discovery_domain
option. - Optional. By default, the service discovery scans for the LDAP service type. To use a different service type, specify the type in the
ldap_dns_service_name
option. - Optional. By default, SSSD attempts to look up an IPv4 address. If the attempt fails, SSSD attempts to look up an IPv6 address. To customize this behavior, use the
lookup_family_order
option. See the sssd.conf(5) man page for details. - For every service with which you want to use service discovery, add a DNS record to the DNS server:
_service._protocol._domain TTL priority weight port host_name
7.4.4. Defining Access Control Using the simple
Access Provider
simple
access provider allows or denies access based on a list of user names or groups. It enables you to restrict access to specific machines.
simple
access provider to restrict access to only a specific user or a specific group. Other users or groups will not be allowed to log in even if they authenticate successfully against the configured authentication provider.
Configuring simple
Access Provider Rules
- Open the
/etc/sssd/sssd.conf
file. - Set the
access_provider
option tosimple
:[domain/domain_name]
access_provider = simple
- Define the access control rules for users. Choose one of the following:
- To allow access to users, use the
simple_allow_users
option. - To deny access to users, use the
simple_deny_users
option.Important
Allowing access to specific users is considered safer than denying. If you deny access to specific users, you automatically allow access to everyone else.
- Define the access control rules for groups. Choose one of the following:
- To allow access to groups, use the
simple_allow_groups
option. - To deny access to groups, use the
simple_deny_groups
option.Important
Allowing access to specific groups is considered safer than denying. If you deny access to specific groups, you automatically allow access to everyone else.
user1
, user2
, and members of group1
, while denying access to all other users.
[domain/domain_name] access_provider = simplesimple_allow_users = user1, user2
simple_allow_groups = group1
7.4.5. Defining Access Control Using the LDAP Access Filter
access_provider
option is set in /etc/sssd/sssd.conf
, SSSD uses the specified access provider to evaluate which users are granted access to the system. If the access provider you are using is an extension of the LDAP provider type, you can also specify an LDAP access control filter that a user must match in order to be allowed access to the system.
Note
simple
Access Provider”.
Important
Configuring SSSD to Apply an LDAP Access Filter
- Open the
/etc/sssd/sssd.conf
file. - In the
[domain]
section, specify the LDAP access control filter.- For an LDAP access provider, use the
ldap_access_filter
option. See the sssd-ldap(5) man page for details. - For an AD access provider, use the
ad_access_filter
option. See the sssd-ad(5) man page for details.
For example, to allow access only to AD users who belong to theadmins
user group and have aunixHomeDirectory
attribute set:[domain/AD_domain_name] access provider = ad [... file truncated ...]
ad_access_filter = (&(memberOf=cn=admins,ou=groups,dc=example,dc=com)(unixHomeDirectory=*))
authorizedService
or host
attribute in an entry. In fact, all options — LDAP filter, authorizedService
, and host
— can be evaluated, depending on the user entry and the configuration. The ldap_access_order
parameter lists all access control methods to use, in order of how they should be evaluated.
[domain/example.com] access_provider = ldap ldap_access_filter = memberOf=cn=allowedusers,ou=Groups,dc=example,dc=com ldap_access_order = filter, host, authorized_service
sssd-ldap(5)
man page.
7.5. Configuring System Services for SSSD
- Name Service Switch (NSS)
- Pluggable Authentication Modules (PAM)
- OpenSSH
- See Configuring SSSD to Provide a Cache for the OpenSSH Services in the Linux Domain Identity, Authentication, and Policy Guide.
autofs
sudo
7.5.1. Configuring Services: NSS
How SSSD Works with NSS
- User information (the
passwd
map) - Groups (the
groups
map) - Netgroups (the
netgroups
map) - Services (the
services
map)
Prerequisites
- Install SSSD.
# yum install sssd
Configure NSS Services to Use SSSD
- Use the
authconfig
utility to enable SSSD:[root@server ~]# authconfig --enablesssd --update
This updates the/etc/nsswitch.conf
file to enable the following NSS maps to use SSSD:passwd: files sss shadow: files sss group: files sss netgroup: files sss
- Open
/etc/nsswitch.conf
and addsss
to theservices
map line:services: files
sss
Configure SSSD to work with NSS
- Open the
/etc/sssd/sssd.conf
file. - In the
[sssd]
section, make sure that NSS is listed as one of the services that works with SSSD.[sssd] [... file truncated ...] services =
nss
, pam - In the
[nss]
section, configure how SSSD interacts with NSS. For example:[nss] filter_groups = root filter_users = root entry_cache_timeout = 300 entry_cache_nowait_percentage = 75
For a complete list of available options, seeNSS configuration options
in the sssd.conf(5) man page. - Restart SSSD.
# systemctl restart sssd.service
Test That the Integration Works Correctly
id user
getent passwd user
7.5.2. Configuring Services: PAM
Warning
Configure PAM to Use SSSD
- Use the
authconfig
utility to enable SSSD:# authconfig --enablesssdauth --update
This updates the PAM configuration to reference the SSSD modules, usually in the/etc/pam.d/system-auth
and/etc/pam.d/password-auth
files. For example:[... file truncated ...] auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so [... file truncated ...]
Configure SSSD to work with PAM
- Open the
/etc/sssd/sssd.conf
file. - In the
[sssd]
section, make sure that PAM is listed as one of the services that works with SSSD.[sssd] [... file truncated ...] services = nss,
pam
- In the
[pam]
section, configure how SSSD interacts with PAM. For example:[pam] offline_credentials_expiration = 2 offline_failed_login_attempts = 3 offline_failed_login_delay = 5
For a complete list of available options, seePAM configuration options
in the sssd.conf(5) man page. - Restart SSSD.
# systemctl restart sssd.service
Test That the Integration Works Correctly
- Try logging in as a user.
- Use the
sssctl user-checks user_name auth
command to check your SSSD configuration. For details, use thesssctl user-checks --help
command.
7.5.3. Configuring Services: autofs
How SSSD Works with automount
automount
utility can mount and unmount NFS file systems automatically (on-demand mounting), which saves system resources. For details on automount
, see autofs in the Storage Administration Guide.
automount
to point to SSSD. In this setup:
- When a user attempts to mount a directory, SSSD contacts LDAP to obtain the required information about the current
automount
configuration. - SSSD stores the information required by
automount
in a cache, so that users can mount directories even when the LDAP server is offline.
Configure autofs
to Use SSSD
- Install the autofs package.
# yum install autofs
- Open the
/etc/nsswitch.conf
file. - On the
automount
line, change the location where to look for theautomount
map information fromldap
tosss
:automount: files
sss
Configure SSSD to work with autofs
- Open the
/etc/sssd/sssd.conf
file. - In the
[sssd]
section, addautofs
to the list of services that SSSD manages.[sssd] services = nss,pam,
autofs
- Create a new
[autofs]
section. You can leave it empty.[autofs]
For a list of available options, seeAUTOFS configuration options
in the sssd.conf(5) man page. - Make sure an LDAP domain is available in
sssd.conf
, so that SSSD can read theautomount
information from LDAP. See Section 7.3.2, “Configuring an LDAP Domain for SSSD”.The[domain]
section ofsssd.conf
accepts severalautofs
-related options. For example:[domain/LDAP] [... file truncated ...]
autofs_provider=ldap
ldap_autofs_search_base=cn=automount,dc=example,dc=com
ldap_autofs_map_object_class=automountMap
ldap_autofs_entry_object_class=automount
ldap_autofs_map_name=automountMapName
ldap_autofs_entry_key=automountKey
ldap_autofs_entry_value=automountInformation
For a complete list of available options, seeDOMAIN SECTIONS
in the sssd.conf(5) man page.If you do not provide additionalautofs
options, the configuration depends on the identity provider settings. - Restart SSSD.
# systemctl restart sssd.service
Test the Configuration
- Use the
automount -m
command to print the maps from SSSD.
7.5.4. Configuring Services: sudo
How SSSD Works with sudo
sudo
utility gives administrative access to specified users. For more information about sudo
, see The sudo
utility documentation in the System Administrator's Guide.
sudo
to point to SSSD. In this setup:
- When a user attempts a
sudo
operation, SSSD contacts LDAP or AD to obtain the required information about the currentsudo
configuration. - SSSD stores the
sudo
information in a cache, so that users can performsudo
operations even when the LDAP or AD server is offline.
sudo
rules which apply to the local system, depending on the value of the sudoHost
attribute. See the sssd-sudo(5) man page for details.
Configure sudo
to Use SSSD
- Open the
/etc/nsswitch.conf
file. - Add SSSD to the list on the
sudoers
line.sudoers: files
sss
Configure SSSD to work with sudo
- Open the
/etc/sssd/sssd.conf
file. - In the
[sssd]
section, addsudo
to the list of services that SSSD manages.[sssd] services = nss,pam,
sudo
- Create a new
[sudo]
section. You can leave it empty.[sudo]
For a list of available options, seeSUDO configuration options
in the sssd.conf(5) man page. - Make sure an LDAP or AD domain is available in
sssd.conf
, so that SSSD can read thesudo
information from the directory. For details, see:- the Using Active Directory as an Identity Provider for SSSD section in the Windows Integration Guide.
The[domain]
section for the LDAP or AD domain must include thesesudo
-related parameters:[domain/LDAP_or_AD_domain] ...
sudo_provider = ldap
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
Note
Setting Identity Management or AD as the ID provider automatically enables thesudo
provider. In this situation, it is not necessary to specify thesudo_provider
parameter.For a complete list of available options, seeDOMAIN SECTIONS
in the sssd.conf(5) man page.For options available for asudo
provider, see the sssd-ldap(5) man page. - Restart SSSD.
# systemctl restart sssd.service
sudo
rules. For details, see the sudo
documentation.
sudo
rules in LDAP or AD, see the sudoers.ldap(5) man page.
7.6. SSSD Client-side Views
id_provider
values, except ipa
. If you are using the ipa
provider, define ID views centrally in IdM. See the corresponding section in the Linux Domain Identity, Authentication, and Policy Guide.
Note
sss_override user-add
, sss_override group-add
, or sss_override user-import
command, restart SSSD for the changes to take effect:
# systemctl restart sssd
7.6.1. Defining a Different Attribute Value for a User Account
- Optional. Display the current UID of the user account:
# id user uid=1241400014(user_name) gid=1241400014(user_name) Groups=1241400014(user_name)
- Override the account's UID with 6666:
# sss_override user-add user -u 6666
- Wait until the in-memory cache has been expired. To expire it manually:
# sss_cache --users
- Verify that the new UID is applied:
# id user uid=6666(user_name) gid=1241400014(user_name) Groups=1241400014(user_name)
- Optional. Display the overrides for the user:
# sss_override user-show user user@ldap.example.com::6666:::::
--help
to the command:
# sss_override user-add --help
7.6.2. Listing All Overrides on a Host
# sss_override user-find user1@ldap.example.com::8000::::/bin/zsh: user2@ldap.example.com::8001::::/bin/bash: ...
# sss_override group-find group1@ldap.example.com::7000 group2@ldap.example.com::7001 ...
7.6.3. Removing a Local Override
# sss_override user-del user
# sss_override group-del group
Note
7.6.4. Exporting and Importing Local Views
# sss_override user-export /var/lib/sss/backup/sssd_user_overrides.bak # sss_override group-export /var/lib/sss/backup/sssd_group_overrides.bak
# sss_override user-import /var/lib/sss/backup/sssd_user_overrides.bak # sss_override group-import /var/lib/sss/backup/sssd_group_overrides.bak
7.7. Downgrading SSSD
(Wed Nov 28 21:25:50 2012) [sssd] [sysdb_domain_init_internal] (0x0010): Unknown DB version [0.14], expected [0.10] for domain AD!
- Delete the existing cache database files.
[root@server ~]# rm -rf /var/lib/sss/db/*
- Restart the SSSD process.
[root@server ~]# systemctl restart sssd.service
7.8. Using NSCD with SSSD
resolv.conf
file. This file is typically only read once, and so any changes made to this file are not automatically applied. This can cause NFS locking to fail on the machine where the NSCD service is running, unless that service is manually restarted.
7.9. Additional Resources
- A complete list of SSSD-related man pages is available in the
SEE ALSO
section in the sssd(8) man page. - Troubleshooting advice: Section A.1, “Troubleshooting SSSD”.
- A procedure for configuring SSSD to process password expiration warnings sent by the server and display them to users on the local system: Setting Password Expiry in Red Hat Knowledgebase
- An SSSD client can automatically create a GID for every user retrieved from an LDAP server, and at the same time ensure that the GID matches the user's UID unless the GID number is already taken. To see how automatic creation of GIDs can be set up on an SSSD client which is directly integrated into Active Directory, see the corresponding section in the Windows Integration Guide.
Chapter 8. Using realmd
to Connect to an Identity Domain
realmd
system provides a clear and simple way to discover and join identity domains. It does not connect to the domain itself but configures underlying Linux system services, such as SSSD or Winbind, to connect to the domain.
realmd
to connect to a Microsoft Active Directory (AD) domain. The same procedures apply to using realmd
to connect to non-AD identity domains. See Using realmd to Connect to an Active Directory Domain in the Windows Integration Guide.
Chapter 9. LDAP Servers
LDAP
(Lightweight Directory Access Protocol) is a set of open protocols used to access centrally stored information over a network. It is based on the X.500
standard for directory sharing, but is less complex and resource-intensive. For this reason, LDAP is sometimes referred to as “X.500 Lite”.
9.1. Red Hat Directory Server
Note
9.2. OpenLDAP
Note
9.2.1. Introduction to LDAP
Important
Important
SSLv3
protocol for security. OpenLDAP is one of the system components that do not provide configuration parameters that allow SSLv3
to be effectively disabled. To mitigate the risk, it is recommended that you use the stunnel
command to provide a secure tunnel, and disable stunnel from using SSLv3
. For more information on using stunnel, see the Red Hat Enterprise Linux 7 Security Guide.
9.2.1.1. LDAP Terminology
- entry
- A single unit within an LDAP directory. Each entry is identified by its unique Distinguished Name (DN).
- attribute
- Information directly associated with an entry. For example, if an organization is represented as an LDAP entry, attributes associated with this organization might include an address, a fax number, and so on. Similarly, people can be represented as entries with common attributes such as personal telephone number or email address.An attribute can either have a single value, or an unordered space-separated list of values. While certain attributes are optional, others are required. Required attributes are specified using the
objectClass
definition, and can be found in schema files located in the/etc/openldap/slapd.d/cn=config/cn=schema/
directory.The assertion of an attribute and its corresponding value is also referred to as a Relative Distinguished Name (RDN). Unlike distinguished names that are unique globally, a relative distinguished name is only unique per entry. - LDIF
- The LDAP Data Interchange Format (LDIF) is a plain text representation of an LDAP entry. It takes the following form:
[id] dn: distinguished_name attribute_type: attribute_value… attribute_type: attribute_value… …
The optional id is a number determined by the application that is used to edit the entry. Each entry can contain as many attribute_type and attribute_value pairs as needed, as long as they are all defined in a corresponding schema file. A blank line indicates the end of an entry.
9.2.1.2. OpenLDAP Features
- LDAPv3 Support — Many of the changes in the protocol since LDAP version 2 are designed to make LDAP more secure. Among other improvements, this includes the support for Simple Authentication and Security Layer (SASL), Transport Layer Security (TLS), and Secure Sockets Layer (SSL) protocols.
- LDAP Over IPC — The use of inter-process communication (IPC) enhances security by eliminating the need to communicate over a network.
- IPv6 Support — OpenLDAP is compliant with Internet Protocol version 6 (IPv6), the next generation of the Internet Protocol.
- LDIFv1 Support — OpenLDAP is fully compliant with LDIF version 1.
- Updated C API — The current C API improves the way programmers can connect to and use LDAP directory servers.
- Enhanced Standalone LDAP Server — This includes an updated access control system, thread pooling, better tools, and much more.
9.2.1.3. OpenLDAP Server Setup
- Install the OpenLDAP suite. See Section 9.2.2, “Installing the OpenLDAP Suite” for more information on required packages.
- Customize the configuration as described in Section 9.2.3, “Configuring an OpenLDAP Server”.
- Start the
slapd
service as described in Section 9.2.5, “Running an OpenLDAP Server”. - Use the
ldapadd
utility to add entries to the LDAP directory. - Use the
ldapsearch
utility to verify that theslapd
service is accessing the information correctly.
9.2.2. Installing the OpenLDAP Suite
Package | Description |
---|---|
openldap | A package containing the libraries necessary to run the OpenLDAP server and client applications. |
openldap-clients | A package containing the command line utilities for viewing and modifying directories on an LDAP server. |
openldap-servers | A package containing both the services and utilities to configure and run an LDAP server. This includes the Standalone LDAP Daemon, slapd . |
compat-openldap | A package containing the OpenLDAP compatibility libraries. |
Package | Description |
---|---|
nss-pam-ldapd | A package containing nslcd , a local LDAP name service that allows a user to perform local LDAP queries. |
mod_ldap |
A package containing the
mod_authnz_ldap and mod_ldap modules. The mod_authnz_ldap module is the LDAP authorization module for the Apache HTTP Server. This module can authenticate users' credentials against an LDAP directory, and can enforce access control based on the user name, full DN, group membership, an arbitrary attribute, or a complete filter string. The mod_ldap module contained in the same package provides a configurable shared memory cache, to avoid repeated directory access across many HTTP requests, and also support for SSL/TLS. Note that this package is provided by the Optional channel. See Adding the Optional and Supplementary Repositories in the System Administrator's Guide for more information on Red Hat additional channels.
|
yum
command in the following form:
yum
install
package…
~]# yum install openldap openldap-clients openldap-servers
root
) to run this command. For more information on how to install new packages in Red Hat Enterprise Linux, see Installing Packages in the System Administrator's Guide.
9.2.2.1. Overview of OpenLDAP Server Utilities
slapd
service:
Command | Description |
---|---|
slapacl | Allows you to check the access to a list of attributes. |
slapadd | Allows you to add entries from an LDIF file to an LDAP directory. |
slapauth | Allows you to check a list of IDs for authentication and authorization permissions. |
slapcat | Allows you to pull entries from an LDAP directory in the default format and save them in an LDIF file. |
slapdn | Allows you to check a list of Distinguished Names (DNs) based on available schema syntax. |
slapindex | Allows you to re-index the slapd directory based on the current content. Run this utility whenever you change indexing options in the configuration file. |
slappasswd | Allows you to create an encrypted user password to be used with the ldapmodify utility, or in the slapd configuration file. |
slapschema | Allows you to check the compliance of a database with the corresponding schema. |
slaptest | Allows you to check the LDAP server configuration. |
Important
root
can run slapadd
, the slapd
service runs as the ldap
user. Because of this, the directory server is unable to modify any files created by slapadd
. To correct this issue, after running the slapdadd
utility, type the following at a shell prompt:
~]# chown -R ldap:ldap /var/lib/ldap
Warning
slapd
service before using slapadd
, slapcat
, or slapindex
. You can do so by typing the following at a shell prompt:
~]# systemctl stop slapd.service
slapd
service, see Section 9.2.5, “Running an OpenLDAP Server”.
9.2.2.2. Overview of OpenLDAP Client Utilities
Command | Description |
---|---|
ldapadd | Allows you to add entries to an LDAP directory, either from a file, or from standard input. It is a symbolic link to ldapmodify -a . |
ldapcompare | Allows you to compare given attribute with an LDAP directory entry. |
ldapdelete | Allows you to delete entries from an LDAP directory. |
ldapexop | Allows you to perform extended LDAP operations. |
ldapmodify | Allows you to modify entries in an LDAP directory, either from a file, or from standard input. |
ldapmodrdn | Allows you to modify the RDN value of an LDAP directory entry. |
ldappasswd | Allows you to set or change the password for an LDAP user. |
ldapsearch | Allows you to search LDAP directory entries. |
ldapurl | Allows you to compose or decompose LDAP URLs. |
ldapwhoami | Allows you to perform a whoami operation on an LDAP server. |
ldapsearch
, each of these utilities is more easily used by referencing a file containing the changes to be made rather than typing a command for each entry to be changed within an LDAP directory. The format of such a file is outlined in the man page for each utility.
9.2.2.3. Overview of Common LDAP Client Applications
9.2.3. Configuring an OpenLDAP Server
/etc/openldap/
directory. The following table highlights the most important directories and files within this directory:
/etc/openldap/slapd.conf
file. Instead, it uses a configuration database located in the /etc/openldap/slapd.d/
directory. If you have an existing slapd.conf
file from a previous installation, you can convert it to the new format by running the following command:
~]# slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d/
slapd
configuration consists of LDIF entries organized in a hierarchical directory structure, and the recommended way to edit these entries is to use the server utilities described in Section 9.2.2.1, “Overview of OpenLDAP Server Utilities”.
Important
slapd
service unable to start. Because of this, it is strongly advised that you avoid editing the LDIF files within the /etc/openldap/slapd.d/
directly.
9.2.3.1. Changing the Global Configuration
/etc/openldap/slapd.d/cn=config.ldif
file. The following directives are commonly used:
-
olcAllows
- The
olcAllows
directive allows you to specify which features to enable. It takes the following form:olcAllows
: feature…It accepts a space-separated list of features as described in Table 9.6, “AvailableolcAllows
options”. The default option isbind_v2
.Table 9.6. Available olcAllows options Option Description bind_v2
Enables the acceptance of LDAP version 2 bind requests. bind_anon_cred
Enables an anonymous bind when the Distinguished Name (DN) is empty. bind_anon_dn
Enables an anonymous bind when the Distinguished Name (DN) is not empty. update_anon
Enables processing of anonymous update operations. proxy_authz_anon
Enables processing of anonymous proxy authorization control. Example 9.1. Using the
olcAllows
directiveolcAllows: bind_v2 update_anon
-
olcConnMaxPending
- The
olcConnMaxPending
directive allows you to specify the maximum number of pending requests for an anonymous session. It takes the following form:olcConnMaxPending
: numberThe default option is100
.Example 9.2. Using the
olcConnMaxPending
directiveolcConnMaxPending: 100
-
olcConnMaxPendingAuth
- The
olcConnMaxPendingAuth
directive allows you to specify the maximum number of pending requests for an authenticated session. It takes the following form:olcConnMaxPendingAuth
: numberThe default option is1000
.Example 9.3. Using the
olcConnMaxPendingAuth
directiveolcConnMaxPendingAuth: 1000
-
olcDisallows
- The
olcDisallows
directive allows you to specify which features to disable. It takes the following form:olcDisallows
: feature…It accepts a space-separated list of features as described in Table 9.7, “AvailableolcDisallows
options”. No features are disabled by default.Table 9.7. Available olcDisallows options Option Description bind_anon
Disables the acceptance of anonymous bind requests. bind_simple
Disables the simple bind authentication mechanism. tls_2_anon
Disables the enforcing of an anonymous session when the STARTTLS command is received. tls_authc
Disallows the STARTTLS command when authenticated. Example 9.4. Using the
olcDisallows
directiveolcDisallows: bind_anon
-
olcIdleTimeout
- The
olcIdleTimeout
directive allows you to specify how many seconds to wait before closing an idle connection. It takes the following form:olcIdleTimeout
: numberThis option is disabled by default (that is, set to0
).Example 9.5. Using the
olcIdleTimeout
directiveolcIdleTimeout: 180
-
olcLogFile
- The
olcLogFile
directive allows you to specify a file in which to write log messages. It takes the following form:olcLogFile
: file_nameThe log messages are written to standard error by default.Example 9.6. Using the
olcLogFile
directiveolcLogFile: /var/log/slapd.log
-
olcReferral
- The
olcReferral
option allows you to specify a URL of a server to process the request in case the server is not able to handle it. It takes the following form:olcReferral
: URLThis option is disabled by default.Example 9.7. Using the
olcReferral
directiveolcReferral: ldap://root.openldap.org
-
olcWriteTimeout
- The
olcWriteTimeout
option allows you to specify how many seconds to wait before closing a connection with an outstanding write request. It takes the following form:olcWriteTimeout
This option is disabled by default (that is, set to0
).Example 9.8. Using the
olcWriteTimeout
directiveolcWriteTimeout: 180
9.2.3.2. The Front End Configuration
etc/openldap/slapd.d/cn=config/olcDatabase={-1}frontend.ldif
file and defines global database options, such as access control lists (ACL). For details, see the Global Database Options section in the slapd-config(5) man page.
9.2.3.3. The Monitor Back End
/etc/openldap/slapd.d/cn=config/olcDatabase={1}monitor.ldif
file controls the OpenLDAP monitor back end. If enabled, it is automatically generated and dynamically updated by OpenLDAP with information about the running status of the daemon. The suffix is cn=Monitor
and cannot be changed. For further details, see the slapd-monitor(5) man page.
9.2.3.4. Database-Specific Configuration
hdb
database back end. Besides that it uses a hierarchical database layout which supports subtree renames, it is identical to the bdb
back end and uses the same configuration options. The configuration for this database back end is stored in the /etc/openldap/slapd.d/cn=config/olcDatabase={2}hdb.ldif
file.
# man slapd-hdb
Note
bdb
and hdb
back ends are deprecated. Consider using the mdb
back end for new installations instead.
-
olcReadOnly
- The
olcReadOnly
directive allows you to use the database in a read-only mode. It takes the following form:olcReadOnly
: booleanIt accepts eitherTRUE
(enable the read-only mode), orFALSE
(enable modifications of the database). The default option isFALSE
.Example 9.9. Using the
olcReadOnly
directiveolcReadOnly: TRUE
-
olcRootDN
- The
olcRootDN
directive allows you to specify the user that is unrestricted by access controls or administrative limit parameters set for operations on the LDAP directory. It takes the following form:olcRootDN
: distinguished_nameIt accepts a Distinguished Name (DN). The default option iscn=Manager,dn=my-domain,dc=com
.Example 9.10. Using the
olcRootDN
directiveolcRootDN: cn=root,dn=example,dn=com
-
olcRootPW
- The
olcRootPW
directive allows you to set a password for the user that is specified using theolcRootDN
directive. It takes the following form:olcRootPW
: passwordIt accepts either a plain text string, or a hash. To generate a hash, type the following at a shell prompt:~]$
slappaswd
New password: Re-enter new password: {SSHA}WczWsyPEnMchFf1GRTweq2q7XJcvmSxDExample 9.11. Using the
olcRootPW
directiveolcRootPW: {SSHA}WczWsyPEnMchFf1GRTweq2q7XJcvmSxD
-
olcSuffix
- The
olcSuffix
directive allows you to specify the domain for which to provide information. It takes the following form:olcSuffix
: domain_nameIt accepts a fully qualified domain name (FQDN). The default option isdc=my-domain,dc=com
.Example 9.12. Using the
olcSuffix
directiveolcSuffix: dc=example,dc=com
9.2.3.5. Extending Schema
/etc/openldap/slapd.d/
directory also contains LDAP definitions that were previously located in /etc/openldap/schema/
. It is possible to extend the schema used by OpenLDAP to support additional attribute types and object classes using the default schema files as a guide. However, this task is beyond the scope of this chapter. For more information on this topic, see https://openldap.org/doc/admin24/schema.html.
9.2.3.6. Establishing a Secure Connection
Server Configuration
slapd
that need to be specified in the /etc/openldap/slapd.d/cn=config.ldif
file on an OpenLDAP server in order to establish TLS.
/usr/local/etc/openldap/slapd.conf
, the new style uses a slapd
back end database to store the configuration. The configuration database normally resides in the /usr/local/etc/openldap/slapd.d/
directory.
/etc/sysconfig/slapd
file and append the ldaps:///
string to the list of URLs specified with the SLAPD_URLS
directive.
-
olcTLSCACertificateFile
- The
olcTLSCACertificateFile
directive specifies the file encoded with privacy-enhanced mail (PEM) schema that contains trusted CA certificates. The directive takes the following form:olcTLSCACertificateFile
: pathReplace path with the path to the CA certificate file. -
olcTLSCACertificatePath
- The
olcTLSCACertificatePath
directive specifies the path to a directory containing individual CA certificates in separate files. This directory must be specially managed with the OpenSSL c_rehash utility that generates symbolic links with the hashed names that point to the actual certificate files. In general, it is simpler to use theolcTLSCACertificateFile
directive instead.The directive takes the following form:olcTLSCACertificatePath
: pathReplace path with a path to the directory containing the CA certificate files. The specified directory must be managed with the OpenSSL c_rehash utility. -
olcTLSCertificateFile
- The
olcTLSCertificateFile
directive specifies the file that contains theslapd
server certificate. The directive takes the following form:olcTLSCertificateFile
: pathReplace path with a path to the server certificate file of theslapd
service. -
olcTLSCertificateKeyFile
- The
olcTLSCertificateKeyFile
directive specifies the file that contains the private key that matches the certificate stored in the file specified witholcTLSCertificateFile
. Note that the current implementation does not support encrypted private keys, and therefore the containing file must be sufficiently protected. The directive takes the following form:olcTLSCertificateKeyFile
: pathReplace path with a path to the private key file.
Client Configuration
/etc/openldap/ldap.conf
configuration file on the client system. Most of these directives are parallel to the server configuration options. Directives in/etc/openldap/ldap.conf
are configured on a system-wide basis, however, individual users may override them in their ~/.ldaprc
files.
ldaps://
string must be used instead of ldap://
in OpenLDAP commands such as ldapsearch
. This forces commands to use the default port for SSL, port 636, configured on the server.
-
TLS_CACERT
- The
TLS_CACERT
directive specifies a file containing certificates for all of the Certificate Authorities the client will recognize. This is equivalent to theolcTLSCACertificateFile
directive on a server.TLS_CACERT
should always be specified beforeTLS_CACERTDIR
in/etc/openldap/ldap.conf
. The directive takes the following form:TLS_CACERT
pathReplace path with a path to the CA certificate file. -
TLS_CACERTDIR
- The
TLS_CACERTDIR
directive specifies the path to a directory that contains Certificate Authority certificates in separate files. As witholcTLSCACertificatePath
on a server, the specified directory must be managed with the OpenSSL c_rehash utility.TLS_CACERTDIR
directoryReplace directory with a path to the directory containing CA certificate files. -
TLS_CERT
- The
TLS_CERT
specifies the file that contains a client certificate. This directive can only be specified in a user's~/.ldaprc
file. The directive takes the following form:TLS_CERT
pathReplace path with a path to the client certificate file. -
TLS_KEY
- The
TLS_KEY
specifies the file that contains the private key that matches the certificate stored in the file specified with theTLS_CERT
directive. As witholcTLSCertificateFile
on a server, encrypted key files are not supported, so the file itself must be carefully protected. This option is only configurable in a user's~/.ldaprc
file.TheTLS_KEY
directive takes the following form:TLS_KEY
pathReplace path with a path to the client certificate file.
9.2.3.7. Setting Up Replication
/etc/openldap/slapd.d/
on both provider and consumers.
-
olcMirrorMode
- The
olcMirrorMode
directive enables the mirror replication mode. It takes the following form:olcMirrorMode
on
This option needs to be specified both on provider and consumers. Also aserverID
must be specified along withsyncrepl
options. Find a detailed example in the 18.3.4. MirrorMode section of the OpenLDAP Software Administrator's Guide (see the section called “Installed Documentation”). -
olcSyncrepl
- The
olcSyncrepl
directive enables the sync replication mode. It takes the following form:olcSyncrepl
on
The sync replication mode requires a specific configuration on both the provider and the consumers. This configuration is thoroughly described in the 18.3.1. Syncrepl section of the OpenLDAP Software Administrator's Guide (see the section called “Installed Documentation”).
9.2.3.8. Loading Modules and Back ends
slapd
service with dynamically loaded modules. Support for these modules must be enabled with the --enable-modules
option when configuring slapd
. Modules are stored in files with the .la extension:
module_name.la
slapd
, or when module support is enabled, they may be dynamically loaded. In the latter case, the following naming convention is applied:
back_backend_name.la
/etc/openldap/slapd.d/
:
-
olcModuleLoad
- The
olcModuleLoad
directive specifies a dynamically loadable module to load. It takes the following form:olcModuleLoad
: moduleHere, module stands either for a file containing the module, or a back end, that will be loaded.
9.2.4. SELinux Policy for Applications Using LDAP
allow_ypbind
SELinux Boolean needs to be enabled. Certain applications also demand an enabled authlogin_nsswitch_use_ldap
Boolean in this scenario. Execute the following commands to enable the aforementioned Booleans:
~]#setsebool
-P
allow_ypbind
=1
~]#setsebool
-P
authlogin_nsswitch_use_ldap
=1
-P
option makes this setting persistent across system reboots. See the Red Hat Enterprise Linux 7 SELinux User's and Administrator's Guide for more detailed information about SELinux.
9.2.5. Running an OpenLDAP Server
9.2.5.1. Starting the Service
slapd
service in the current session, type the following at a shell prompt as root
:
~]# systemctl start slapd.service
root
:
~]# systemctl enable slapd.service
ln -s '/usr/lib/systemd/system/slapd.service' '/etc/systemd/system/multi-user.target.wants/slapd.service'
9.2.5.2. Stopping the Service
slapd
service in the current session, type the following at a shell prompt as root
:
~]# systemctl stop slapd.service
root
:
~]# systemctl disable slapd.service
rm '/etc/systemd/system/multi-user.target.wants/slapd.service'
9.2.6. Configuring a System to Authenticate Using OpenLDAP
~]# yum install openldap openldap-clients nss-pam-ldapd
9.2.6.1. Migrating Old Authentication Information to LDAP Format
~]# yum install migrationtools
/usr/share/migrationtools/
directory. Once installed, edit the /usr/share/migrationtools/migrate_common.ph
file and change the following lines to reflect the correct domain, for example:
# Default DNS domain $DEFAULT_MAIL_DOMAIN = "example.com"; # Default base $DEFAULT_BASE = "dc=example,dc=com";
migrate_all_online.sh
script with the default base set to dc=example,dc=com
, type:
~]#export DEFAULT_BASE="dc=example,dc=com" \
/usr/share/migrationtools/migrate_all_online.sh
Existing Name Service | Is LDAP Running? | Script to Use |
---|---|---|
/etc flat files | yes | migrate_all_online.sh |
/etc flat files | no | migrate_all_offline.sh |
NetInfo | yes | migrate_all_netinfo_online.sh |
NetInfo | no | migrate_all_netinfo_offline.sh |
NIS (YP) | yes | migrate_all_nis_online.sh |
NIS (YP) | no | migrate_all_nis_offline.sh |
README
and the migration-tools.txt
files in the /usr/share/doc/migrationtools-version/
directory.
9.2.7. Additional Resources
Installed Documentation
/usr/share/doc/openldap-servers-version/guide.html
— A copy of the OpenLDAP Software Administrator's Guide./usr/share/doc/openldap-servers-version/README.schema
— A README file containing the description of installed schema files.
- Client Applications
- ldapadd(1) — The manual page for the
ldapadd
command describes how to add entries to an LDAP directory. - ldapdelete(1) — The manual page for the
ldapdelete
command describes how to delete entries within an LDAP directory. - ldapmodify(1) — The manual page for the
ldapmodify
command describes how to modify entries within an LDAP directory. - ldapsearch(1) — The manual page for the
ldapsearch
command describes how to search for entries within an LDAP directory. - ldappasswd(1) — The manual page for the
ldappasswd
command describes how to set or change the password of an LDAP user. - ldapcompare(1) — Describes how to use the
ldapcompare
tool. - ldapwhoami(1) — Describes how to use the
ldapwhoami
tool. - ldapmodrdn(1) — Describes how to modify the RDNs of entries.
- Server Applications
- slapd(8C) — Describes command line options for the LDAP server.
- Administrative Applications
- slapadd(8C) — Describes command line options used to add entries to a
slapd
database. - slapcat(8C) — Describes command line options used to generate an LDIF file from a
slapd
database. - slapindex(8C) — Describes command line options used to regenerate an index based upon the contents of a
slapd
database. - slappasswd(8C) — Describes command line options used to generate user passwords for LDAP directories.
- Configuration Files
- ldap.conf(5) — The manual page for the
ldap.conf
file describes the format and options available within the configuration file for LDAP clients. - slapd-config(5) — Describes the format and options available within the
/etc/openldap/slapd.d
configuration directory.
Other Resources
- OpenLDAP and Mozilla NSS Compatibility Layer Implementation details of NSS database backwards compatibility.
- How do I use TLS/SSL? Information on how to configure OpenLDAP to use OpenSSL.
Part III. Secure Applications
Pluggable Authentication Modules
(PAM
), how to use the Kerberos
authentication protocol and the certmonger
daemon, and, finally, how to configure applications for Single sign-on
(SSO
).
Chapter 10. Using Pluggable Authentication Modules (PAM)
10.1. About PAM
- PAM provides a common authentication scheme that can be used with a wide variety of applications.
- PAM provides significant flexibility and control over authentication for system administrators.
- PAM provides a single, fully-documented library which allows developers to write programs without having to create their own authentication schemes.
10.1.1. Other PAM Resources
/usr/share/doc/pam-
version#
/
directory contains a System Administrators' Guide, a Module Writers' Manual, and the Application Developers' Manual, as well as a copy of the PAM standard, DCE-RFC 86.0.
10.1.2. Custom PAM Modules
/usr/share/doc/pam-devel-
version#
/
directory.
10.2. About PAM Configuration Files
/etc/pam.d/
directory. Each file in this directory has the same name as the service to which it controls access. For example, the login
program defines its service name as login
and installs the /etc/pam.d/login
PAM configuration file.
Warning
authconfig
tool instead of manually editing the PAM configuration files.
10.2.1. PAM Configuration File Format
module_interface control_flag module_name module_arguments
auth required pam_unix.so
auth
— This module interface authenticates users. For example, it requests and verifies the validity of a password. Modules with this interface can also set credentials, such as group memberships.account
— This module interface verifies that access is allowed. For example, it checks if a user account has expired or if a user is allowed to log in at a particular time of day.password
— This module interface is used for changing user passwords.session
— This module interface configures and manages user sessions. Modules with this interface can also perform additional tasks that are needed to allow access, like mounting a user's home directory and making the user's mailbox available.
pam_unix.so
provides all four module interfaces.
pam_unix.so
, provides PAM with the name of the library containing the specified module interface. The directory name is omitted because the application is linked to the appropriate version of libpam
, which can locate the correct version of the module.
required
— The module result must be successful for authentication to continue. If the test fails at this point, the user is not notified until the results of all module tests that reference that interface are complete.requisite
— The module result must be successful for authentication to continue. However, if a test fails at this point, the user is notified immediately with a message reflecting the first failedrequired
orrequisite
module test.sufficient
— The module result is ignored if it fails. However, if the result of a module flaggedsufficient
is successful and no previous modules flaggedrequired
have failed, then no other results are required and the user is authenticated to the service.optional
— The module result is ignored. A module flagged asoptional
only becomes necessary for successful authentication when no other modules reference the interface.include
— Unlike the other controls, this does not relate to how the module result is handled. This flag pulls in all lines in the configuration file which match the given parameter and appends them as an argument to the module.
Note
sufficient
or requisite
value, then the order in which the modules are listed is important to the authentication process.
setup
utility normally uses several stacked modules, as seen in its PAM configuration file:
[root@MyServer ~]# cat /etc/pam.d/setup auth sufficient pam_rootok.so auth include system-auth account required pam_permit.so session required pam_permit.so
auth sufficient pam_rootok.so
— This line uses thepam_rootok.so
module to check whether the current user is root, by verifying that their UID is 0. If this test succeeds, no other modules are consulted and the command is executed. If this test fails, the next module is consulted.auth include system-auth
— This line includes the content of the/etc/pam.d/system-auth
module and processes this content for authentication.account required pam_permit.so
— This line uses thepam_permit.so
module to allow the root user or anyone logged in at the console to reboot the system.session required pam_permit.so
— This line is related to the session setup. Usingpam_permit.so
, it ensures that thesetup
utility does not fail.
pam_pwquality.so
module checks how strong a password is and can take several arguments. In the following example, enforce_for_root
specifies that even password of the root user must successfully pass the strength check and retry
defines that a user will receive three opportunities to enter a strong password.
password requisite pam_pwquality.so enforce_for_root retry=3
journald
service. For information on how to use journald
and the related journalctl
tool, see the System Administrator's Guide.
Note
journald
service was introduced in Red Hat Enterprise Linux 7.1. In previous versions of Red Hat Enterprise Linux, most modules report errors to the /var/log/secure
file.
10.2.2. Annotated PAM Configuration Example
Example 10.1. Simple PAM Configuration
#%PAM-1.0 auth required pam_securetty.so auth required pam_unix.so nullok auth required pam_nologin.so account required pam_unix.so password required pam_pwquality.so retry=3 password required pam_unix.so shadow nullok use_authtok session required pam_unix.so
- The first line is a comment, indicated by the hash mark (
#
) at the beginning of the line. - Lines two through four stack three modules for login authentication.
auth required pam_securetty.so
— This module ensures that if the user is trying to log in as root, the TTY on which the user is logging in is listed in the/etc/securetty
file, if that file exists.If the TTY is not listed in the file, any attempt to log in as root fails with aLogin incorrect
message.auth required pam_unix.so nullok
— This module prompts the user for a password and then checks the password using the information stored in/etc/passwd
and, if it exists,/etc/shadow
.The argumentnullok
instructs thepam_unix.so
module to allow a blank password. auth required pam_nologin.so
— This is the final authentication step. It checks whether the/etc/nologin
file exists. If it exists and the user is not root, authentication fails.Note
In this example, all threeauth
modules are checked, even if the firstauth
module fails. This prevents the user from knowing at what stage their authentication failed. Such knowledge in the hands of an attacker could allow them to more easily deduce how to crack the system.account required pam_unix.so
— This module performs any necessary account verification. For example, if shadow passwords have been enabled, the account interface of thepam_unix.so
module checks to see if the account has expired or if the user has not changed the password within the allowed grace period.password required pam_pwquality.so retry=3
— If a password has expired, the password component of thepam_pwquality.so
module prompts for a new password. It then tests the newly created password to see whether it can easily be determined by a dictionary-based password cracking program.The argumentretry=3
specifies that if the test fails the first time, the user has two more chances to create a strong password.password required pam_unix.so shadow nullok use_authtok
— This line specifies that if the program changes the user's password, using thepassword
interface of thepam_unix.so
module.- The argument
shadow
instructs the module to create shadow passwords when updating a user's password. - The argument
nullok
instructs the module to allow the user to change their password from a blank password, otherwise a null password is treated as an account lock. - The final argument on this line,
use_authtok
, provides a good example of the importance of order when stacking PAM modules. This argument instructs the module not to prompt the user for a new password. Instead, it accepts any password that was recorded by a previous password module. In this way, all new passwords must pass thepam_pwquality.so
test for secure passwords before being accepted.
session required pam_unix.so
— The final line instructs the session interface of thepam_unix.so
module to manage the session. This module logs the user name and the service type to/var/log/secure
at the beginning and end of each session. This module can be supplemented by stacking it with other session modules for additional functionality.
10.3. PAM and Administrative Credential Caching
control-center
, provide users with elevated privileges for up to five minutes using the pam_timestamp.so
module. It is important to understand how this mechanism works, because a user who walks away from a terminal while pam_timestamp.so
is in effect leaves the machine open to manipulation by anyone with physical access to the console.
pam_timestamp.so
module creates a timestamp file. By default, this is created in the /var/run/sudo/
directory. If the timestamp file already exists, graphical administrative programs do not prompt for a password. Instead, the pam_timestamp.so
module freshens the timestamp file, reserving an extra five minutes of unchallenged administrative access for the user.
/var/run/sudo/
user directory. For the desktop, the relevant file is unknown:root
. If it is present and its timestamp is less than five minutes old, the credentials are valid.
Figure 10.1. The Authentication Icon
10.3.1. Common pam_timestamp Directives
pam_timestamp.so
module provides these two interfaces:
auth
session
pam_timestamp.so
:
timestamp_timeout
: specifies the validity period (in seconds) of the timestamp file, by default 300 (five minutes).timestampdir
: specifies in which directory the timestamp file is stored, by default/var/run/sudo/
.- You can also use
verbose
ordebug
for more detailed messages.
auth sufficient pam_timestamp.so timestamp_timeout=600 session optional pam_timestamp.so
pam_timestamp(8)
man page and the pam.conf(5)
man page.
10.3.2. Removing the Timestamp File
Figure 10.2. Dismiss Authentication Dialog
- If logged in to the system remotely using
ssh
, use the/sbin/pam_timestamp_check -k root
command to destroy the timestamp file. - Run the
/sbin/pam_timestamp_check -k root
command from the same terminal window where the privileged application was launched. - The logged in user who originally invoked the
pam_timestamp.so
module must be the user who runs the/sbin/pam_timestamp_check -k
command. Do not run this command as root. - Killing the credentials on the desktop without using theaction on the icon can be done with the
/sbin/pam_timestamp_check
command./sbin/pam_timestamp_check -k root </dev/null >/dev/null 2>/dev/null
Any other method only removes the credentials from the PTY where the command was run.
pam_timestamp_check
man page for more information about destroying the timestamp file using pam_timestamp_check
.
10.4. Restricting Domains for PAM services
Important
Note
pam_ldap
, which were able to use a separate configuration file as a parameter for a PAM module.
Options to Restrict Access to Domains
pam_trusted_users
in/etc/sssd/sssd.conf
- This option accepts a list of numerical UIDs or user names representing the PAM services that are to be trusted by SSSD. The default setting is
all
, which means all service users are trusted and can access any domain. pam_public_domains
in/etc/sssd/sssd.conf
- This option accepts a list of public SSSD domains. Public domains are domains accessible even for untrusted PAM service users. The option also accepts the
all
andnone
values. The default value isnone
, which means no domains are public and untrusted service users therefore cannot access any domain. domains
for PAM configuration files- This option specifies a list of domains against which a PAM service can authenticate. If you use
domains
without specifying any domain, the PAM service will not be able to authenticate against any domain, for example:auth required pam_sss.so domains=
Ifdomains
is not used in the PAM configuration file, the PAM service is able to authenticate against all domains, on the condition that the service is running under a trusted user.Thedomains
option in the/etc/sssd/sssd.conf
SSSD configuration file also specifies a list of domains to which SSSD attempts to authenticate. Note that thedomains
option in a PAM configuration file cannot extend the list of domains insssd.conf
, it can only restrict thesssd.conf
list of domains by specifying a shorter list. Therefore, if a domain is specified in the PAM file but not insssd.conf
, the PAM service will not be able to authenticate against the domain.
pam_trusted_users = all
and pam_public_domains = none
specify that all PAM service users are trusted and can access any domain. The domains
option for PAM configuration files can be used in this situation to restrict the domains that can be accessed.
domains
in the PAM configuration file while sssd.conf
contains pam_public_domains
, it might be required to specify the domain in pam_public_domains
as well. If pam_public_domains
is used but does not include the required domain, the PAM service will not be able to successfully authenticate against the domain if it is running under an untrusted user.
Note
pam_trusted_users
and pam_public_domains
options, see the sssd.conf(5) man page. For more information about the domains
option used in PAM configuration files, see the pam_sss(8) man page.
Example 10.2. Restricting Domains for a PAM Service
- Make sure SSSD is configured to access the required domain or domains. The domains against which SSSD can authenticate are defined in the
domains
option in the/etc/sssd/sssd.conf
file.[sssd] domains = domain1, domain2, domain3
- Specify the domain or domains to which a PAM service will be able to authenticate. To do this, set the
domains
option in the PAM configuration file. For example:auth sufficient pam_sss.so forward_pass domains=domain1 account [default=bad success=ok user_unknown=ignore] pam_sss.so password sufficient pam_sss.so use_authtok
domain1
.
pam.d
manpage.
Chapter 11. Using Kerberos
11.1. About Kerberos
11.1.1. The Basics of How Kerberos Works
kinit
program after the user logs in.
Figure 11.1. Kerberos Authentication
kinit
program on the client then decrypts the TGT using the user's key, which it computes from the user's password. The user's key is used only on the client machine and is not transmitted over the network. The ticket (or credentials) sent by the KDC are stored in a local store, the credential cache (ccache), which can be checked by Kerberos-aware services. Red Hat Enterprise Linux 7 supports the following types of credential caches:
- The persistent KEYRING ccache type, the default cache in Red Hat Enterprise Linux 7
- The System Security Services Daemon (SSSD) Kerberos Credential Manager (KCM), an alternative option since Red Hat Enterprise Linux 7.4
- FILE
- DIR
- MEMORY
kinit
, is a KCM client and the daemon is referred to as a KCM server.
- The daemon is stateful and can perform tasks such as Kerberos credential cache renewals or reaping old ccaches. Renewals and tracking are possible not only for tickets that SSSD itself acquired, typically via a login through
pam_sss.so
, but also for tickets acquired, for example, thoughkinit
. - Since the process runs in user space, it is subject to UID namespacing, unlike the Kernel KEYRING.
- Unlike the Kernel KEYRING-based cache, which is entirely dependent on the UID of the caller and which, in a containerized environment, is shared among all containers, the KCM server’s entry point is a UNIX socket that can be bind-mounted only to selected containers.
kinit
; this is kept in a keytab.
11.1.2. About Kerberos Principal Names
identifier@REALM
service/FQDN@REALM
host
, ldap
, http
, and DNS
. Not all services have obvious principal identifiers; the sshd
daemon, for example, uses the host service principal.
/etc/krb5.keytab
.
www.example.com CNAME web-01.example.com web-01.example.com A 192.0.2.145
$ ssh www.example.com
web-01.example.com@EXAMPLE.COM
, so the host principal must be host/web-01.example.com@EXAMPLE.COM
.
11.1.3. About the Domain-to-Realm Mapping
foo.example.org → EXAMPLE.ORG foo.example.com → EXAMPLE.COM foo.hq.example.com → HQ.EXAMPLE.COM
domain_realm
section of the client system's /etc/krb5.conf
file. For example:
[domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM
$ORIGIN example.com _kerberos TXT "EXAMPLE.COM"
11.1.4. Environmental Requirements
/usr/share/doc/krb5-server-
version-number.
ntpd
. For information on the ntpd
service, see the documentation in /usr/share/doc/ntp-
version-number/html/index.html
or the ntpd(8) man page.
Note
11.1.5. Considerations for Deploying Kerberos
- Kerberos assumes that each user is trusted but is using an untrusted host on an untrusted network. Its primary goal is to prevent unencrypted passwords from being transmitted across that network. However, if anyone other than the proper user has access to the one host that issues tickets used for authentication — the KDC — the entire Kerberos authentication system are at risk.
- For an application to use Kerberos, its source must be modified to make the appropriate calls into the Kerberos libraries. Applications modified in this way are considered to be Kerberos-aware. For some applications, this can be quite problematic due to the size of the application or its design. For other incompatible applications, changes must be made to the way in which the server and client communicate. Again, this can require extensive programming. Closed source applications that do not have Kerberos support by default are often the most problematic.
- To secure a network with Kerberos, one must either use Kerberos-aware versions of all client and server applications that transmit passwords unencrypted, or not use that client and server application at all.
- Migrating user passwords from a standard UNIX password database, such as
/etc/passwd
or/etc/shadow
, to a Kerberos password database can be tedious. There is no automated mechanism to perform this task. Migration methods can vary substantially depending on the particular way Kerberos is deployed. That is why it is recommended that you use the Identity Management feature; it has specialized tools and methods for migration.
Warning
11.1.6. Additional Resources for Kerberos
Documentation | Location |
---|---|
Kerberos V5 Installation Guide (in both PostScript and HTML) | /usr/share/doc/krb5-server-version-number |
Kerberos V5 System Administrator's Guide (in both PostScript and HTML) | /usr/share/doc/krb5-server-version-number |
Kerberos V5 UNIX User's Guide (in both PostScript and HTML) | /usr/share/doc/krb5-workstation-version-number |
"Kerberos: The Network Authentication Protocol" web page from MIT | http://web.mit.edu/kerberos/www/ |
Designing an Authentication System: a Dialogue in Four Scenes, originally by Bill Bryant in 1988, modified by Theodore Ts'o in 1997. This document is a conversation between two developers who are thinking through the creation of a Kerberos-style authentication system. The conversational style of the discussion makes this a good starting place for people who are completely unfamiliar with Kerberos. | http://web.mit.edu/kerberos/www/dialogue.html |
An article for making a network Kerberos-aware. | http://www.ornl.gov/~jar/HowToKerb.html |
man
command_name.
Manpage | Description |
---|---|
Client Applications | |
kerberos | An introduction to the Kerberos system which describes how credentials work and provides recommendations for obtaining and destroying Kerberos tickets. The bottom of the man page references a number of related man pages. |
kinit | Describes how to use this command to obtain and cache a ticket-granting ticket. |
kdestroy | Describes how to use this command to destroy Kerberos credentials. |
klist | Describes how to use this command to list cached Kerberos credentials. |
Administrative Applications | |
kadmin | Describes how to use this command to administer the Kerberos V5 database. |
kdb5_util | Describes how to use this command to create and perform low-level administrative functions on the Kerberos V5 database. |
Server Applications | |
krb5kdc | Describes available command line options for the Kerberos V5 KDC. |
kadmind | Describes available command line options for the Kerberos V5 administration server. |
Configuration Files | |
krb5.conf | Describes the format and options available within the configuration file for the Kerberos V5 library. |
kdc.conf | Describes the format and options available within the configuration file for the Kerberos V5 AS and KDC. |
11.2. Configuring the Kerberos KDC
Important
11.2.1. Configuring the Master KDC Server
Important
- Install the required packages for the KDC:
[root@server ~]# yum install krb5-server krb5-libs krb5-workstation
- Edit the
/etc/krb5.conf
and/var/kerberos/krb5kdc/kdc.conf
configuration files to reflect the realm name and domain-to-realm mappings. For example:[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h renew_lifetime = 7d forwardable = true allow_weak_crypto = true [realms] EXAMPLE.COM = { kdc = kdc.example.com.:88 admin_server = kdc.example.com default_domain = example.com } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM
A simple realm can be constructed by replacing instances of EXAMPLE.COM and example.com with the correct domain name — being certain to keep uppercase and lowercase names in the correct format — and by changing the KDC from kerberos.example.com to the name of the Kerberos server. By convention, all realm names are uppercase and all DNS host names and domain names are lowercase. The man pages of these configuration files have full details about the file formats. - Create the database using the
kdb5_util
utility.[root@server ~]# kdb5_util create -s
Thecreate
command creates the database that stores keys for the Kerberos realm. The-s
argument creates a stash file in which the master server key is stored. If no stash file is present from which to read the key, the Kerberos server (krb5kdc
) prompts the user for the master server password (which can be used to regenerate the key) every time it starts. - Edit the
/var/kerberos/krb5kdc/kadm5.acl
file. This file is used bykadmind
to determine which principals have administrative access to the Kerberos database and their level of access. For example:*/admin@EXAMPLE.COM *
Most users are represented in the database by a single principal (with a NULL, or empty, instance, such as joe@EXAMPLE.COM). In this configuration, users with a second principal with an instance of admin (for example, joe/admin@EXAMPLE.COM) are able to exert full administrative control over the realm's Kerberos database.Afterkadmind
has been started on the server, any user can access its services by runningkadmin
on any of the clients or servers in the realm. However, only users listed in thekadm5.acl
file can modify the database in any way, except for changing their own passwords.Note
Thekadmin
utility communicates with thekadmind
server over the network, and uses Kerberos to handle authentication. Consequently, the first principal must already exist before connecting to the server over the network to administer it. Create the first principal with thekadmin.local
command, which is specifically designed to be used on the same host as the KDC and does not use Kerberos for authentication. - Create the first principal using
kadmin.local
at the KDC terminal:[root@server ~]# kadmin.local -q "addprinc username/admin"
- Start Kerberos using the following commands:
[root@server ~]# systemctl start krb5kdc.service [root@server ~]# systemctl start kadmin.service
- Add principals for the users using the
addprinc
command withinkadmin
.kadmin
andkadmin.local
are command line interfaces to the KDC. As such, many commands — such asaddprinc
— are available after launching thekadmin
program. Refer to thekadmin
man page for more information. - Verify that the KDC is issuing tickets. First, run
kinit
to obtain a ticket and store it in a credential cache file. Next, useklist
to view the list of credentials in the cache and usekdestroy
to destroy the cache and the credentials it contains.Note
By default,kinit
attempts to authenticate using the same system login user name (not the Kerberos server). If that user name does not correspond to a principal in the Kerberos database,kinit
issues an error message. If that happens, supplykinit
with the name of the correct principal as an argument on the command line:kinit principal
11.2.2. Setting up Secondary KDCs
kadmind
. The master KDC is also the realm's admin server. Additional secondary KDCs keep read-only copies of the database and run kpropd
.
- Install the required packages for the KDC:
[root@slavekdc ~]# yum install krb5-server krb5-libs krb5-workstation
- Copy the master KDC's
krb5.conf
andkdc.conf
files to the secondary KDC. - Start
kadmin.local
from a root shell on the master KDC.- Use the
kadmin.local add_principal
command to create a new entry for the master KDC's host service.[root@masterkdc ~]# kadmin.local -r EXAMPLE.COM Authenticating as principal root/admin@EXAMPLE.COM with password. kadmin: add_principal -randkey host/masterkdc.example.com Principal "host/masterkdc.example.com@EXAMPLE.COM" created. kadmin: ktadd host/masterkdc.example.com Entry for principal host/masterkdc.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/masterkdc.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/masterkdc.example.com with kvno 3, encryption type DES with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/masterkdc.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab. kadmin: quit
- Use the
kadmin.local ktadd
command to set a random key for the service and store the random key in the master's default keytab file.Note
This key is used by thekprop
command to authenticate to the secondary servers. You will only need to do this once, regardless of how many secondary KDC servers you install.
- Start
kadmin
from a root shell on the secondary KDC.- Use the
kadmin.local add_principal
command to create a new entry for the secondary KDC's host service.[root@slavekdc ~]# kadmin -p jsmith/admin@EXAMPLE.COM -r EXAMPLE.COM Authenticating as principal jsmith/admin@EXAMPLE.COM with password. Password for jsmith/admin@EXAMPLE.COM: kadmin: add_principal -randkey host/slavekdc.example.com Principal "host/slavekdc.example.com@EXAMPLE.COM" created. kadmin: ktadd host/slavekdc.example.com@EXAMPLE.COM Entry for principal host/slavekdc.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/slavekdc.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/slavekdc.example.com with kvno 3, encryption type DES with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/slavekdc.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab. kadmin: quit
- Use the
kadmin.local ktadd
command to set a random key for the service and store the random key in the secondary KDC server's default keytab file. This key is used by thekpropd
service when authenticating clients.
- With its service key, the secondary KDC could authenticate any client which would connect to it. Obviously, not all potential clients should be allowed to provide the
kprop
service with a new realm database. To restrict access, thekprop
service on the secondary KDC will only accept updates from clients whose principal names are listed in/var/kerberos/krb5kdc/kpropd.acl
.Add the master KDC's host service's name to that file.[root@slavekdc ~]# echo host/masterkdc.example.com@EXAMPLE.COM > /var/kerberos/krb5kdc/kpropd.acl
- Once the secondary KDC has obtained a copy of the database, it will also need the master key which was used to encrypt it. If the KDC database's master key is stored in a stash file on the master KDC (typically named
/var/kerberos/krb5kdc/.k5.REALM
), either copy it to the secondary KDC using any available secure method, or create a dummy database and identical stash file on the secondary KDC by runningkdb5_util create -s
and supplying the same password. The dummy database will be overwritten by the first successful database propagation. - Ensure that the secondary KDC's firewall allows the master KDC to contact it using TCP on port 754 (krb5_prop), and start the
kprop
service. - Verify that the
kadmin
service is disabled. - Perform a manual database propagation test by dumping the realm database on the master KDC to the default data file which the
kprop
command will read (/var/kerberos/krb5kdc/slave_datatrans
).[root@masterkdc ~]# kdb5_util dump /var/kerberos/krb5kdc/slave_datatrans
- Use the
kprop
command to transmit its contents to the secondary KDC.[root@masterkdc ~]# kprop slavekdc.example.com
- Using
kinit
, verify that the client system is able to correctly obtain the initial credentials from the KDC.The/etc/krb5.conf
for the client should list only the secondary KDC in its list of KDCs.[realms] EXAMPLE.COM = {
kdc = slavekdc.example.com.:88
admin_server = kdc.example.com default_domain = example.com } - Create a script which dumps the realm database and runs the
kprop
command to transmit the database to each secondary KDC in turn, and configure thecron
service to run the script periodically.
11.2.3. Kerberos Key Distribution Center Proxy
HTTPS
service as a proxy that communicates with Kerberos via the HTTPS
port 443.
KKDCP Server
ipaConfigString=kdcProxyEnabled
exists in the directory. In this situation, the symbolic link /etc/httpd/conf.d/ipa-kdc-proxy.conf
is created. Thus, you can verify that KKDCP is enabled on an IdM Server by checking that the symbolic link exists.
$ ls -l /etc/httpd/conf.d/ipa-kdc-proxy.conf lrwxrwxrwx. 1 root root 36 Aug 15 09:37 /etc/httpd/conf.d/ipa-kdc-proxy.conf -> /etc/ipa/kdcproxy/ipa-kdc-proxy.conf
Example 11.1. Configuring the KKDCP server I
- In the
/etc/ipa/kdcproxy/kdcproxy.conf
file, set theuse_dns
parameter in the [global] section to false :[global] use_dns = false
- Put the proxied realm information into the
/etc/ipa/kdcproxy/kdcproxy.conf
file. For the [AD.EXAMPLE.COM] realm with proxy, for example, list the realm configuration parameters as follows:[AD.EXAMPLE.COM] kerberos = kerberos+tcp://1.2.3.4:88 kerberos+tcp://5.6.7.8:88 kpasswd = kpasswd+tcp://1.2.3.4:464 kpasswd+tcp://5.6.7.8:464
Important
The realm configuration parameters must list multiple servers separated by a space, as opposed to/etc/krb5.conf
andkdc.conf
, in which certain options may be specified multiple times. - Restart IdM services:
# ipactl restart
Example 11.2. Configuring the KKDCP server II
- In the
/etc/ipa/kdcproxy/kdcproxy.conf
file, the [global] section, set theuse_dns
parameter to true:[global] configs = mit use_dns = true
Theconfigs
parameter allows you to load other configuration modules. In this case, the configuration is read from the MITlibkrb5
library. - Optional: In case you do not want to use DNS service records, add explicit AD servers to the [realms] section of the
/etc/krb5.conf
file. If the realm with proxy is, for example, AD.EXAMPLE.COM, you add:[realms] AD.EXAMPLE.COM = { kdc = ad-server.ad.example.com kpasswd_server = ad-server.ad.example.com }
- Restart IdM services:
# ipactl restart
KKDCP Client
/etc/krb5.conf
files. Follow this procedure to reach the AD server.
- On the client, open the
/etc/krb5.conf
file, and add the name of the AD realm to the [realms] section:[realms] AD.EXAMPLE.COM { kdc = https://ipa-server.example.com/KdcProxy kdc = https://ipa-server2.example.com/KdcProxy kpasswd_server = https://ipa-server.example.com/KdcProxy kpasswd_server = https://ipa-server2.example.com/KdcProxy }
- Open the
/etc/sssd/sssd.conf
file, and add the krb5_use_kdcinfo = False line to your IdM domain section:[domain/example.com] krb5_use_kdcinfo = False
- Restart the
SSSD
service:# systemctl restart sssd.service
Additional Resources
- For details on configuring KKDCP for an Active Directory realm, see Configure IPA server as a KDC Proxy for AD Kerberos communication in Red Hat Knowledgebase.
11.3. Configuring a Kerberos Client
krb5.conf
configuration file. While ssh
and slogin
are the preferred methods of remotely logging in to client systems, Kerberos-aware versions of rsh
and rlogin
are still available, with additional configuration changes.
- Install the
krb5-libs
andkrb5-workstation
packages on all of the client machines.[root@server ~]# yum install krb5-workstation krb5-libs
- Supply a valid
/etc/krb5.conf
file for each client. Usually this can be the samekrb5.conf
file used by the Kerberos Distribution Center (KDC). For example:[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h renew_lifetime = 7d forwardable = true allow_weak_crypto = true [realms] EXAMPLE.COM = { kdc = kdc.example.com.:88 admin_server = kdc.example.com default_domain = example.com } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM
In some environments, the KDC is only accessible using an HTTPS Kerberos Key Distribution Center Proxy (KKDCP). In this case, make the following changes:- Assign the URL of the KKDCP instead of the host name to the
kdc
andadmin_server
options in the[realms]
section:[realms] EXAMPLE.COM = { kdc = https://kdc.example.com/KdcProxy admin_server = https://kdc.example.com/KdcProxy kpasswd_server = https://kdc.example.com/KdcProxy default_domain = example.com }
For redundancy, the parameterskdc
,admin_server
, andkpasswd_server
can be added multiple times using different KKDCP servers. - On IdM clients, restart the
sssd
service to make the changes take effect:[root@server ~]# systemctl restart sssd
- To use Kerberos-aware
rsh
andrlogin
services, install thersh
package. - Before a workstation can use Kerberos to authenticate users who connect using
ssh
,rsh
, orrlogin
, it must have its own host principal in the Kerberos database. Thesshd
,kshd
, andklogind
server programs all need access to the keys for the host service's principal.- Using
kadmin
, add a host principal for the workstation on the KDC. The instance in this case is the host name of the workstation. Use the-randkey
option for thekadmin
'saddprinc
command to create the principal and assign it a random key:addprinc -randkey host/server.example.com
- The keys can be extracted for the workstation by running
kadmin
on the workstation itself and using thektadd
command.ktadd -k /etc/krb5.keytab host/server.example.com
- To use other Kerberos-aware network services, install the krb5-server package and start the services. The Kerberos-aware services are listed in Table 11.3, “Common Kerberos-aware Services”.
Service Name | Usage Information |
---|---|
ssh | OpenSSH uses GSS-API to authenticate users to servers if the client's and server's configuration both have GSSAPIAuthentication enabled. If the client also has GSSAPIDelegateCredentials enabled, the user's credentials are made available on the remote system. OpenSSH also contains the sftp tool, which provides an FTP-like interface to SFTP servers and can use GSS-API. |
IMAP |
The
cyrus-imap package uses Kerberos 5 if it also has the cyrus-sasl-gssapi package installed. The cyrus-sasl-gssapi package contains the Cyrus SASL plugins which support GSS-API authentication. Cyrus IMAP functions properly with Kerberos as long as the cyrus user is able to find the proper key in /etc/krb5.keytab , and the root for the principal is set to imap (created with kadmin ).
An alternative to
cyrus-imap can be found in the dovecot package, which is also included in Red Hat Enterprise Linux. This package contains an IMAP server but does not, to date, support GSS-API and Kerberos.
|
11.4. Setting up a Kerberos Client for Smart Cards
- Install the required PKI/OpenSSL package, along with the other client packages:
[root@server ~]# yum install krb5-pkinit [root@server ~]# yum install krb5-workstation krb5-libs
- Edit the
/etc/krb5.conf
configuration file to add a parameter for the public key infrastructure (PKI) to the[realms]
section of the configuration. Thepkinit_anchors
parameter sets the location of the CA certificate bundle file.[realms] EXAMPLE.COM = { kdc = kdc.example.com.:88 admin_server = kdc.example.com default_domain = example.com ... pkinit_anchors = FILE:/usr/local/example.com.crt }
- Add the PKI module information to the PAM configuration for both smart card authentication (
/etc/pam.d/smartcard-auth
) and system authentication (/etc/pam.d/system-auth
). The line to be added to both files is as follows:auth optional pam_krb5.so use_first_pass no_subsequent_prompt preauth_options=X509_user_identity=PKCS11:/usr/lib64/pkcs11/opensc-pkcs11.so
If the OpenSC module does not work as expected, use the module from the coolkey package:/usr/lib64/pkcs11/libcoolkeypk11.so
. In this case, consider contacting Red Hat Technical Support or filing a Bugzilla report about the problem.
11.5. Setting up Cross-Realm Kerberos Trusts
11.5.1. A Trust Relationship
Figure 11.2. Basic Trust
krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM
). When that principal is also added to Domain A, then the clients in Domain A can access the resources in Domain B. The configured principal exists in both realms. That shared principal has three characteristics:
- It exists in both realms.
- When a key is created, the same password is used in both realms.
- The key has the same key version number (
kvno
).
B.EXAMPLE.COM
realm are trusted to authenticate to services in the A.EXAMPLE.COM
realm. To establish trust in the other direction, both realms would need to share keys for the krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM
service — an entry with a reverse mapping from the previous example.
Figure 11.3. Transitive Trust
[domain_realm]
section of the /etc/krb5.conf
file. With implicit mapping, the domain name is converted to upper case; the converted name is then assumed to be the Kerberos realm to search.
Figure 11.4. Trusts in the Same Domain
Figure 11.5. Child/Parent Trusts in the Same Domain
Figure 11.6. Trusts in Different Domains
The [capaths]
section
[capaths]
section of the /etc/krb5.conf
file defines the trust flow between different realms.
[capaths]
section is relatively straightforward: there is a main entry for each realm where a client has a principal, and then inside each realm section is a list of intermediate realms from which the client must obtain credentials.
[capaths]
can be used to specify the following process for obtaining credentials:
- With credentials from Realm A, the client obtains a
krbtgt/A@A
ticket from the KDC of Realm A. Using this ticket, the client then asks for thekrbtgt/B@A
ticket.Thekrbtgt/B@A
ticket issued by the KDC of Realm A is a cross-realm ticket granting ticket. It allows the client to ask the KDC of Realm B for a ticket to a service principal of Realm B. - With the
krbtgt/B@A
ticket, the client asks for thekrbtgt/C@B
cross-realm ticket. - With the
krbtgt/C@B
ticket issued by the KDC of Realm B, the client asks for thekrbtgt/D@C
cross-realm ticket. - With the
krbtgt/D@C
ticket issued by the KDC of Realm C, the client asks the KDC of Realm D for a ticket to a service principal in Realm D.
krbtgt/A@A
, krbtgt/B@A
, krbtgt/C@B
, krbtgt/D@C
, and service/hostname@D
. To obtain the service/hostname@D
ticket, it was required to obtain the three intermediate cross-realm tickets.
[capaths]
section, including examples of the [capaths]
configuration, see the krb5.conf(5) man page.
11.5.2. Setting up a Realm Trust
A.EXAMPLE.COM
and B.EXAMPLE.COM
.
kadmin
.
[root@server ~]# kadmin -r A.EXAMPLE.COM kadmin: add_principal krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM Enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM": Re-enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM": Principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" created. quit
Important
kadmin
.
[root@server ~]# kadmin -r B.EXAMPLE.COM kadmin: add_principal krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM Enter password for principal "krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM": Re-enter password for principal "krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM": Principal "krbtgt/A.EXAMPLE.COM@B.EXAMPLE.COM" created. quit
get_principal
command to verify that both entries have matching key version numbers (kvno
values) and encryption types.
Important
add_principal
command's -randkey
option to assign a random key instead of a password, dump the new entry from the database of the first realm, and import it into the second. This will not work unless the master keys for the realm databases are identical, as the keys contained in a database dump are themselves encrypted using the master key.
Chapter 12. Working with certmonger
certmonger
service manages certificate life cycle for applications and, if properly configured, can work together with a certificate authority (CA) to renew certificates.
certmonger
daemon and its command-line clients simplify the process of generating public/private key pairs, creating certificate requests, and submitting requests to the CA for signing. The certmonger
daemon monitors certificates for expiration and can renew certificates that are about to expire. The certificates that certmonger
monitors are tracked in files stored in a configurable directory. The default location is /var/lib/certmonger/requests
.
Note
certmonger
daemon cannot revoke certificates. A certificate can only be revoked by a relevant Certificate Authority, which needs to invalidate the certificate and update its Certificate Revocation List.
12.1. certmonger and Certificate Authorities
certmonger
can automatically obtain three kinds of certificates that differ in what authority source the certificate employs:
- Self-signed certificateGenerating a self-signed certificate does not involve any CA, because each certificate is signed using the certificate's own key. The software that is verifying a self-signed certificate needs to be instructed to trust that certificates directly in order to verify it.To obtain a self-signed certificate, run the
selfsign-getcert
command. - Certificate from the Dogtag Certificate System CA as part of Red Hat Enterprise Linux IdMTo obtain a certificate using an IdM server, run the
ipa-getcert
command - Certificate signed by a local CA present on the systemThe software that is verifying a certificate signed by a local signer needs to be instructed to trust certificates from this local signer in order to verify them.To obtain a locally-signed certificate, run the
local-getcert
command.
certmonger
to manage certificates, but support must be added to certmonger
by creating special CA helpers. For more information on how to create CA helpers, see the certmonger
project documentation at https://pagure.io/certmonger/blob/master/f/doc/submit.txt.
12.2. Requesting a Self-signed Certificate with certmonger
certmonger
, use the getcert request
utility.
.pem
extension or in an NSS database, identified by the certificate nickname. When requesting a certificate, then, the request should identify the location where the certificate will be stored and the nickname of the certificate. For example:
[root@server ~]# selfsign-getcert request -d /etc/pki/nssdb -n Server-Cert
/etc/pki/nssdb
file is the global NSS database, and Server-Cert
is the nickname of this certificate. The certificate nickname must be unique within this database.
-r
automatically renews the certificate when its expiration date is close if the key pair already exists. This option is used by default.-f
stores the certificate in the given file.-k
either stores the key in the given file or, if the key file already exists, uses the key in the file.-K
gives the Kerberos principal name of the service that will be using the certificate;-K
is required when requesting a certificate from an IdM server and optional when requesting a self-signed or locally-signed certificate-N
gives the subject name.-D
requests a DNS domain name to be included in the certificate as asubjectAltName
value.-U
sets the extended key usage flag.-A
requests an IP address to be included in the certificate as asubjectAltName
value.-I
sets a name for the task.certmonger
uses this name to refer to the combination of storage locations and request options, and it is also displayed in the output of thegetcert list
command. If you do not specify this option,certmonger
assigns an automatically-generated name for the task.
-K
, -N
, -D
, -U
, and -A
options according to the CA's own policies. For example, IdM requires that -K
and -N
agree with the local host name. Certificates generated using the selfsign-getcert
and local-getcert
commands, on the other hand, agree with the options that you specify because these commands do not enforce any policy.
Example 12.1. Using certmonger for a Service
[root@server ~]# selfsign-getcert request -f /etc/httpd/conf/ssl.crt/server.crt -k /etc/httpd/conf/ssl.key/server.key -N CN=`hostname --fqdn` -D `hostname` -U id-kp-serverAuth
12.3. Requesting a CA-signed Certificate Through SCEP
certmonger
, requests a new certificate, and adds it to the local NSS database.
- Add the CA configuration to
certmonger
:[root@server ~]# getcert add-scep-ca -c CA_Name -u SCEP_URL
-c
: Mandatory nickname for the CA configuration. The same value can later be passed to othergetcert
commands.-u
: URL to the server's SCEP interface.- Mandatory parameter when using an HTTPS URL:
-R CA_Filename
: Location of the PEM-formatted copy of the SCEP server's CA certificate, used for the HTTPS encryption.
- Verify that the CA configuration has been successfully added:
[root@server ~]# getcert list-cas -c CA_Name CA 'CA_Name': is-default: no ca-type: EXTERNAL helper-location: /usr/libexec/certmonger/scep-submit -u http://SCEP_server_enrollment_interface_URL SCEP CA certificate thumbprint (MD5): A67C2D4B 771AC186 FCCA654A 5E55AAF7 SCEP CA certificate thumbprint (SHA1): FBFF096C 6455E8E9 BD55F4A5 5787C43F 1F512279
The CA configuration was successfully added, when the CA certificate thumbprints were retrieved over SCEP and shown in the command's output. When accessing the server over unencrypted HTTP, manually compare the thumbprints with the ones displayed at the SCEP server to prevent a Man-in-the-middle attack. - Request a certificate from the CA:
[root@server ~]# getcert request -I Task_Name -c CA_Name -d /etc/pki/nssdb -n Certificate_Name -N cn="Subject Name" -L one-time_PIN
-I
: Name of the task. The same value can later be passed to thegetcert list
command.-c
: CA configuration to submit the request to.-d
: Directory with the NSS database to store the certificate and key.-n
: Nickname of the certificate, used in the NSS database.-N
: Subject name in the CSR.-L
: Time-limited one-time PIN issued by the CA.
- Right after submitting the request, you can verify that a certificate was issued and correctly stored in the local database:
[root@server ~]# getcert list -I TaskName Request ID 'Task_Name': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/nssdb',nickname='TestCert',token='NSS Certificate DB' certificate: type=NSSDB,location='/etc/pki/nssdb',nickname='TestCert',token='NSS Certificate DB' signing request thumbprint (MD5): 503A8EDD DE2BE17E 5BAA3A57 D68C9C1B signing request thumbprint (SHA1): B411ECE4 D45B883A 75A6F14D 7E3037F1 D53625F4 CA: AD-Name issuer: CN=windows-CA,DC=ad,DC=example,DC=com subject: CN=Test Certificate expires: 2018-05-06 10:28:06 UTC key usage: digitalSignature,keyEncipherment eku: iso.org.dod.internet.security.mechanisms.8.2.2 certificate template/profile: IPSECIntermediateOffline pre-save command: post-save command: track: yes auto-renew: yes
The status MONITORING signifies a successful retrieval of the issued certificate. Thegetcert-list(1)
man page lists other possible states and their meanings.
12.4. Storing Certificates in NSS Databases
certmonger
uses .pem
files to store the key and the certificate. To store the key and the certificate in an NSS database, specify the -d
and -n
with the command you use for requesting the certificate.
-d
sets the security database location-n
gives the certificate nickname which is used for the certificate in the NSS database
Note
-d
and -n
options are used instead of the -f
and -k
options that give the .pem
file.
[root@server ~]# selfsign-getcert request -d /export/alias -n ServerCert ...
ipa-getcert
and local-getcert
allows you to specify another two options:
-F
gives the file where the certificate of the CA is to be stored.-a
gives the location of the NSS database where the certificate of the CA is to be stored.
Note
selfsign-getcert
, there is no need to specify the -F
and -a
options because generating a self-signed certificate does not involve any CA.
-F
option, the -a
option, or both with local-getcert
allows you to obtain a copy of the CA certificate that is required in order to verify a certificate issued by the local signer. For example:
[root@server ~]# local-getcert request -F /etc/httpd/conf/ssl.crt/ca.crt -n ServerCert -f /etc/httpd/conf/ssl.crt/server.crt -k /etc/httpd/conf/ssl.key/server.key
12.5. Tracking Certificates with certmonger
certmonger
can monitor expiration date of a certificate and automatically renew the certificate at the end of its validity period. To track a certificate in this way, run the getcert start-tracking
command.
Note
getcert start-tracking
after running getcert request
, because the getcert request
command by default automatically tracks and renews the requested certificate. The getcert start-tracking
command is intended for situations when you have already obtained the key and certificate through some other process, and therefore you have to manually instruct certmonger
to start the tracking.
getcert start-tracking
command takes several options:
-r
automatically renews the certificate when its expiration date is close if the key pair already exists. This option is used by default.-I
sets a name for the tracking request.certmonger
uses this name to refer to the combination of storage locations and request options, and it is also displayed in the output of thegetcert list
command. If you do not specify this option,certmonger
assigns an automatically generated a name for the task.
[root@server ~]# getcert start-tracking -I cert1-tracker -d /export/alias -n ServerCert
stop-tracking
command.
Chapter 13. Configuring Applications for Single Sign-On
13.1. Configuring Firefox to Use Kerberos for Single Sign-On
kinit
command and supply the user password for the user on the KDC.
[jsmith@host ~] $ kinit Password for jsmith@EXAMPLE.COM:
- In the address bar of Firefox, type
about:config
to display the list of current configuration options. - In the Filter field, type
negotiate
to restrict the list of options. - Double-click the network.negotiate-auth.trusted-uris entry.
- Enter the name of the domain against which to authenticate, including the preceding period (.). If you want to add multiple domains, enter them in a comma-separated list.
Figure 13.1. Manual Firefox Configuration
Important
Note
13.2. Certificate Management in Firefox
- In Mozilla Firefox, open the Firefox menu and click.
Figure 13.2. Firefox Preferences
- Open the Advanced section and choose the Certificates tab.
Figure 13.3. Certificates Tab in Firefox
- Click Certificate Manager.to open the
- Download and save the CA certificate to your computer.
- In the Certificate Manager, choose the Authorities tab and click .
Figure 13.4. Importing the CA Certificate in Firefox
- Select the downloaded CA certificate.
- In the Certificate Manager, under the Authorities tab, select the appropriate certificate and click .
- Edit the certificate trust settings.
Figure 13.5. Editing the Certificate Trust Settings in Firefox
- In the Certificate Manager, under the Your Certificates tab, click .
Figure 13.6. Importing a Personal Certificate for Authentication in Firefox
- Select the required certificate from your computer.
13.3. Certificate Management in Email Clients
- In Mozilla Thunderbird, open the Thunderbird main menu and select Preferences → Account Settings.
- Select the Security item, and click to open the Certificate Manager.
Figure 13.7. Account Settings in Thunderbird
- Download and save the CA certificate to your computer.
- In the Certificate Manager, choose the Authorities tab and click .
Figure 13.8. Importing the CA Certificate in Thunderbird
- Select the downloaded CA certificate.
- In the Certificate Manager, under the Authorities tab, select the appropriate certificate and click .
- Edit the certificate trust settings.
Figure 13.9. Editing the Certificate Trust Settings in Thunderbird
- In the Certificate Manager, under the Your Certificates tab, click .
Figure 13.10. Importing a Personal Certificate for Authentication in Thunderbird
- Select the required certificate from your computer.
- Close the Certificate Manager and return to the Security item in Account Settings.
- Under the Digital Signing section of the form, click to choose your personal certificate to use for signing messages.
- Under Encryption, click to choose your personal certificate to encrypt and decrypt messages.
Appendix A. Troubleshooting
A.1. Troubleshooting SSSD
A.1.1. Setting Debug Logs for SSSD Domains
debug_level
parameter for each section in the sssd.conf
file for which to produce extra logs. For example:
[domain/LDAP]
cache_credentials = true
debug_level = 9
Level | Description |
---|---|
0 | Fatal failures. Anything that would prevent SSSD from starting up or causes it to cease running. |
1 | Critical failures. An error that does not kill the SSSD, but one that indicates that at least one major feature is not going to work properly. |
2 | Serious failures. An error announcing that a particular request or operation has failed. |
3 | Minor failures. These are the errors that would percolate down to cause the operation failure of 2. |
4 | Configuration settings. |
5 | Function data. |
6 | Trace messages for operation functions. |
7 | Trace messages for internal control functions. |
8 | Contents of function-internal variables that may be interesting. |
9 | Extremely low-level tracing information. |
sss_debuglevel
utility, which is part of the sssd-tools
package. For more information about how it works, see the sss_debuglevel man page.
A.1.2. Checking SSSD Log Files
/var/log/sssd/
directory. SSSD produces a log file for each domain, as well as an sssd_pam.log
and an sssd_nss.log
file.
krb5_child.log
: log file for the short-lived helper process involved in Kerberos authenticationldap_child.log
: log file for the short-lived helper process involved in communicating with the LDAP serverselinux_child.log
: log file for the short-lived helper process that retrieves SELinux informationsssd.log
: log file for SSSD communicating with its responder processessssd_[domain].log
: each SSSD domain section logs information about communication with the LDAP server to a separate log filesssd_ifp.log
: log file for the InfoPipe responder, provides a public D-Bus interface accessible over the system bussssd_nss.log
: log file for the Name Services Switch (NSS) responder that retrieves user and group informationsssd_pac.log
: log file for the Microsoft Privilege Attribute Certificate (PAC) responder service that defines how SSSD works with Kerberos to manage Active Directory users and groupssssd_pam.log
: log file for the Pluggable Authentication Module (PAM) respondersssd_ssh.log
: log file for the SSH responder process
/var/log/secure
file logs authentication failures and the reason for the failure.
A.1.3. Problems with SSSD Configuration
- Q: SSSD fails to start
- Q: I do not see any groups with id or group members with getent group.
- Q: Authentication fails against LDAP.
- Q: Connecting to LDAP servers on non-standard ports fail.
- Q: NSS fails to return user information
- Q: NSS returns incorrect user information
- Q: Setting the password for the local SSSD user prompts twice for the password
- Q: An Active Directory identity provider is properly configured in my sssd.conf file, but SSSD fails to connect to it, with GSS-API errors.
- Q: I configured SSSD for central authentication, but now several of my applications (such as Firefox or Adobe) will not start.
- Q: SSSD is showing an automount location that I removed.
- SSSD requires at least one properly configured domain before the service will start. Without a domain, attempting to start SSSD returns an error that no domains are configured:
# sssd -d4 -i [sssd] [ldb] (3): server_sort:Unable to register control with rootdse! [sssd] [confdb_get_domains] (0): No domains configured, fatal error! [sssd] [get_monitor_config] (0): No domains configured.
Edit the/etc/sssd/sssd.conf
file and create at least one domain. - SSSD also requires at least one available service provider before it will start. If the problem is with the service provider configuration, the error message indicates that there are no services configured:
[sssd] [get_monitor_config] (0): No services configured!
Edit the/etc/sssd/sssd.conf
file and configure at least one service provider.Important
SSSD requires that service providers be configured as a comma-separated list in a singleservices
entry in the/etc/sssd/sssd.conf
file. If services are listed in multiple entries, only the last entry is recognized by SSSD. - SSSD also requires the ownership and permissions of the
/etc/sssd/sssd.conf
to be set correctly. If the ownership or permissions are set incorrectly, attempt to start SSSD returns these error messages:[sssd] [confdb_ldif_from_ini_file] (0x0020): Permission check on config file failed. [sssd] [confdb_init_db] (0x0020): Cannot convert INI to LDIF [1]: [Operation not permitted] [sssd] [confdb_setup] (0x0010): ConfDB initialization has failed [1]: Operation not permitted [sssd] [load_configuration] (0x0010): Unable to setup ConfDB [1]: Operation not permitted [sssd] [main] (0x0020): Cannot read config file /etc/sssd/sssd.conf. Please check that the file is accessible only by the owner and owned by root.root.
Set the correct ownership and permissions of the/etc/sssd/sssd.conf
file:# chmod 600 /etc/sssd/sssd.conf # chown root:root /etc/sssd/sssd.conf
id
or group members with getent group
.
ldap_schema
setting in the [domain/DOMAINNAME]
section of sssd.conf
.
memberuid
attribute, which contains the name of the users that are members. In an RFC2307bis server, group members are stored as the multi-valued member
or uniqueMember
attribute which contains the DN of the user or group that is a member of this group. RFC2307bis allows nested groups to be maintained as well.
- Set
ldap_schema
torfc2307bis
. - Delete
/var/lib/sss/db/cache_DOMAINNAME.ldb
. - Restarting SSSD.
sssd.conf
:
ldap_group_name = uniqueMember
sssd.conf
is configured to connect over a standard protocol (ldap://
), it attempts to encrypt the communication channel with Start TLS. If sssd.conf
is configured to connect over a secure protocol (ldaps://
), then SSSD uses SSL.
syslog
message is written, indicating that TLS encryption could not be started. The certificate configuration can be tested by checking if the LDAP server is accessible apart from SSSD. For example, this tests an anonymous bind over a TLS connection to test.example.com
:
$ ldapsearch -x -ZZ -h test.example.com -b dc=example,dc=com
ldap_start_tls: Connect error (-11) additional info: TLS error -8179:Unknown code ___f 13
- Obtain a copy of the public CA certificate for the certificate authority used to sign the LDAP server certificate and save it to the local system.
- Add a line to the
sssd.conf
file that points to the CA certificate on the filesystem.ldap_tls_cacert = /path/to/cacert
- If the LDAP server uses a self-signed certificate, remove the
ldap_tls_reqcert
line from thesssd.conf
file.This parameter directs SSSD to trust any certificate issued by the CA certificate, which is a security risk with a self-signed CA certificate.
# semanage port -a -t ldap_port_t -p tcp 1389
- Ensure that the NSS service is running:
# service sssd status Redirecting to /bin/systemctl status sssd.service sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled) Active: active (running) since Wed 2015-01-14 10:17:26 CET; 1min 30s ago Process: 683 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=0/SUCCESS) Main PID: 745 (sssd) CGroup: /system.slice/sssd.service ├─745 /usr/sbin/sssd -D -f ├─746 /usr/libexec/sssd/sssd_be --domain default --debug-to-files... ├─804 /usr/libexec/sssd/sssd_nss --debug-to-files └─805 /usr/libexec/sssd/sssd_pam --debug-to-files
NSS service is running when SSSD is in theActive: active (running)
state and when the output includessssd_nss
. - If NSS is running, make sure that the provider is properly configured in the
[nss]
section of the/etc/sssd/sssd.conf
file. Especially check thefilter_users
andfilter_groups
attributes. - Make sure that NSS is included in the list of services that SSSD uses.
- Check the configuration in the
/etc/nsswitch.conf
file. For more information, see the section called “Configure NSS Services to Use SSSD”.
use_fully_qualified_domains
attribute to true
in the /etc/sssd/sssd.conf
file. This differentiates between different users in different domains with the same name.
[root@clientF11 tmp]# passwd user1000 Changing password for user user1000. New password: Retype new password: New Password: Reenter new Password: passwd: all authentication tokens updated successfully.
use_authtok
option is correctly configured in your /etc/pam.d/system-auth
file. For examples of the correct configuration, see Section 7.5.2, “Configuring Services: PAM”.
sssd.conf
file, but SSSD fails to connect to it, with GSS-API errors.
[domain/ADEXAMPLE]
debug_level = 0xFFF0
id_provider = ad
ad_server = 172.16.0.1
ad_domain = example.com
krb5_canonicalize = False
(Fri Jul 27 18:27:44 2012) [sssd[be[ADTEST]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error] (Fri Jul 27 18:27:44 2012) [sssd[be[ADTEST]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Cannot determine realm for numeric host address)]
ad_server
to the name of the Active Directory host, or use the _srv_
keyword to use the DNS service discovery, as described in Section 7.4.3, “Configuring DNS Service Discovery”.
Failed to contact configuration server. See http://www.gnome.org/projects/gconf/ for information. (Details - 1: IOR file '/tmp/gconfd-somebody/lock/ior' not opened successfully, no gconfd located: Permission denied 2: IOR file '/tmp/gconfd-somebody/lock/ior' not opened successfully, no gconfd located: Permission denied)
[jsmith@server ~]$ acroread (acroread:12739): GLib-WARNING **: getpwuid_r(): failed due to unknown user id (366)
- Remove the autofs cache, as described in Section A.1.4, “A User Cannot Log In After UID or GID Changed”.
- Restart SSSD:
# systemctl restart sssd
A.1.4. A User Cannot Log In After UID or GID Changed
What this means:
To fix the problem:
sss_cache
utility:
- Make sure the sssd-tools is installed.
- To clear the SSSD cache for a specific user and leave the rest of the cache records intact:
# sss_cache --user user_name
To clear the cache for an entire domain:# sss_cache --domain domain_name
sss_cache
, see the sss_cache(8) man page.
A.1.5. SSSD Control and Status Utility
sssctl
utility to obtain status information, manage data files during troubleshooting, and other SSSD-related tasks.
- To use
sssctl
, install the sssd-tools package:[root@server ~]# yum install sssd-tools
- Some options of
sssctl
use the SSSD InfoPipe responder. To enable it, addifp
to theservices
option of your/etc/sssd/sssd.conf
:[sssd] services = nss, sudo, pam, ssh, ifp
- Restart SSSD:
[root@server ~]# systemctl restart sssd.service
A.1.5.1. SSSD Configuration Validation
sssctl config-check
command performs a static analysis of the SSSD configuration files. This enables you to validate the /etc/sssd/sssd.conf
file and /etc/sssd/conf.d/*
files to receive a report before restarting SSSD.
- Permissions
- The owner and group owner must be set to
root:root
and the permissions to600
. - File names
- File names in
/etc/sssd/conf.d/
must use the suffix.conf
and not start with a period (hidden files). - Typographical errors
- Typographical errors are checked in section and option names. Note that values are not checked.
- Options
- Options must be placed in the correct sections.
# sssctl config-check Issues identified by validators: 3 [rule/allowed_sections]: Section [paM] is not allowed. Check for typos. [rule/allowed_domain_options]: Attribute 'offline_timeoutX' is not allowed in section 'domain/idm.example.com'. Check for typos. [rule/allowed_sudo_options]: Attribute 'homedir_substring' is not allowed in section 'sudo'. Check for typos. Messages generated during configuration merging: 2 File /etc/sssd/conf.d/wrong-file-permissions.conf did not pass access check. Skipping. File configuration.conf.disabled did not match provided patterns. Skipping. Used configuration snippet files: 1 /etc/sssd/conf.d/sample.conf
A.1.5.2. Displaying User Data
sssctl user-checks
command helps to debug problems in applications that use SSSD as a back end for user lookup, authentication, and authorization. The command displays user data available through NSS and the InfoPipe responder for the D-Bus interface. The displayed data shows whether the user is authorized to log in using the system-auth
PAM services.
admin
user:
# sssctl user-checks admin user: admin action: acct service: system-auth SSSD nss user lookup result: - user name: admin - user id: 1194200000 - group id: 1194200000 - gecos: Administrator - home directory: /home/admin - shell: /bin/bash SSSD InfoPipe user lookup result: - name: admin - uidNumber: 1194200000 - gidNumber: 1194200000 - gecos: Administrator - homeDirectory: /home/admin - loginShell: /bin/bash testing pam_acct_mgmt pam_acct_mgmt: Success PAM Environment: - no env -
sssctl user-checks --help
command.
A.1.5.3. Domain Information
- List all domains available within SSSD, including trusted domains:
[root@server ~]# sssctl domain-list idm.example.com ad.example.com
- Retrieve the status of the domain idm.example.com:
[root@server ~]# sssctl domain-status idm.example.com Online status: Online
A.1.5.4. Cached Entries Information
sssctl
command enables you to retrieve information about a cached entry, to investigate and debug cache-related authentication problems.
admin
, run:
[root@server ~]# sssctl user-show admin Name: admin Cache entry creation date: 07/10/16 16:09:18 Cache entry last update time: 07/14/16 10:13:32 Cache entry expiration time: 07/14/16 11:43:32 Initgroups expiration time: Expired Cached in InfoPipe: No
[root@server ~]# sssctl group-show groupname [root@server ~]# sssctl netgroup-show netgroupname
A.1.5.5. Truncating the Log Files
sssctl logs-remove
to truncate all SSSD log files in the /var/log/sssd/
directory to capture only newly created entries.
[root@server ~]# sssctl logs-remove Truncating log files...
A.1.5.6. Removing the SSSD Cache
sssctl
command provides the remove-cache
option. Before the databases are removed, the command creates automatically a backup.
[root@server ~]# sssctl cache-remove SSSD must not be running. Stop SSSD now? (yes/no) [yes] Creating backup of local data... Removing cache files... SSSD needs to be running. Start SSSD now? (yes/no) [yes]
Note
/var/lib/sss/backup/
directory.
sssctl restore-local-data
.
A.1.5.7. Obtaining Information about an LDAP Group Takes Long
What this means:
To fix the problem:
- Open the
/etc/sssd/sssd.conf
file. - In the
[domain]
section, set theignore_group_members
option totrue
.[domain/domain_name] [... file truncated ...]
ignore_group_members = true
Note
true
when the deployment involves an IdM server with the compat tree.
A.2. Troubleshooting sudo with SSSD and sudo Debugging Logs
A.2.1. SSSD and sudo Debug Logging
The sudo
Debug Log File
- Add the following lines to
/etc/sudo.conf
:Debug sudo /var/log/sudo_debug.log all@debug Debug sudoers.so /var/log/sudo_debug.log all@debug
- Run the
sudo
command as the user you want to debug.
/var/log/sudo_debug.log
file is created automatically and provides detailed information to answer questions like:
- What information is available about the user and the environment when running the
sudo
command?sudo[22259] settings: debug_flags=all@debug sudo[22259] settings: run_shell=true sudo[22259] settings: progname=sudo sudo[22259] settings: network_addrs=192.0.2.1/255.255.255.0 fe80::250:56ff:feb9:7d6/ffff:ffff:ffff:ffff:: sudo[22259] user_info: user=user_name sudo[22259] user_info: pid=22259 sudo[22259] user_info: ppid=22172 sudo[22259] user_info: pgid=22259 sudo[22259] user_info: tcpgid=22259 sudo[22259] user_info: sid=22172 sudo[22259] user_info: uid=10000 sudo[22259] user_info: euid=0 sudo[22259] user_info: gid=554801393 sudo[22259] user_info: egid=554801393 sudo[22259] user_info: groups=498,6004,6005,7001,106501,554800513,554801107,554801108,554801393,554801503,554802131,554802244,554807670 sudo[22259] user_info: cwd=/ sudo[22259] user_info: tty=/dev/pts/1 sudo[22259] user_info: host=client sudo[22259] user_info: lines=31 sudo[22259] user_info: cols=237
- What data sources are used to fetch sudo rules?
sudo[22259] <- sudo_parseln @ ./fileops.c:178 := sudoers: files sss
- SSSD plug-in starts with this line:
sudo[22259] <- sudo_sss_open @ ./sssd.c:305 := 0
- How many rules did SSSD return?
sudo[22259] Received 3 rule(s)
- Does a rule match or not?
sudo[22259] sssd/ldap sudoHost 'ALL' ... MATCH! sudo[22259] <- user_in_group @ ./pwutil.c:1010 := false
The SSSD Debug Log Files
- Add the
debug_level
option to the[sudo]
and[domain/domain_name]
sections of your/etc/sssd/sssd.conf
file:[domain/domain_name] debug_level = 0x3ff0 ... [sudo] debug_level = 0x3ff0
- Restart SSSD:
# systemctl restart sssd
- Run the
sudo
command to write the debug information to the log files.
- The domain log file:
/var/log/sssd/sssd_domain_name.log
- This log file helps you to answer questions like:
- How many rules did SSSD return?
[sdap_sudo_refresh_load_done] (0x0400): Received 4-rules rules
- What sudo rules did SSSD download from the server?
[sssd[be[LDAP.PB]]] [sysdb_save_sudorule] (0x0400): Adding sudo rule demo-name
- Are the matching rules stored in the cache?
[sdap_sudo_refresh_load_done] (0x0400): Sudoers is successfully stored in cache
- What filter was used to download the rules from the server?
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=client.example.com)(sudoHost=client)(sudoHost=192.0.2.1)(sudoHost=192.0.2.0/24)(sudoHost=2620:52:0:224e:21a:4aff:fe23:1394)(sudoHost=2620:52:0:224e::/64)(sudoHost=fe80::21a:4aff:fe23:1394)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\2A*)(sudoHost=*[*]*))))][dc=example,dc=com]
Use this filter to look up the rules in the IdM database:# ldapsearch -x -D "cn=Directory Manager" -W -H ldap://server.example.com -b dc=example,dc=com '(&(objectClass=sudoRole)...)'
- The sudo responder log file:
/var/log/sssd/sssd_sudo.log
- This log file helps you to answer questions like:
- How many rules did SSSD return?
[sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 4-rules rules for [user@idm.example.com]
- What filter was applied for searching the cache of SSSD?
[sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=user)(sudoUser=#10001)(sudoUser=%group-1)(sudoUser=%user)(sudoUser=+*)))]
- How do I look up the rules returned from the SSSD cache? Use the following filter to look up the rules:
# ldbsearch -H /var/lib/sss/db/cache_domain_name.ldb -b cn=sysdb '(&(objectClass=sudoRule)...)'
Note
Theldbsearch
utility is included in the ldb-tools package.
A.3. Troubleshooting Firefox Kerberos Configuration
- Close all instances of Firefox.
- In a command prompt, export values for the
NSPR_LOG_*
variables:export NSPR_LOG_MODULES=negotiateauth:5 export NSPR_LOG_FILE=/tmp/moz.log
- Restart Firefox from that shell, and visit the website where Kerberos authentication is failing.
- Check the
/tmp/moz.log
file for error messages with nsNegotiateAuth in the message.
- No credentials found
-1208550944[90039d0]: entering nsNegotiateAuth::GetNextToken() -1208550944[90039d0]: gss_init_sec_context() failed: Miscellaneous failure No credentials cache found
This means that no Kerberos tickets are available (meaning that they expired or were not generated). To fix this, runkinit
to generate the Kerberos ticket, and then open the website again.- Server not found in Kerberos database
-1208994096[8d683d8]: entering nsAuthGSSAPI::GetNextToken() -1208994096[8d683d8]: gss_init_sec_context() failed: Miscellaneous failure Server not found in Kerberos database
This means that the browser is unable to contact the KDC. This is usually a Kerberos configuration problem. The correct entries must be in the[domain_realm]
section of the/etc/krb5.conf
file to identify the domain. For example:.example.com = EXAMPLE.COM example.com = EXAMPLE.COM
- No errors are present in the log
- An HTTP proxy server could be stripping off the HTTP headers required for Kerberos authentication. Try to connect to the site using HTTPS, which allows the request to pass through unmodified.
Appendix B. Revision History
Revision History | |||
---|---|---|---|
Revision 7.0-31 | Wed Nov 11 2020 | ||
| |||
Revision 7.0-30 | Tue Aug 06 2019 | ||
| |||
Revision 7.0-29 | Tue Apr 08 2019 | ||
| |||
Revision 7.0-28 | Fri Oct 26 2018 | ||
| |||
Revision 7.0-27 | Mon Jun 25 2018 | ||
| |||
Revision 7.0-26 | Tue Apr 10 2018 | ||
| |||
Revision 7.0-25 | Mon Mar 19 2018 | ||
| |||
Revision 7.0-24 | Mon Feb 12 2018 | ||
| |||
Revision 7.0-23 | Mon Jan 29 2018 | ||
| |||
Revision 7.0-22 | Mon Dec 4 2017 | ||
| |||
Revision 7.0-21 | Mon Nov 20 2017 | ||
| |||
Revision 7.0-20 | Mon Nov 6 2017 | ||
| |||
Revision 7.0-19 | Mon Aug 14 2017 | ||
| |||
Revision 7.0-18 | Tue Jul 18 2017 | ||
| |||
Revision 7.0-17 | Mon Mar 27 2017 | ||
| |||
Revision 7.0-16 | Mon Feb 27 2017 | ||
| |||
Revision 7.0-15 | Wed Dec 7 2016 | ||
| |||
Revision 7.0-14 | Tue Oct 18 2016 | ||
| |||
Revision 7.0-13 | Wed Jul 27 2016 | ||
| |||
Revision 7.0-11 | Thu Mar 03 2016 | ||
| |||
Revision 7.0-10 | Tue Feb 09 2016 | ||
| |||
Revision 7.0-9 | Thu Nov 12 2015 | ||
| |||
Revision 7.0-8 | Fri Mar 13 2015 | ||
| |||
Revision 7.0-6 | Wed Feb 25 2015 | ||
| |||
Revision 7.0-4 | Fri Dec 05 2014 | ||
| |||
Revision 7.0-1 | July 16, 2014 | ||
|