An important thing to recall is that UNIX(-like) kernels does not operate with user or group names and such -- they see numbers instead. Naming of users or groups is purely a user-space thing.
The most essential traditional user/group files are:
FreeBSD has a master.passwd file that contains hashed passwords which a binary file passwd actually gets generated from.
crypt(3) or crypt_r(3) function (which also accepts settings -- e.g. what hashing method to use and a salt value) can be used to create a hashed password.
NSS (Name Service Switch) provides a central configuration for mappings between identities/services and configuration sources. This allows to use other resources that traditional files (passwd, shadow, ...) while common programs can keep using functions like getgrnam(3) or getpwnam(3).
NSS can use multiple backends based on a content of /etc/nsswitch.conf. It is a facility that is typically part of libc libraries (glibc in case of GNU/Linux distributions).
Some of backend databases are:
Any of these databases can use LDAP (but a shared library nss_ldap must be present).
A default NSS config file, stored in /etc/.
Its syntax format is: db-backend-name services
where services is one or more services delimited with comma (,), their order matters. Optionally, there can be an action right behind a service specification.
Invoke man 5 nsswitch.conf to read more about what services can be assigned to individual database types.
An example of nsswitch.conf file:
passwd: compat group: compat shadow: compat hosts: dns [!UNAVAIL=return] files networks: nis [NOTFOUND=return] files ethers: nis [NOTFOUND=return] files protocols: nis [NOTFOUND=return] files rpc: nis [NOTFOUND=return] files services: nis [NOTFOUND=return] files
SSSD (System Security Services Daemon) comes with collection of daemons that deal with things like authentication, authorization and other information from various network sources.
One of major features of SSSD is offline caching of network credentials.
Stands for (Linux) Pluggable Authentication Modules and it aims to provide an independent authentication procedure for user-space Linux programs.
It is a collection of modules (shared libraries) which create a boundary between an app and a user of the app.
Development started in 90s, Linux PAM project was created cca in 1996.
It can for instance:
Definitions are stored in config files which contain so called rules describing how a concrete application relates to PAMs. An actual authentication is done by individual PAMs.
PAM files are dynamically loadable object files stored in /lib64/security/ (in case of Fedora). Each module typically has its own man page: e.g. man 8 pam_nologin.
PAM is used for a long time and is popular on many different Unices and Unix-like OSs (including freeBSD or AIX).
[user@machine ~]$ ldd /usr/bin/sshd | grep pam libpam.so.0 => /usr/lib/libpam.so.0 (0x00007f6dd8fa0000)
We can call e.g. sshd a PAM-aware application. An application that does not have support for PAM implemented in its source code cannot be used with PAM.
There are 4 PAM management groups:
account
Modules here may question things like:
authentication
password
session
Be cautious about editing some PAM config files -- you may end up with OS that you can't log into.
Important note: some modules have instances for multiple groups (for example pam_unix.so has all 4 management groups provided.
+----------------+
| application: X |
+----------------+ / +----------+ +================+
| authentication-[---->--\--] Linux- |--<--| PAM config file|
| + [----<--/--] PAM | |================|
|[conversation()][--+ \ | | | X auth .. a.so |
+----------------+ | / +-n--n-----+ | X auth .. b.so |
| | | __| | | _____/
| service user | A | | |____,-----'
| | | V A
+----------------+ +------|-----|---------+ -----+------+
+---u-----u----+ | | |
| auth.... |--[ a ]--[ b ]--[ c ]
+--------------+
| acct.... |--[ b ]--[ d ]
+--------------+
| password |--[ b ]--[ c ]
+--------------+
| session |--[ e ]--[ c ]
+--------------+
Taken from http://www.linux-pam.org/Linux-PAM-html/sag-overview.html.
Can be found in /etc/pam.conf. When /etc/pam.d/ directory exists, pam.conf gets ignored. PAM config files can also be on other places (like /usr/lib/pam.d/ when supplied by vendors), but /etc/pam.d/ has highest priority.
An order of lines mostly matters (more precisely order of all lines with a same control value matters).
#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authselect is run. auth required pam_env.so auth sufficient pam_unix.so try_first_pass nullok auth required pam_deny.so account required pam_unix.so password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= password sufficient pam_unix.so try_first_pass use_authtok nullok sha512 shadow password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so
File contains list of rules, each rule typically being on a standalone line. Comments are marked by # character.
Rules have a following syntax (syntax of modules found in pam.d/ is same except that a first column service is missing): service type control module-path module-arguments
LDAP (Lightweight Directory Access Protocol) is a lightweight variant of DAP protocol which is defined in X.500 series of standards These standard deal with directory services and was first published in 1988.
LDAP is one of directory services -- specialized databases that typically come with fast searching and browsing capabilities (update operations should happen rarely).
These databases typically do not support transactions, because they aim for fast read access only. An update operation may mean that a whole database gets replaced (for some implementations).
LDAP builds on a client-server model.
Directory entries are organized into a tree-like structure. Typically, top levels of the tree contain geographical data. Often times it is based on DNS labels.
+-------+
| dc=cz |
+-------+
|
+---------+
| dc=muni |
+---------+
|
+---------+
| dc=fi |
+---------+
/ \
+------------+ +------------+
| ou=People | | ou=Rooms |
+------------+ +------------+
/
+---------------+
| uid=Dave Null |
+---------------+
For the example above a RDN (Relative Distinguished Name) is uid=Dave Null, while DN is uid=Dave Null,ou=People,dc=fi,dc=muni,dc=cz.
LDIF (LDAP Data Interchange Format) is a standard plain-text format that LDAP uses.
LDIF files can be loaded by ldapadd(1).
Where -x requests a simple authentication, -D specifies a DN to bind to and -W asks for a password query right after command invocation.
A special attribute called objectClass is used to define which attributes are mandatory and what format is allowed.
On Fedora packages openldap, openldap-servers and openldap-clients need to be installed.
Service is called slapd.