Additional Topics
These are some additional notes from previous versions of lpi exams.
Linux Login basics
/etc/login.defs
The /etc/login.defs file provides default configuration information for several user account parameters. The useradd, usermod, userdel, and groupadd commands, and other user and group utilities take default values from this file. Each line consists of a directive name and associated value.
[root@rocky8 ~]# cat /etc/login.defs
#
# Please note that the parameters in this configuration file control the
# behavior of the tools from the shadow-utils component. None of these
# tools uses the PAM mechanism, and the utilities that use PAM (such as the
# passwd command) should therefore be configured elsewhere. Refer to
# /etc/pam.d/system-auth for more information.
#
# *REQUIRED*
# Directory where mailboxes reside, _or_ name of file, relative to the
# home directory. If you _do_ define both, MAIL_DIR takes precedence.
# QMAIL_DIR is for Qmail
#
#QMAIL_DIR Maildir
MAIL_DIR /var/spool/mail
#MAIL_FILE .mail
# Default initial "umask" value used by login(1) on non-PAM enabled systems.
# Default "umask" value for pam_umask(8) on PAM enabled systems.
# UMASK is also used by useradd(8) and newusers(8) to set the mode for new
# home directories if HOME_MODE is not set.
# 022 is the default value, but 027, or even 077, could be considered
# for increased privacy. There is no One True Answer here: each sysadmin
# must make up their mind.
UMASK 022
# HOME_MODE is used by useradd(8) and newusers(8) to set the mode for new
# home directories.
# If HOME_MODE is not set, the value of UMASK is used to create the mode.
HOME_MODE 0700
# Password aging controls:
#
# PASS_MAX_DAYS Maximum number of days a password may be used.
# PASS_MIN_DAYS Minimum number of days allowed between password changes.
# PASS_MIN_LEN Minimum acceptable password length.
# PASS_WARN_AGE Number of days warning given before a password expires.
#
PASS_MAX_DAYS 99999
PASS_MIN_DAYS 0
PASS_MIN_LEN 5
PASS_WARN_AGE 7
#
# Min/max values for automatic uid selection in useradd
#
UID_MIN 1000
UID_MAX 60000
# System accounts
SYS_UID_MIN 201
SYS_UID_MAX 999
#
# Min/max values for automatic gid selection in groupadd
#
GID_MIN 1000
GID_MAX 60000
# System accounts
SYS_GID_MIN 201
SYS_GID_MAX 999
#
# If defined, this command is run when removing a user.
# It should remove any at/cron/print jobs etc. owned by
# the user to be removed (passed as the first argument).
#
#USERDEL_CMD /usr/sbin/userdel_local
#
# If useradd should create home directories for users by default
# On RH systems, we do. This option is overridden with the -m flag on
# useradd command line.
#
CREATE_HOME yes
# This enables userdel to remove user groups if no members exist.
#
USERGROUPS_ENAB yes
# Use SHA512 to encrypt password.
ENCRYPT_METHOD SHA512/etc/login.defs has been replaced with pam over the time but some of parameters are still here:
Location of user mailboxes MAIL_DIR
Password aging controls
Minimum and maximum values for automatic UID selection (1000 to 60000)
Minimum and maximum values for automatic GID selection (1000 to 60000)
Whether home directories should be created when adding a new user
Default umask
Encryption method used to encrypt passwords
The /etc/login.defs file defines the configuration of the shadow password suite.(hidden passwords) for the system. This file is essential. His absence will not prevent the system to work, but will probably have undesirable consequences.
chage
the “chage” command is derived from the words “Change Age”, which is used to modify the information such as duration when to change password, make account status active or inactive, sets expiry date of the account, and sets a reminder to change the password through an alarm before user’s account will be inactive.
note1: chage requires root for most functionality.
note2: User must have entry in /etc/shadow (it must be a local user, it can't be stored in sssd or user in Remote Directory Server)
NSS Concepts
NSS stands for Name Service Switch. It connects calls for information from a system data base to a back-end service.
/etc/nsswitch.conf
/etc/nsswitch.conf is a Linux configuration file that specifies how the system should switch between different name service providers. The file can be used to configure which services should be used for hostname lookup, password lookups, and so on.
“/etc/nsswitch.conf” file is read by the Name Service Switch (NSS) library when the system starts up. The NSS library then uses the information in “/etc/nsswitch.conf” to determine which name service providers should be used for each type of lookup.
“/etc/nsswitch.conf” is a critical part of the Linux operating system, and any changes to the file can potentially cause serious problems.
pam concepts and configuration
PAM (pluggable authentication module) has become a core part of login in most modern linux distributions. PAM is made up number of modules each handling unique function regarding authentication and authorization. Applications enabled to make use of PAM can be plugged-in to new technologies without modifying the existing applications.
PAM is divided to four management groups:
account: provide services for account verification: has the user’s password expired?; is this user permitted access to the requested service?.
authentication: authenticate a user and set up user credentials.
password: are responsible for updating user passwords and work together with authentication modules.
session: manage actions performed at the beginning of a session and end of a session.
The PAM framework consists of a library, pluggable modules, and a configuration file.
The PAM library implements the PAM application programming interface (API) and serves to manage PAM transactions and invoke the PAM service programming interface (SPI) defined in the pluggable modules.
Pluggable modules are dynamically loaded by the library based on the invoking service and its entry in the configuration file. Success is determined not only by the pluggable module but also by the behavior defined for the service. Through the concept of stacking, a service can be configured to authenticate through multiple authentication methods. If supported, modules can also be configured to use a previously submitted password rather than prompting for additional input.
configuration file In earlier versions of PAM, the /etc/pam.conf file was used, but this file is now deprecated and is only used if the /etc/pam.d/ directory does not exist
How PAM Works
The functionality of the PAM system is actually fairly basic. Any service that requires authentication is linked against the PAM libraries included with Linux.
For example, try the following:
When a specific service such as login requires user authentication, it employs the PAM routines to complete this authentication. These routines look at the PAM configuration files for stack entries with a matching service name. They then process these entries in the order in which they are found, one by one.
/etc/pam.d
The /etc/pam.d/ directory contains the PAM configuration files for each PAM-aware application.
lets take a look at classic pam authenrication module /etc/pam.d/system_auth file:
PAM Configuration File Format is like this:
There are several simple flags, which use only a keyword to set the configuration:
requisite: If a requisite module fails, the stack fails immediately - no further modules are invoked.required: A required modules must succeed for stack success however a required module failure will not stop remaining checks from being invoked though the stack will still fail..sufficient: If any sufficient module in a stack succeeds, then remaining sufficient modules are not invoked.optional: Optional Modules only causes failure if it is the only module in the stack.
Visit my LPIC2 book for full review: https://borosan.gitbook.io/lpic2-exam-guide/2102-pam-authentication#pam-pluggable-authentication-modules
pam_cracklib Module
When added to the PAM password stack, the pam_cracklib module performs strength checking of proposed user passwords. The module calls the cracklib routine that compares passwords against a dictionary of known (common, weak, default, etc.) words before performing further strength checks.
Capabilities include:
minlen=Nretry=N— A user may only be prompted N times before the module returns an error.enforce_for_root— Root must also follow set rules (off by default).credit parameters— If above 0, provide a reduction up to N in password minlength for each occurrence of a given class.
Example: password requisite pam_cracklib.so retry=3 minlength=8
This line in the PAM stack will allow a user to submit up to 3 passwords that must satisfy a minimum length of 8 characters: See man pam_cracklib for more detail.
install libpam-cracklib and read its man page for more information.
pam_tally.so
The pam_tally.so and pam_tally2.so are able to count login attempts by a user and to act on a number of consecutive failed logins.
pam_tally.so originally served this purpose and Logs attempts to /var/log/faillog by default. we could use faillog to view a user's last failed login attempt. pam_tally.so deprecated in favor of pam_tally2.so . See man pam_tally
pam_tally2.so
Regarding pam_tally2.so Logs to /var/log/tallylog
Important auth parameters:
deny=nwill instruct tally to deny login after n failed login attempts.unlock_time=nwill allow denied users to attempt again after n seconds.even_deny_rootwill make root subject to lock out as well (this is not default).
Example implementation:
auth required pam_tally2.so deny=4 even_deny_root unlock_time=1200
Locks accounts (including root) for 20 minutes after 4 failed login attempts.
By default, pamtally2 module is already installed on the most of the Linux distributions and it is controlled by PAM package itself. try
man pam_tally2for more information.
Kerbrose
What is kerbrose?
Kerberos is a computer network security protocol that authenticates service requests between two or more trusted hosts across an untrusted network, like the internet. It uses secret-key cryptography and a trusted third party for authenticating client-server applications and verifying users' identities.
history
Initially developed by the Massachusetts Institute of Technology (MIT) for Project Athena in the late '80s, Kerberos is now the default authorization technology used by Microsoft Windows. Kerberos implementations also exist for other operating systems such as Apple OS, FreeBSD, UNIX, and Linux.
Microsoft rolled out its version of Kerberos in Windows 2000, and it's become the go-to protocol for websites and single sign-on implementations over different platforms. The Kerberos Consortium maintains the Kerberos as an open-source project.
How Kerbrose works?
In Kerberos Authentication server and database is used for client authentication. Kerberos runs as a third-party trusted server known as the Key Distribution Center (KDC). Each user and service on the network is a principal.
The main components of Kerberos are:
Authentication Server (AS): The Authentication Server performs the initial authentication and ticket for Ticket Granting Service.
Database: The Authentication Server verifies the access rights of users in the database.
Ticket Granting Server (TGS): The Ticket Granting Server issues the ticket for the Server
Step-1: User login and request services on the host. Thus user requests for ticket-granting service.
Step-2: Authentication Server verifies user’s access right using database and then gives ticket-granting-ticket (TGT) and session key. Results are encrypted using the Password of the user.
Step-3: The decryption of the message is done using the password then send the ticket to Ticket Granting Server. The Ticket contains authenticators like user names and network addresses.
Step-4: Ticket Granting Server decrypts the ticket sent by User and authenticator verifies the request then creates the ticket for requesting services from the Server.
Step-5: The user sends the Ticket and Authenticator to the Server.
Step-6: The server verifies the Ticket and authenticators then generate access to the service. After this User can access the services.
/etc/krb5.conf
The krb5.conf file contains Kerberos configuration information, including the locations of KDCs and administration daemons for the Kerberos realms of interest, defaults for the current realm and for Kerberos applications, and mappings of host names onto Kerberos realms. This file must reside on all Kerberos clients.
The format of the krb5.conf consists of sections headings in square brackets. Each section can contain zero or more configuration variables (called relations), of the form:
relation= relation-value
or
lets take a look at that:
The krb5.conf file can contain any or all of the following sections:
libdefaults: Contains default values used by the Kerberos V5 library.
appdefaults: Contains subsections for Kerberos V5 applications, where relation-subsection is the name of an application. Each subsection describes application-specific defaults.
realms :Contains subsections for Kerberos realms, where relation-subsection is the name of a realm. Each subsection contains relations that define the properties for that particular realm.
domain_realm: Contains relations which map domain names and subdomains onto Kerberos realm names. This is used by programs to determine what realm a host should be in, given its fully qualified domain name.
logging :Contains relations which determine how Kerberos programs are to perform logging.
capaths: Contains the authentication paths used with direct (nonhierarchical) cross-realm authentication. Entries in this section are used by the client to determine the intermediate realms which can be used in cross-realm authentication. It is also used by the end-service when checking the transited field for trusted intermediate realms.
plugins: Control plogin module registration.
Kerberos Commands
List of some commands that are included in the Kerberos product:
kinit
Obtains and caches Kerberos ticket-granting tickets
klist
Displays current Kerberos tickets
kpasswd
Changes a Kerberos password
kdestroy
Destroys Kerberos tickets
Understanding sssd
The System Security Services Daemon (SSSD) is a system service to access remote directories and authentication mechanisms. It connects a local system (an SSSD client) to an external back-end system (a provider). This provides the SSSD client with access to identity and authentication remote services using an SSSD provider. For example, these remote services include:
Active Directory
FreelPA
LDAP
Kerberos
Local Domain
For this purpose, SSSD:
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.
Users on the local system are then able to authenticate using the user accounts stored in the external back-end system.SSSD does not create user accounts on the local system. Instead, it uses the identities from the external data store and lets the users access the local system.
SSSD can also provide caches for several system services, such as Name Service Switch (NSS) or Pluggable Authentication Modules (PAM).
/etc/sssd/sssd.conf
SSSD services and domains are configured in a .conf file. By default, this is /etc/sssd/sssd.conf — although that file must be created and configured manually, since SSSD is not configured after installation.
There are different configurations sssd has for different back-end service:
Creating the sssd.conf File
There are three parts of the SSSD configuration file:
[sssd], for general SSSD process and operational configuration; this basically lists the configured services, domains, and configuration parameters for each[service_name], for configuration options for each supported system service, as described in Section 13.2.4, “SSSD and System Services”
[domain_type/DOMAIN_NAME], for configuration options for each configured identity provider
there is a very pretty configuration example file at /usr/share/doc/sssd-common/sssd-example.conf:
as an example let me show what steps are required to have a sssd.conf file:
try
man pam_sssfor inculding map module to that login process.
sss commands family
There are different sss_* commands and each serves different functions(you might need to install sssd):
sss_useradd
creates a new user account using the values specified on the command line plus the default values from the system.
sss_userdel
deletes a user identified by login name LOGIN from the system.
sss_usermod
modifies the account specified by LOGIN to reflect the changes that are specified on the command line.
sss_groupadd
creates a new group. These groups are compatible with POSIX groups, with the additional feature that they can contain other groups as members.
sss_groupdel
deletes a group identified by its name GROUP from the system.
sss_groupshow
displays information about a group identified by its name GROUP. The information includes the group ID number, members of the group and the parent group.
sss_cache
invalidates records in SSSD cache. Invalidated records are forced to be reloaded from server as soon as related SSSD backend is online.
sss_obfuscate
converts a given password into human-unreadable format and places it into appropriate domain section of the SSSD config file.
read man page of each commands above for more information
.
.
.
resources:
https://www.man7.org/linux/man-pages/man5/login.defs.5.html
https://linuxhint.com/use-linux-chage-command/
https://man7.org/linux/man-pages/man5/nss.5.html
https://tecadmin.net/what-is-etc-nsswitch-conf-file/
https://www.ibm.com/docs/en/aix/7.2?topic=system-pluggable-authentication-modules
https://www.thegeekdiary.com/pam-password-complexity-and-pam_cracklib-credit-system-in-centos-rhel/
https://www.tecmint.com/use-pam_tally2-to-lock-and-unlock-ssh-failed-login-attempts/
https://www.simplilearn.com/what-is-kerberos-article
https://www.geeksforgeeks.org/kerberos/
https://www.techtarget.com/searchsecurity/definition/Kerberos
Last updated