homeblogmanaging windows security policies puppet enterprise two modules

Managing Windows Security Policies with Puppet Enterprise: Two Modules

Living in a Microsoft world, you get very used to a nice GUI to handle all your tasks. This point-and-click model can make life much easier, and can feel a bit more intuitive…as long as you are dealing with only a few servers. Once your environment starts hitting 50, 100, or thousands of servers, those point-and-click actions start to get tedious.

The system administration world is moving to more centralized administration, and for that, Microsoft has the Group Policy Object Editor. It's a really useful tool that lets you define your specific configurations and template across your Active Directory domains, but it has a few issues you have to watch out for:

  • The server must be part of Active Directory.
  • The server must be part of the right Organization Unit.
  • The server must be correctly authenticating against Active Directory and resolving through DNS.
  • There is not a good way to report whether the configuration succeeded or failed.

Puppet is designed to give you detailed visibility into your infrastructure, as well as granular control of your machines. Puppet’s declarative language also has the advantage of making it much simpler and quicker to manage, track and report on the state of your infrastructure, and to do it securely.

Puppet also has close to 3,000 modules for doing all kinds of tasks, including a wide range of modules for use with Windows — modules that have been written and tested in the real world by Puppet Labs employees and Puppet community members. In this post, I’m going to talk about two modules that can be used to handle Local Security Policy and Local Group Policy, which are the core of Windows security. The two modules that can be used to handle these settings are cannonps-local_security_policy and cannonps-local_group_policy.

There are many reasons why a Domain Group Policy may not be solving all your security and configuration problems. Sometimes you may have demilitarized zones (DMZs) to secure your public-facing infrastructure from your core environment that do not have access to Active Directory. You may have multiple Active Directory domains, which means you have to keep track of multiple Domain Group Policies. Last but not least, with seemingly thousands of settings, it’s often hard to determine whether Group Policy, as it applies to your servers, is really configured the way you want. I have found in working with multiple clients that when we dug deeper into their Windows server security and Group Policy configuration, the settings were not exactly what the clients thought they were. When your boss or security team asks, “Can you be certain that all the settings defined in the corporate policy are being implemented?” hopefully your answer isn’t just “I think so.” You need to know.

That’s where configuration management tools come in. A great configuration management tool gives you a single pane of glass to view the state of your entire infrastructure, no matter which OS, platform, application, or type of configuration you are charged with managing. The best CM tools allow for ease of administration, without you having to do complex scripting, even without you needing to have in-depth knowledge of everything on a server.

Another feature to look for in a configuration management tool is whether it is declarative or procedural. Declarative tools allow you to define the end state, and it is up to the configuration management tool to ensure the end state. Procedural tools are a push-and-pray technology that will deliver scripts on a one-time basis, or on some form of schedule. This does not always work well if there are any connectivity issues, or if the servers are down for maintenance.

Puppet’s declarative model makes managing, tracking, and reporting on the state of your entire infrastructure’s configuration much simpler and quicker. This matters not just for keeping an eye of security, but also for managing each and every detail that defines the purpose and role of the server.

Puppet can enhance the functionality of something like GPO, and can make it easier to manage your local security policies. Some of those settings cannot be scripted or changed by just making some Registry updates, and anyway, you should not need in-depth Registry knowledge just to change your password policy settings. So scripting can get you only so far. Luckily, Puppet and its community of users provide modules for almost every configuration you need to configure your Windows servers, soup to nuts — including security policy.

How it all works

You can check out the Forge pages for detailed instructions; here, I will show the configuration and style of the modules. First note that these modules, like many on the Forge, were created using a type/provider method. This allows you to to list all configurations of that type, whether it is under Puppet’s control or not. Take a look at the command and output below:

CMD> puppet resource local_security_policy

Output for command CMD> puppet resource local_security_policy

You can see the settings for local security policy in this output, including settings for User Rights, Security Options and Account Lockout Policy. While this is just a snippet, all the policies that are set in Windows are listed here.

What is really fun about this is that you can easily build your local security policy manifest by outputting this to a file and making a few changes as you see fit, creating an immediate baseline for your organization to enforce or check against.

CMD> puppet resource local_security_policy > my_lsp.pp

Note that the policy_setting and policy_type are for informational purposes only, and do not have to be part of the manifest. This manifest will work just fine if you specify only the policy and the setting.

You can do pretty much the same as above to set up local group policy. The one difference is that while local security policy is preset on Windows by default, local group policy is a blank slate, and you make the choices. If you have already set a local group policy on a server, the command shown below will give you an output of all the current settings on your system, so you will have a baseline for your configuration manifest.

CMD> puppet resource local_group_policy

Notice that the setup is a bit different from the one-liners you saw for local security policy. For group policies, I have tried to keep the structure very similar to what Microsoft provides. Looking at the following example:

This code snippet corresponds to the GUI view below. Note that if Windows provides a default, the module will automatically fill it in, unless you define it yourself in the manifest.

GUI view corresponding to Puppet code shown above

Final Note

If you have global policies already set up, you can still use Puppet to validate and report on the state of your environment. By using Puppet’s “noop” (no operations) mode, you can have Puppet validate the settings and report back to you on whether any settings need to be fixed, and on which specific servers, or that in fact your entire environment is configured as you thought it was.

Either way, the next time your boss or security team asks you about the compliance state of your environment, you can hand them a report that shows it is in exactly the state you have defined — and even more important, that your infrastructure is set up to immediately reset and alert if those settings are tampered with.

Other useful modules

The Puppet Forge is full of great Windows modules, including:

Paul Cannon is practice manager for cloud computing at RiverMeadow Software.