tencent cloud

TencentOS Server

문서TencentOS ServerUser GuideSecurity ConfigurationAuthentication and Services (PAM-Kerberos-SSSD)

Authentication and Services (PAM-Kerberos-SSSD)

다운로드
포커스 모드
폰트 크기
마지막 업데이트 시간: 2026-10-19 17:22:49
AI 번역
This document describes how to configure PAM (Pluggable Authentication Modules), the Kerberos authentication protocol, and SSSD (System Security Services Daemon) in TencentOS Server to implement unified authentication and authorization management.

Configuring PAM

PAM Overview

PAM (Pluggable Authentication Modules) is a modular authentication mechanism that provides a unified authentication interface, allowing applications to handle various authentication technologies more easily and return verification results (success/failure). PAM enables system administrators to flexibly configure and manage authentication policies without modifying applications.
PAM is controlled through configuration files, which define the connection between applications (services) and the PAM modules that actually perform authentication tasks. Each application or service may have a corresponding PAM configuration file. For example, the PAM configuration file for SSH is named /etc/pam.d/sshd.

PAM Configuration File

The global configuration file for PAM is /etc/pam.conf, and the configuration directory for PAM is /etc/pam.d/. If the /etc/pam.d/ directory exists, the /etc/pam.conf file is ignored.
A configuration file is a collection of rules, with each rule on a single line and containing the following four fields: type, control, module-path, and module-arguments.
The available values and descriptions of the type field are as follows:
type Value
Description
Account management (Account)
Provides account verification services, such as checking whether user passwords are expired and whether access to requested services is allowed.
Authentication (Auth)
Authenticate users and set user certificates. Authentication can be performed by using passwords, one-time passwords, hardware authentication, and other methods.
Password management (Password)
Update the authentication mechanism, commonly used to manage the creation, change, and deletion of user passwords. For example, set password complexity, expiration time, and other attributes.
Session management (Session)
Perform operations when a user logs in and logs out, such as recording the user's login time, configuring the environment, setting resource limits, and allocating file system space.
Note: If a field value in the preceding table is preceded by a - character, the PAM library will not log to the system log if the module cannot be loaded because it is missing from the system.
The common values and descriptions of the control field are as follows:
control Value
Description
required
The module must be successfully executed; otherwise, authentication fails. After a failure, subsequent modules continue to be executed and failure information is returned.
requisite
The module must be successfully executed; otherwise, authentication fails immediately and subsequent modules are not executed.
sufficient
If the module is successfully executed, authentication succeeds immediately and subsequent modules are not executed. If the module fails, authentication does not fail immediately; instead, subsequent modules continue to be executed.
optional
The module execution result does not affect the authentication result unless it is the only module.
include
Insert the content of another PAM configuration file directly into the current configuration file.
substack
Pause the current stack and start executing modules in the referenced file. After all modules in the referenced file are executed, PAM resumes executing the next module in the current file.
For more complex syntax, a valid control value has the following form: [value1=action1 value2=action2 ...]
Module path (module-path):
This field indicates the location of PAM modules in the file system. You can use the modules provided by PAM, which are located in the /lib64/security/ directory. You can also use custom modules via an absolute path.
Module arguments (module-arguments):
These are parameters provided to PAM modules. Different PAM modules provide different parameters. You can view the specific parameters of each module in the man pages, for example, man pam_unix.

Modifying PAM Configurations

Note: PAM module configurations take effect immediately. Therefore, exercise caution when modifying configurations. It is recommended to verify configurations in a test environment first and back up existing configuration files to avoid errors.

Limiting the Access of Specific Users

Use the pam_listfile.so module to allow or deny specific users access to a service. For example, the following configuration can be used to prevent the root user from logging in via SSH.
1. Modify the /etc/pam.d/sshd file and add the following rule on the first line to prevent the root user from logging in via SSH. This rule uses the pam_listfile.so module to check whether the login username exists in the deny list. The control flag is set to required, which means authentication can continue only when the module check passes (that is, the user is not in the deny list):
auth required pam_listfile.so item=user sense=deny file=/etc/ssh/deniedusers onerr=fail
2. Create the file /etc/ssh/deniedusers and add the usernames to be denied SSH login:
sudo vim /etc/ssh/deniedusers
3. Set file permissions to prevent accidental operations by other users:
sudo chmod 600 /etc/ssh/deniedusers
The parameters in the rule are described as follows:
item=user: Specifies that the check target is user.
sense=deny: Specifies the action to take if the corresponding user is found in the file specified by file. If the user is not found, the opposite action is taken.
file=/etc/ssh/deniedusers: Specifies the file that contains one user per line.
onerr=fail: Specifies the action to take when an error occurs.
PAM module configurations take effect immediately. After that, you cannot access SSH or log in to services as the root user. To view more parameters of the pam_listfile.so module, run man pam_listfile to check the man page.

Limiting the Number of User Login Sessions

