Ranger supports three Authentication methods namely : Active Directory, LDAP and Unix. But it used to support only shadow based authentication if configured for Unix authentication. That was outdated as recent Linux systems now support PAM authentication which allows multiple authentication sources and also does authorization.
Ranger community has been working on adding PAM support for Ranger. They have resolved this issue, here is the related link in case you are interest in how they accomplished this:
So, what exactly are the advantages of PAM? This blog will help explain the background and PAM configuration for Ranger.
How User information is stored on your system
First, we should know how user information is stored on the system. On almost all Linux distributions, user information is stored in /etc/passwd which contains the users’ login, encrypted password, unique user id, unique group id, optional comment field, home directory, and preferred shell.
An entry would look like this:
It’s pretty straight-forward. But wait, why is the password filed “x”? Of course it’s not the real content of password. To explain this, we need to talk about Shadow passwords.
The /etc/passwd file, which contains the information about all users, is accessible by all users. In this way, any user can get the encrypted password for every user on the system. Even though the passwords are encrypted, it’s still not safe since password-cracking programs are widely available. To solve this, shadow passwords were developed.
When a system has shadow passwords enabled, the password field in /etc/passwd is replaced by “x” and the user’s real encrypted password is stored in /etc/shadow. This file is only readable by the root user, malicious users can’t access their fellow users’ passwords. Each entry in /etc/shadow contains the user’s login, their encrypted password, and a number of fields relating to password expiration. Here is a typical entry:
/etc/group and /etc/gshadow
Group information is stored in /etc/group. The format is similar to that of /etc/passwd. And group passwords can be shadowed and stored in etc/gshadow.
MD5 encrypted passwords
Traditionally, UNIX passwords were encrypted using the standard crypt() function, but as modern computers grew faster, passwords with this function became easier to crack. So many newer distributions ship with the stronger MD5 hash algorithm. While MD5 passwords will not eliminate the threat of password cracking, they will make cracking passwords much more difficult.
What a mess!
As you can see, there are number of different ways user authentication information can be stored on your system (shadow passwords without MD5 encryption, /etc/passwd passwords with MD5 encryption, etc.). How do programs know how to verify your password? Even worse, what if you want to change the way passwords are stored on your system? How will programs that need your password know that passwords are stored differently? PAM is the answer.
PAM (Pluggable Authentication Modules)
As we explained above, in the old days, programs simply read and edit /etc/passwd file. This is clumsy and many problems got presented. As MD5 and shadow passwords became popular, each program requiring user authentication had to know how to get the proper information when dealing with lots of different schemes. If you wanted to change your user authentication scheme, all those programs had to be recompiled. PAM can avoid this mess by enabling programs to transparently authenticate users, regardless of how user information is stored.
The purpose of PAM is to separate the development of privilege granting software from the development of secure and appropriate authentication schemes. This is accomplished by providing a library of functions that an application may use to request that a user be authenticated. With PAM, it doesn’t matter whether your password is stored in /etc/passwd or on a server in Tokyo. When a program needs to authenticate a user, PAM provides a library containing the functions for the proper authentication scheme. Because this library is loaded dynamically, changing authentication schemes can be done by simply editing a configuration file.
Flexibility is one of PAM’s greatest strengths, PAM can be configured to deny certain programs the right to authenticate users, to only allow certain users to be authenticated, to warn when certain programs attempt to authenticate, or even to deprive all users of login privileges. PAM’s modular design gives you complete control over how users are authenticated.
PAM configuration files
PAM configuration files are stored in the /etc/pam.d directory.
You can see different files for different programs on your system. Each file contains the PAM authentication for the program it’s named after (except for the other file). Let’s take a look at the PAM configuration for login:
PAM configuration syntax
type control module-path module-arguments
The type token tells PAM what type of authentication is to be used for this module. Modules of the same type can be “stacked”, requiring a user to meet multiple requirements to be authenticated.
Determines whether the user is allowed to access the service, whether their password has expired, etc.
Determines whether the user is who they claim to be, usually by a password.
Provides a mechanism for the user to change their authentication. Again, this is usually their password.
Things that should be done before and/or after the user is authenticated. This might include things such as mounting/unmounting the user home directory, logging their login/logout, and restricting/unrestricting the services available to the user.
In the login file, we can see all types. Since this is the program that allows user to login, it’s understandable that it need to access all of different types of authentication.
The control token tells PAM what should be done if authentication by this module fails.
Failure to authentication via this module results in immediate denial of authentication.
Failure also results in denial of authentication, although PAM will still call all the other modules listed for this service before denying authentication.
If authentication by this module is successful, PAM will grant authentication, even if a previous required module failed.
Whether this module succeeds or fails is only significant if it is the only module of its type for this service.
In the login configuration file for login, we see almost all control types. Most of the required modules are pam_unix.so(the main authentication module).
The module-path tells PAM which module to use. Most configurations only contains the module’s name. PAM will look for the modules in the default PAM module directory, normally /usr/lib/security or /lib/security.
The module-arguments are arguments to be passed to the module. Each module has its own arguments.
All of the files in etc/pam.d contain the configuration for a particular service. One exception is the /etc/pam.d/other file. This file contains the configuration for any services which do not have their own configuration file. For ranger, if ranger-admin service attempted authentication, PAM would look for a /etc/pam.d/ranger-admin file. Not finding one, authentication for ranger-admin would be determined by the /etc/pam.d/other file. This file is important and should be configured properly.
Enable PAM for Ranger
After applying PAM support to Ranger, we can also benefit from all the advantages from PAM. We can activate PAM authentication for Ranger as long as your system support PAM (Almost every distribution now has PAM support). After installing Ranger with the RANGER-842 PAM build, change the configuration file ranger-admin-site.xml.
- Change the configuration file ranger-admin-site.xml
- If you are using IOP/Ambari to install Ranger, the path would be /usr/iop/current/ranger-admin/conf/ranger-admin-site.xml
- If you are installing Ranger manually, go to /usr/local/ranger-admin/conf/ranger-admin-site.xml
Find the property “ranger.authentication.method” and change its value to “PAM”.
- Restart ranger-admin service using the command:
- Create PAM configuration files for Ranger
Go to /etc/pam.d directory and create two files “ranger-admin” and “ranger-remote” with the following content:
Of course you can change the configuration according to your own needs.
Now, PAM authentication should be in place.
- Change the configuration file ranger-admin-site.xml
How Ranger is using PAM to do authentication
- Internal user
Internal users are those users which are created by ranger Admin Policy Manager. when you login to ranger policy manager as admin user, you can be able yo create and edit all users. when created from the web interface, users are internal users.
- External user
External users are those users which are synced from other system like Active Directory (AD), LDAP or Unix system.
Ranger has two types of users: internal and external users. Ranger stores all these users in its database.
One big difference between internal and external users is that Ranger database stores valid encrypted password for internal ones, but for external users, the encrypted-password stored in the JDBC table is random plain-text, which will never match. When Ranger is performing PAM authentication, there are two steps:
• Ranger checks PAM authentication first
• If PAM authentication fails, Ranger goes to JDBC authentication using the ranger database.
When authenticating internal users, PAM would fail since internal users are all stored in the local database not in /etc/passwd or /etc/shadow. Then Ranger goes to the local database for authentication.
But external users such as Unix users are not “actually” in the local database. Although you can find the user info along with their encrypted password in the database but the encrypted-password stored in the JDBC table is invalid random plain-text. For these external users, the first step of PAM authentication would work.
- Internal user