In the enterprise, it's very popular to manage Windows client PCs through Red Hat servers. This sort of configuration is especially common in healthcare and the financial services industries. Red Hat Enterprise Linux (RHEL) has good software for working with Windows Active Directory. Red Hat Enterprise Linux can also manage clients with multiple platforms, such as Windows, OS X, Android, and other Linux distributions with OpenLDAP, an opensource implementation of the Lightweight Directory Access Protocol (LDAP).
Cyber threats are now more common than ever, so it's crucial to be mindful of security when installing and configuring an LDAP application. You should not only be concerned with information security policy compliance; you should go above and beyond compliance whenever possible without restricting necessary functionality.
This is a brief guide on how to use LDAP in Red Hat in a secure way. Your network and enterprise computing needs may be very complex, as can the specific security policies, government and industry regulations you must abide by. This piece only covers some fundamental basics. Think of it as a starting point, a 101 guide for a network administrator.
The information here applies to Red Hat Enterprise Linux 6 and 7.
There are multiple basic ways to configure RHEL servers with Windows Active Directory, depending on how many servers, clients, and domains you have. You also need to know which sorts of functions you need. Do you need file sharing? Do you need to be able to configure user account attributes? Take a whitelisting approach, and only enable the services that you need. These considerations will help you choose which backend you should run in RHEL for Active Directory management. Choosing the appropriate backend for your needs isn't only important for functionality, but also for security. The most frequently implemented backends are Samba implementations which require Winbind. They all support file sharing and login access.
- idmap_tdb is the default Winbind backend. It's also the simplest to use. It supports both read and write operations. But it must be run from only one RHEL server, and its scalability is limited.
- idmap_rid can be run from multiple RHEL servers, as can all the backends further down this list. It features algorithmic ID mappings across multiple servers, keeping them consistent across RHEL systems. But it only supports read operations.
- idmap_ad uses standardized user configuration, and centralized user account management. But it's read-only, and also requires more work for a network administrator as user and group ID attributes must be set within Active Directory.
- idmap_ldap can keep ID mappings in a non-AD server, such as OpenLDAP. It supports both read and write. Keep in mind that an external LDAP server is required, and it can have a complex configuration because of Samba LDAP mapping limitations.
- idmap_adex works well with legacy versions of Samba, it's not to be used with recent versions of Samba. It's read-only, and ID mappings are assigned by the administrator.
- idmap_hash is read-only and has simpler configuration than other Winbind backends that support multiple RHEL servers. Be careful about ID collisions if you choose this backend.
- idmap_tdb2 supports both read and write operations. Scripting can be used if you perform ID mappings with an external program. But it can only be used with Samba clusters.
- idmap_nss is read-only and uses pre-existing ID mappings. Keep in mind that it offers no support for trusted domains.
Detailed information about choosing a configuration specific to your needs can be found in this guide from Red Hat. Remember that the best practice for security is to choose a configuration that supports all your needs while not enabling services that you'll never use. Remember, take a whitelisting approach.
Installing a Kerberos client is optional, but it's a best practice for secure AD implementations with RHEL. First, you should verify if a Kerberos client has already been installed. At the command line, enter yum list installed | grep krb5. If it hasn't been installed, enter yum -y install krb5-workstation. If Kerberos hasn't been configured yet, edit the /etc/krb5.conf file.
Whenever possible, encrypt your RHEL LDAP communications with TLS. The simplest way to do so is to choose the LDAPS protocol. Using it properly will ensure confidentiality and data integrity, a must for compliance in many data sensitive industries. Authentication certificates can be used with tokens, smart cards, or they can be completely software-based. Choosing certificates instead of non-certificate bind operations is a security best practice. Certificates use public key cryptography. Lost certificates are also useless without the PIN, so it's a way to secure your network against man-in-the-middle and phishing attacks. Also without certificates, bind operations must continuously provide bind directory names and passwords! The less authentication data that travels your network, the less likely your sessions can be intercepted by attackers. It's also a lot more resource efficient.
This article has covered a few fundamental best practices for using Active Directory and general LDAP services with Red Hat Enterprise Linux. It's a starting point. For more specific information for various configurations and applications, I strongly recommend exploring the documentation and knowledgebase on Red Hat's website.
