Severity analysis of vulnerabilities by experts from the information security industry is rarely based on real code review. In the ‘Badlock’ case, most read our CVE descriptions and built up a score representing a risk this CVE poses to a user. There is nothing wrong with this approach if it is done correctly. CVEs are analyzed in isolation; as if no other issue exists. In the case of a ‘Badlock‘ there were eight CVEs. The difference is the fact that one of them was in a foundational component used by most of the code affected by the remaining seven CVEs. That very specific CVE was
Continue reading “How Badlock Was Discovered and Fixed”
In a previous post, I compared the features and capabilities of Samba winbind and SSSD. In this post, I will focus on formulating a set of criteria for how to choose between SSSD and winbind. In general, my recommendation is to choose SSSD… but there are some notable exceptions.
Continue reading “SSSD vs Winbind”
This post is dedicated to the new SSSD features in Red Hat Enterprise Linux 7.1 that have significance when SSSD is used by itself (i.e. without IdM integration) – for example, when connecting directly to Active Directory (AD) or some other Directory Server.
Control Access to Linux Machines with Active Directory GPO
A common use case for managing computer-based access control in an Active Directory environment is through the use of GPO policy settings related to Windows Logon Rights. The Administrator who maintains a heterogeneous AD and Red Hat Enterprise Linux network without an IdM server has traditionally had to face the challenging task of centrally controlling access to the Linux machines without being able to update the SSSD configuration on each and every client machine.
In Red Hat Enterprise Linux 7.1, the Administrator is (now) able to
Continue reading “New SSSD Features in Red Hat Enterprise Linux 7.1”
As mentioned in my previous post there are multiple ways to connect a Linux system to Active Directory (AD) directly. With this in mind, let us review the following list of options…
- The legacy integration option: this is a solution where (likely older) native Linux tools are used to connect to an LDAP server of your choice (e.g. AD).
- The traditional integration option: this is a solution based on Samba winbind.
- The third-party integration option: this is a solution based on (proprietary) commercial software.
- The contemporary integration option: this is a solution based on SSSD.
Legacy Integration Option
In the case of the legacy integration option (see figure above), a Linux system is connected to AD using LDAP for identity lookup and LDAP or Kerberos for authentication. It pretty much solves the problem of basic user authentication. That said, such a solution has the following significant limitations:
Continue reading “Overview of Direct Integration Options”
This post is the second in a series of blog posts about integrating Linux systems into Active Directory environments. In the previous post we discussed dishwashers and, more seriously, some basic principles. In this post I will continue by exploring how the integration gap between Linux systems and Active Directory emerged, how it was formerly addressed, and what options are available now.
Let’s start with a bit of history… before the advent of Active Directory, Linux and UNIX systems had developed ways to connect to, and interact with, a central LDAP server for identity look-up and authentication purposes. These connections were basic, but as the environments were not overly complex (in comparison to modern equivalents) – they were good enough for the time. Then… AD was born.
Active Directory not only integrated several services (namely: LDAP, Kerberos, and DNS) under one hood, but it also
Continue reading “Closing the Integration Gap”