One Article Review
| Source |  AlienVault Blog |
|---|---|
| Identifiant | 366300 |
| Date de publication | 2017-05-17 13:00:00 (vue: 2017-05-17 13:00:00) |
| Titre | Basic Best Practices for Securing LDAP and Active Directory with Red Hat |
| Texte | 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 |
| Notes | |
| Envoyé | Oui |
| Condensat | related /etc/krb5 101 12th 2017 abide able about above access account across active adex administrator against algorithmic all already also android application applications applies approach appropriate are article assigned attackers attacks attributes authentication backend backends based basic basics because been best beyond bind both brief but can cards careful centralized certificate certificates choose choosing client clients clusters collisions command common communications completely complex compliance compliance; computing concerned conf confidentiality configuration configurations configure configured configuring considerations consistent continuously covered covers crucial cryptography cyber data default depending detailed directory distributions documentation domains don down edit efficient enable enabling encrypt ensure enter enterprise especially ever existing exploring external eye features file financial first found frequently from functionality functions fundamental further general good government grep group guide has hash hasn't hat hat's have healthcare help here how idmap implementation implementations implemented important industries industry information innovationmaking install installed installing instead integrity intercepted isn't it's its keep keeping kerberos key know knowledgebase krb5 ldap ldaps legacy less lightweight likely limitations limited line linux list login lost lot man manage management many mapping mappings may middle mind mindful more most multiple must names necessary need needs network never non not now nss offers one only openldap opensource operations optional other passwords pcs perform phishing piece pin platforms point policies policy popular possible practice practices pre program properly protocol provide public read recent recommend red regulations remember require required requires resource restricting rhel rid run sake samba scalability scripting secure securing security sense sensitive server servers services sessions set sharing should simpler simplest smart software some sort sorts specific standardized starting storiesinnovation strongly such support supports systems take tdb tdb2 than them these think threats through tls to tokens travels trusted use used useless user uses using various verify versions very wannacryaes way ways website well when whenever which whitelisting will winbind windows within without work working works workstation write yet you'll your yum |
| Tags | |
| Stories | Wannacry |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.