Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Extend your Active Directory security policy to Linux and beyond

Danny Kim Founder and CTO, FullArmor

More than 95% of enterprises use Microsoft's Active Directory (AD) as their primary source of identity and access management. But with the advent of cloud computing and software-as-a-service (SaaS) models, a growing number of devices now live outside of traditional AD.

For example, the use of Linux systems has grown in the enterprise—both server installations and a growing number of desktop deployments—putting more systems out of the reach of their primary identity and access management. And cloud-provisioned virtual machines do a variety of workloads and services. 

Several third-party vendors have combined the Samba interoperability suite for Windows with AD, allowing companies to shift Linux and Unix systems traditionally outside of AD into Active Directory Group Policies.

Is your team looking at centralizing security and policy management by extending Active Directory Group Policies? Here's why group policy is a better way forward (than scripting) and how to extend AD's reach across an increasingly heterogeneous enterprise. 

Policy vs. scripting

You can provision Linux through PowerShell scripts or third-party scripting tools such as Chef or Puppet. Although these tools create an easy way to configure each Linux box initially, adding settings and configuration information using scripts will eventually become a management headache. Scripts are hard to read over time, and there’s no standard way of creating compliance reports or of enforcing compliance of scripted configuration items. This is where the benefit of Group Policy in AD comes into play.

Through a standard configuration mechanism such as Group Policy, you can not only push settings down to end devices, but you can also report on them and generate compliance reports. Because you know and have documented the format for the configuration settings, it’s easier to maintain them over time. Third-party Group Policy enforcement agents for Linux and other endpoints can apply and enforce settings in sync with their Microsoft Windows counterparts.

This is especially useful when you manage settings manually on the end device and the Group Policy agent initiates a compliance check. It then reapplies the changed settings to keep every managed endpoint in compliance. This Group Policy mechanism allows organizations to better adhere to compliance standards (PCI, HIPPA, GLBA, etc.) across the enterprise.

How not to script

Examples of bad scripting practices are numerous. You can point to individual horror stories and take comfort in the belief that those scenarios can’t happen to you, that your processes are too good to allow that to happen, or any number of other reasons to hope you are immune to mundane novice mistakes.

However, if after you read some of the examples below, you think that you should forward this to your IT counterparts, you’re probably just as vulnerable. Entropy, the Second Law of Thermodynamics, states, “In a closed system, unconstrained energy spontaneously tends to disperse, to spread out.” When applied to IT systems, it means that if you allow something to grow or disperse uncontrollably, it will most likely spread and disperse.

In the two real-life scenarios below, IT administrators were given unconstrained liberty to script and create Group Policy Objects (GPOs) as they liked.

Scenario 1

A large enterprise came to the realization that it had upwards of 4,000 scripts, both directly or indirectly linked and running in some capacity during the login, setup, or configuration of endpoints and servers. Many of the scripts had been written long ago by IT admins who had long since departed, and arbitrarily changing a script could cause regression or catastrophic cascade effects. So trying to bring them back under control was a Herculean task. The admins had to slowly document and decommission the scripts to get them down to a manageable number.

Scenario 2

A large enterprise, after years of allowing the unfettered creation and use of GPOs, found out it had over 60,000 of them in its AD. This was not just unwieldy, but also presented a security risk due to the number of unsecured, orphaned GPOs, and replication issues due to the large numbers of GPOs. The IT team's reduction project took several months, and with automation it was able to successfully reduce the GPOs down to the hundreds.

The reason these two scenarios differ, other than both companies starting with the unsavory task of bringing a messy environment back under control, is that in the second scenario, they were dealing with GPOs, which are reportable, discoverable, and more easily managed.

In addition, you can use the Resultant Set of Policy (RSoP) report of all Group Policy settings to show which policies apply in which order, and which settings take precedence—including numerous troubleshooting and diagnostic tools that IT admins can use out of the box. As systems become more and more complex, having the right technology to apply and manage security policies is essential to keeping entropy at bay.

Standardize security policy across platforms

Being able to bring Linux systems under the configuration management of native AD using third-party Group Policy enforcement agents for Linux and other endpoints allows IT administrators to centralize security configuration across the enterprise.

It’s not enough to just bridge AD to Linux through an identity connector such as System Security Services Daemon (SSSD) or Samba, which does not apply native AD Group Policy. Third-party services can now extend these connectors with translation for native AD services such as Group Policy, file and print services, and beyond—one policy to centrally configure Windows, Linux, UNIX, and even cloud VMs.

Envision a single administrative console, one audit report for compliance, and a centralized enforcement mechanism across all endpoints. When you have the ability to standardize policies and management, you can support scalability across the entire enterprise, and reduce the complexity and potential drift in security compliance due to multiple settings templates and management tools. Your enterprise can save precious resources and money by creating a centralized and standardized console that performs administration through AD.

Is your team embarking on extending Active Directory Group Policy across your enterprise? Share your experiences in the comments section below.

Keep learning

Read more articles about: SecurityIdentity & Access Management