Linux Authentication and Authorization Mechanism
Security plays a very important role in making any software enterprise ready. Linux has a robust security architecture yet it allows plug-gable module to connect to any external Identity manager for authenticating and authorizing users.
The two most important modules that play a very important role in providing the security feature at OS level are
1. PAM
2. NSS
PAM:
The Pluggable Authentication Module allows integration of various authentication technologies such as standard UNIX, RSA, DCE, LDAP etc. into system services such as login, passwd, rlogin, su, ftp, ssh etc. without changing any of these services.
First implemented by Sun Solaris, PAM is now the standard authentication framework of many Linux distributions, including RedHat and Debian. It provides an API through which authentication requests are mapped into technology specific actions (implemented in the so called pam modules). This mapping is done by PAM configuration files, in which, for each service are basically given the authentication mechanisms to use.
In our case, the pam_ldap module, implemented in the shared library pam_ldap.so, allows user and group authentication using an LDAP service.
Each service that needs an authentication facility, can be configured through the PAM configuration files to use different authentication methods. This means that it is possible, using the PAM configuration files, to write a custom list of requirements that an user must satisfy to obtain access to a resource.
NSS:
Once an user is authenticated, many applications still need access to user information. This information is traditionally contained in text files (/etc/passwd, /etc/shadow, and /etc/group) but can also be provided by other name services.
As a new name service (such as LDAP) is introduced it can be implemented either in the C library (as it was for NIS and DNS) or in the application that wants to use the new nameservice.
Anyway, this can be avoided using a common, general purpose, name service API and by demanding to a set of libraries the task of retrieving this information performing technology based operations.
This solution was adopted in the GNU C Library that implements the Name Service Switch, a method originated from the Sun C library that permits to obtain information from various name services through a common API.
NSS uses a common API and a configuration file (/etc/nsswitch.conf) in which the name service providers for every supported database are specified.
The databases currently supported by NSS [2] are:
- aliases: Mail aliases.
- ethers: Ethernet numbers.
- group: Groups of users.
- hosts: Host names and numbers.
- netgroup: Network wide list of host and users.
- network: Network names and numbers.
- protocols: Network protocols.
- passwd: User passwords.
- rpc: Remote procedure call names and numbers.
- services: Network services.
- shadow: Shadow user passwords.
Using the nss_ldap shared library it is possible to implement the maps above using LDAP, anyway here I'll focus only on the LDAP implementation of shadow, passwd and group database tough all the maps above can be implemented. For most of the other maps it is even unadvisable to store them in ldap, as they tend not to change too often, so it is not a problem to have them locally as files, and storing them in ldap would cause some minor performance loss.
Key Take aways 1. NSS can lookup the local configs of /etc/groups, /etc/passwd for user , uid, group, gid mappings or it can lookup to LDAP to do the same. 2. PAM can lookup /etc/passwd for retrieving the username and password for authentication of lookup a third source. 3. As both modules can talk to external source, what it means is there can uid and gid visisble on the Linux which are not present in local confs of /etc/passwd, /etc/groups. 4. This provides an ability to manage all users, groups and password on LDAP, and both PAM and NSS pointing to LDAP (remote source). 5. On the OS all the uid and gid visible are being fetched from LDAP and have no presence in the local configs. 6. The most important thing to appreciate is the applications are transparent from where the users and groups are coming, as the applications makes a call to PAM or NSS and eventually hit the remote source (LDAP) 7. This provides an opportunity to maintain all the users and groups on LDAP and not locally on the machine. 8. Do remeber both PAM and NSS will have a logic to resolve names as in a uid is present in /etc/passwd , git in /etc/groups and with same uid on LDAP , based on the config the conflict will be resolved. Generally the local config wins over the remote sorurce. 9. An application can make a call to LDAP independently too, there is no restriction to always go through PAM , NSS for reaching out to LDAP.
As users are maintained in a remote Service, making lookups every time becomes expensive . PAM and NSS evntually started becoming very complex hence tools like SSSD, VASD came into being.
SSSD
The sssd daemon (Running locally on the Linux OS) acts as the spider in the web, controlling the login process and more. The login program communicates with the configured pam and nss modules, which in this case are provided by the SSSD package. These modules communicate with the corresponding SSSD responders, which in turn talk to the SSSD Monitor. SSSD looks up the user in the LDAP directory, then contacts the Kerberos KDC for authentication and to aquire tickets.
(PAM and NSS can also talk to LDAP directly using pam_ldap and nss_ldap respectively. However SSSD provides additional functionality.)
Of course, a lot of this depends on how SSSD has been configured; there lots of different scenarios. For example, you can configure SSSD to do authentication directly with LDAP, or authenticate via Kerberos.
The sssd daemon does not actually do much that cannot be done with a system that has been "assembled by hand", but has the advantage that it handles everything in a centralised place. Another important benefit of SSSD is that it caches the credentials, which eases the load on servers and makes it possible to go offline and still login. This way you don't need a local account on the machine for offline authentication.
In a nutshell SSSD is able to provide what nss_ldap, pam_ldap, and pam_krb, and ncsd used to provide in a seamless way.
Lets look at who PAM, NSS integrates with SSD.
Key take aways. 1. PAM, NSS and SSSD/VASD are present locally on your Linux OS. 2. Any call made to OS for authenticating or authorization results in a call go PAM/NSS eventually to SSD and eventually to AD or LDAP. 3. SSD can integrate with LDAP, AD, KDC . 4. Three layers are completely transparent to the OS applications. 5. SSSD/VASD maintains a cache locally on the OS. 6. SSSD/VASD will lookup both in the external source and locally to get user -> password or user name to -> uid , uid-> username, group name to gid, gid-> group name etc. 7. getent passwd, getent groups command do show the source from where its fetching the info