Use the pam_limits.so module to set limits on system resources. For example, the following configurations can be used to limit the number of user login sessions.
1. Modify the /etc/pam.d/login and /etc/pam.d/sshd files, and add a rule to enable the pam_limits.so module:
session required pam_limits.so
2. Edit the /etc/security/limits.conf file. By default, the pam_limits.so module reads the /etc/security/limits.conf configuration file and the /etc/security/limits.d/*.conf files. Add the following lines to limit user user1 and members of group group1 to a maximum of 3 concurrent login sessions:
user1 - maxlogins 3
@group1 - maxlogins 3
The PAM module configurations take effect immediately. When the user user1 has multiple login sessions, the following prompt will be displayed:
There were too many logins for 'user1'.

Configuring Kerberos

Basic Concepts

Kerberos is an identity authentication protocol that provides mutual authentication and authorization services for servers and client programs through a key system, enabling single sign-on and unified identity authentication to improve system security and management efficiency.
The Kerberos authentication process is divided into the following steps:
1. Client requests a TGT from the AS: The client requests a Ticket Granting Ticket (TGT) from the Authentication Service (AS). After the AS verifies the client's identity, it generates a TGT and sends it to the client. The client decrypts the TGT using a key and extracts the session key from it. At this point, the client has a valid TGT that can be used to request tickets for accessing services.
2. Client requests an ST from the TGS: When the client needs to access a protected service, it sends a request to the Ticket Granting Service (TGS) along with the TGT and a new Authenticator. The TGS verifies the TGT and the Authenticator, and then generates a Service Ticket that contains a session key shared between the client and the service. The client receives the Service Ticket, decrypts it, and extracts the session key.
3. Client communicates with the Server: The client uses the session key to generate a new Authenticator and sends it together with the Ticket to the service. The service verifies the Service Ticket and the Authenticator to confirm the client's identity. The service can then use the session key to communicate securely with the client.
This process ensures the security of communications between the client and the server while avoiding the transmission of plaintext passwords over the network.

Use and Configuration

Environment Configuration

Set the realm to OPENCLOUDOS.COM.
Use two machines in the same VPC subnet, with one serving as the Key Distribution Center (KDC) and the other as the client. The KDC contains the Authentication Server (AS) and the Ticket Granting Server (TGS).
Host Name
Private IP Address
Role
KDC
192.168.160.161
Master KDC
Client
192.168.160.165
Kerberos Client
Add the following configurations to the /etc/hosts file on both hosts to ensure that the host names can be resolved:
192.168.160.161 KDC
192.168.160.165 Client

Server Configuration

1. Install the Kerberos server (installed with KDC) and administrator tools:
dnf install krb5-server krb5-workstation krb5-libs
2. Configure the krb5.conf file:
The default path of the file is /etc/krb5.conf. Configure the Kerberos authentication service in this file, and synchronize the file to all hosts that use Kerberos.
[libdefaults]
    default_realm = OPENCLOUDOS.COM

[realms]
    OPENCLOUDOS.COM = {
        kdc = 192.168.160.161
        admin_server = 192.168.160.161
    }
3. Configure the kdc.conf file:
The default path of the file is /var/kerberos/krb5kdc/kdc.conf. Modify the configuration information of the Kerberos realm on the KDC server.
[realms]
    OPENCLOUDOS.COM = {
        acl_file = /var/kerberos/krb5kdc/kadm5.acl
        dict_file = /usr/share/dict/words
        default_principal_flags = +preauth
        admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
        supported_enctypes = aes256-cts:normal aes128-cts:normal arcfour-hmac:normal camellia256-cts:normal camellia128-cts:normal
    }
4. Configure the kadm5.acl file:
The default path of the file is /var/kerberos/krb5kdc/kadm5.acl. This file controls administrative permissions for the Kerberos database and grants the admin principal full access permission.
*/admin@OPENCLOUDOS.COM *
*/admin is an account form in Kerberos and indicates accounts belonging to the OPENCLOUDOS.COM realm. The * sign in the end indicates that accounts in the */admin form have all permissions.
5. Create the Kerberos database and set the master key:
kdb5_util create -s -r OPENCLOUDOS.COM
-s indicates creating a secure Kerberos database, and -r specifies the Kerberos realm of the database. After the database is created, new files will be generated in the /var/kerberos/krb5kdc/ directory.
6. Add a Kerberos user:
Kerberos uses principals to represent users, services, and other entities. First, create an administrator principal and set a password:
kadmin.local -q "addprinc root/admin"
Add a Kerberos test user:
kadmin.local -q "addprinc krbtest/admin"
Use the listprincs command to view all users:
kadmin.local
kadmin.local: listprincs
7. Start the Kerberos service and enable autostart on boot:
sudo systemctl start krb5kdc
sudo systemctl start kadmin
sudo systemctl enable krb5kdc
sudo systemctl enable kadmin
After starting the service, you can view the log files /var/log/krb5kdc.log and /var/log/kadmind.log.
8. Configure the firewall:
If the firewall is enabled, you need to allow the related services. Take the firewalld firewall as an example:
firewall-cmd --add-service=kerberos --permanent
firewall-cmd --add-service=kadmin --permanent
firewall-cmd --add-service=kpasswd --permanent
firewall-cmd --reload

Client Configurations

Install the Kerberos client:
dnf install krb5-workstation krb5-libs
Configure the krb5.conf file:
It must be consistent with the krb5.conf file in the KDC.
Verify that the KDC issues tickets:
Use the kinit command to verify that the KDC issues tickets. The tickets are stored in the credential cache file, and this command can also be used to test the Kerberos authentication service:
kinit krbtest/admin
View the tickets and their information in the current cache:
klist
Invalidate the cache and the tickets contained within it:
kdestroy

Configuring SSSD

Introduction to SSSD

The System Security Services Daemon (SSSD) is a system service for accessing remote directories and authentication mechanisms.
SSSD maintains a daemon process, which is an intermediary between local users and data storage. This process can be used to access various authentication servers, such as LDAP and Kerberos, and provide authorization. A local client first connects to SSSD, and then SSSD contacts external resource providers, such as a remote server.
Features of SSSD:
This avoids a large number of connections from each local client program to the authentication server. All local programs contact only SSSD, which then connects to the authentication server or uses the SSSD cache, effectively reducing the load.
Offline authentication is allowed. SSSD can cache user authentication identities from remote servers, which allows users to continue to be successfully authorized to access necessary resources when the remote authentication server is down.

Common Commands of SSSD

Query the status information of SSSD:
Generate a report for the idm.example.com domain:
sssctl access-report idm.example.com
Display user data for a specific user:
sssctl user-checks -a acct -s sshd example.user
Query domain information:
Display the list of available domains:
sssctl domain-list
Display user data for a specific domain:
sssctl domain-status idm.example.com
Configure spell check:
sssctl config-check

Common Configurations of SSSD

Enable offline authentication:
Add the following options to the /etc/sssd/sssd.conf file:
[domain/your-domain-name]
cache_credentials = true
Configure the time limit for the offline authentication:
[pam]
offline_credentials_expiration = 3
Note: offline_credentials_expiration defaults to 0, which means no limit.
Configure DNS service discovery (using LDAP as an example):
Add the following options to the /etc/sssd/sssd.conf file:
[domain/your-domain-name]
id_provider = ldap
ldap_uri = _srv_
chpass_provider = ldap
ldap_chpass_dns_service_name = ldap
Optional:
By default, service discovery uses the domain part of the system host name as the domain name. To use a different DNS domain, specify the domain name with the dns_discovery_domain option.
By default, service discovery scans for the LDAP service type. To use a different service type, specify the type with the ldap_dns_service_name option.
By default, SSSD attempts to look up IPv4 addresses. If the attempt fails, SSSD attempts to look up IPv6 addresses. To customize this behavior, use the lookup_family_order option.
Configure access rules:
Set access_provider to simple mode to allow or deny access based on user names or groups:
[domain/your-domain-name]
access_provider = simple
simple_allow_users = user1, user2
simple_allow_groups = group1
Note: If access is denied to a specific user/group, access to all other users/groups is automatically allowed. Therefore, allowing access to specific users is generally considered more secure than denying access to specific users.

Example Use Cases of SSSD (Using OpenLDAP Client as an Example)

Configure TencentOS Server as an OpenLDAP client to achieve the following features:
Verify users stored in the OpenLDAP user account database.
Use the SSSD service to search for user data.
Communicate with the OpenLDAP server via a Transport Layer Security (TLS) encrypted connection.

Preparing the Environment

1. Switch to root and install the software package:
dnf -y install openldap-clients sssd sssd-ldap oddjob-mkhomedir
2. The OpenLDAP server has been installed and configured with user information.
3. A PEM-format copy of the root CA-signed certificate chain from the OpenLDAP server certificate authority is already available.

Detailed Steps

1. Switch the authentication provider to sssd:
authselect select sssd with-mkhomedir
2. Copy the certificate copy to the /etc/openldap/certs directory:
cp core-dirsrv.ca.pem /etc/openldap/certs
3. Add the LDAP server URL and suffix to the /etc/openldap/ldap.conf file:
URI ldap://ldap-server.example.com/
BASE dc=example,dc=com
4. Specify the certificate path for the TLS_CACERT option in the /etc/openldap/ldap.conf file:
TLS_CACERT /etc/openldap/certs/core-dirsrv.ca.pem
5. Add the environment information to the ldap_uri and ldap_search_base parameters in the /etc/sssd/sssd.conf file:
[domain/default]
ldap_uri = ldap://ldap-server.example.com/
ldap_search_base = dc=example,dc=com
6. Specify TLS authentication requirements in the /etc/sssd/sssd.conf file:
cache_credentials = True
ldap_tls_cacert = /etc/openldap/certs/core-dirsrv.ca.pem
ldap_tls_reqcert = hard
7. Adjust the permissions of the /etc/sssd/sssd.conf file:
chmod 600 /etc/sssd/sssd.conf
8. Restart the SSSD service and the oddjobd daemon process:
systemctl restart sssd oddjobd
systemctl enable sssd oddjobd
9. Verify. Use the id command to specify an LDAP user to search for user data from the LDAP server:
id <ldap_user>

이전 주제: Account and Password Security다음 주제: File Permissions and ACLs

도움말 및 지원

문제 해결에 도움이 되었나요?

피드백

키워드로 검색
    Enter keywords to search documentation