Centralized Management of Java SE Environment Using GPO (Redux)

My Adventures helping a friend secure his Java environment where fun, in my original blog post I used GPO to reduce the risk in his environment by crudely pushing  a configuration file to his environment. After 24 hours the fun started because we got insight from the support team, developer and users and came with a game plan.

The requirements:

• Solution must provide the ability to configure Java 7 and Java 6.
• Users must still be able to look at the settings in the Java control panel so they can relay information to helpdesk for troubleshooting.
• The configuration files must be in a place where the can be replicated to Domain Controllers in other locations.
• Solution must work on Windows Versions 5.x and 6.x
• Policy Should only apply and create the files for machines with Java installed.
• Policy should be robust enough to adapt is Java 6 or 7 are installed on the target in the case a computer is moved from one OU (Organizational Unit) to another.

Thankfully we worked and came with a much simple and easier to manage solution that made everyone happy (And me never volunteering to help).

Creating WMI Filter

When it comes to applying Group Policy Objects I find that WMI filters is one of the best ways to determining to what machines to apply a policy and to witch not. We start by creating 2 WMI filters one for Java 6 and another for Java 7. We first go in to Group Policy Management Console, and go in to WMI Filters:

We Right-Click on it and select New

We give it a name of Java SE 7 is Installed and a description of “For Policies that will only apply for hosts running Java SE 7” and we Click on Add to include our WMI WQL Query and we add the query

Select * From win32_Directory where (name="c:\\Program Files\\Java\\jre7" or name="c:\\Program Files (x86)\\Java\\jre7")

This WMI Query will look for bot X64 and X86 locations of the JRE7 Folder on the System and if found it will apply the policy.

We click on Save to save the query.

We would do the same for Java SE 6 if we want to cover it.

Creating Policy Files

Next we create policy files for Java in our domains \\FQDN\SYSVOL\FQDN\JavaPolicy folder where FQDN is the full path of your domain name. In my example I will create to folders one called JRE7Strict that will have restrictive settings and another called JRE7Block that will have the files to block Java on all web browsers.:

In Jave SE a deployment.config file is used for specifying the System-Level deployment.properties for use by all users of the system and it is located in %windir%\Sun\Java\Deployment\deployment.config. By default no deployment.config  or folder structure exists. The deployment.config file needs the option of deployment.system.config and it can point to a URL(HTTP or HTTPS) or a File Path that points to the deployment.properties to load, to ensure that the properties file in the user %APDATA% location is not loaded we set the deployment.system.config.mandatory option with a value of true. Our config file for the restricted settings would be:

deployment.system.config=file\://acmelabs.com/SYSVOL/acmelabs.com/JavaPolicy/JRE7Strict/deployment.properties
deployment.system.config.mandatory=true

and we would place the file in the JRE7Strict folder and we would create our Properties file with the options we want and to lock the options so they still show in the control panel but would be greyed out so they can not be modified we would also add a <property>.locked line. A sample restricted properties file would look like:

deployment.security.level=VERY_HIGH
deployment.security.level.locked
deployment.security.askgrantdialog.notinca=false
deployment.security.askgrantdialog.notinca.locked
deployment.security.notinca.warning=true
deployment.security.notinca.warning.locked

In the example I set the Security Level to Very High and locked it as well as other options.

Update: for more information on the security levels and what they restrict take a look at http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/client-security.html Remember security levels where added in version 7 Update 10. The only whitelisting available is for sites that use signed Java Applets, those that do not will be blocked by the Very High security level, if you need access to unsigned Java Applets and are not able to sign and create a whitelist of signed ones set the setting to High and educate your users or Restrict them to Internet Explorer only and set security zones and settings per zone and site http://blogs.msdn.com/b/ieinternals/archive/2011/05/15/controlling-java-in-internet-explorer.aspx?Redirected=true.

As domain admins we would save the files in the folder:

for a policy that would block Java on all the web browser we would only add to the properties file:

deployment.webjava.enabled=false
deployment.webjava.enabled.locked

Creating the Policy

The use of the centralized files it makes creating a policy file it is more simple. We just create a new GPO and we start by setting the creation of the folder where the config file will be placed so in the Policy we would go in to Computer Configuration –> Preferences –> Windows Settings –> Folders:

 

We create a new entry for the creation of the folder %WinDir%\Sun\Java\Deployment

Now we can create an entry for copying the config file to the folde we go to Computer Configuration –> Preferences –> Windows Settings –> Files:

We now create a new file policy and set it to replace so updating only takes modifying the file it self we set  the Action to Replace so when the file is updated it will be sent to all the machines in the domain when they update their policy, we set the Source to  \\FQDN\SYSVOL\FQDN\JavaPolicy\JRE7Strict\deployment.config and the Destination to %windir%\Sun\Java\Deployment\deployment.config:

Before we link the policy to any OU we must set the WMI filter we created so it will only create the folder and file on machines running the correct version of JRE

Once it is done we can link it to the OU we want the policy to apply to. Once a hosts update it’s policy via schedule or it is forced.

If you are running a Windows 2012 DC I recommend you go in to the Starter GPO’s and have the 2012 DC create them if they have not yet, if they have been already created and they where in a Windows 2008 or Windows 2008 R2 back the Starter GPOs, Delete the starter GPO folder from \\FQDN\SYSVOL\FQDN\, go back to the Group Policy Management Console on Windows 2012 and have it generate them, you should have 2 additional GPO templates for Firewall and Management configuration. From PowerShell (Had to sneak some PowerShell in ) run:

New-GPO –Name "Configure firewall rules for remote gpupdate" –StarterGpoName "Group Policy Remote Update Firewall Ports" | New-GPLink –target "dc=acmelabs,dc=com" –LinkEnabled yes 

This will create a New Group Policy and link it to the Domain (Make sure you modify the DC values to the ones of your domain) that will allow you to force GPO updates against the host in the domain once the policy is applied.

To force a update of the policy from your Windows 2012 DC run Invoke-GPUpdate against the machines you want to update, in this example I’m running it against the HR OU where my test VM’s are in my lab:

  Get-ADComputer –filter * -Searchbase "ou=HR, dc=acmelabs,dc=com" | foreach{ Invoke-GPUpdate –computer $_.name -force} 

Once the policy has been updated we can just open the Java Control Panel and confirm the options have been set and that they are greyed out.

If the user tries to load a self-signed applet or one not in your trusted signature file he will get:

If the Applet is validly signed he will get a popup giving him a warning and allowing him to run run the applet:

This method can be used to set other policies like the path for the trusted signatures and PKI files plus settings. So make sure your applets are properly signed with valid certificate and modify your trusted CA file to only trust your vendor to reduce the risk of the attacker using a valid provider or even better use your own CA and signed your applets with your own cert.

For Java 7 properties reference use http://docs.oracle.com/javase/7/docs/technotes/guides/deployment/deployment-guide/properties.html

For Java 6 properties reference use http://docs.oracle.com/javase/6/docs/technotes/guides/deployment/deployment-guide/properties.html

Hope you find this useful and allow you to secure your Java environment in Windows.

Comments

[Matt]

This is a great write up. Thanks for it.

Since VERY_HIGH automatically disables the use of self-signed certificates/certificate pinning, it might be worth mentioning that you can add a certificate check to the trusted keystore. In fact, the process made me realize that keystore access is password controlled, and has a default password for all installations ("changeit"). It might also be wise to change this so that popped machine's can't get their main keystore modified.

I heavily cited a Windows Azure write up, and wrote a blog post to try to streamline the process of certificate addition and keystore password reset: http://mbrownnyc.wordpress.com/2013/01/14/add-a-self-signed-certificate-to-the-jre-certificate-store/

Thanks again!

Matt

[Carlos Perez]

Yep I do mention the use of the trusted CA store and that ir can be deployed in the same method, in fact that is what we did with the exception of changing the password to the store. We had on machine outside of the environment where we added all the trusted signatures and then we deployed the file from the GPO placing it in the SYSVOL also.

[Farhanible]

Is there a way to install the JRE7Block policy and have exceptions (whitelists) for internal and external business applications?

[Carlos Perez]

On the block all web browsers are blocked, you can whitelist by adding the applet signatures in to a trustedca file and pushing the file

[Kevin]

Is there any way to leverage this to whitelist certain websites? I'd like to lock down Java to only the users that need it, and then only for URL's submitted & approved by IS...

I have sort-of been able to do that at our network edge but not at the host for when leave our network.

Thanks & great article.

- Kevim

[Kevin]

Apparently the same comments were submitted while I was reading the article.... :)

Thanks.

- Kevin

[Kevin]

Is there any way you can go into some more depth into the whitelist by adding the applet signature to the trustedca file?

Thank you for the great article.

[Leon Krown]

I would also be interested in learning more about whitelisting known applets whether signed or not while still maintaining the very high level being set if possible.

[Aaron Giuoco]

Thanks for the write up. It's really cool.

One thing I noticed about this process is that computers not connected to the corporate network appear to loose all settings in the deployment.properties file. Because deployment.config points to an internal network location and the machine can't reach it, the settings don't apply. This could be a problem for laptop users.

What I did was configure the GPO to copy the deployment.properties file into the Deployment folder along with the deployment.config file. The deployment.config file points to "%windir%\Sun\Java\Deployment\deployment.properties" rather than the central location.

[Carlos Perez]

You can only whitelist signed applets and in that you would whitelist the signer more than the individual one

[Sven]

Ci Carlos

Nice article and you put me on the right direction. I did the same without WMI filtering, I used the ILT filtering instead. Since we are only using the GPP I decided to give it a try. The reason why I did it without the WMI Filter was the hardcoded path you used in the filter. If I did not hardcode the path some of our very old clients would have run into problems because it would have searched on the hdd.
Dou you know any possibility to use environment variables in the WMI Filter? (e.g. %programfiles%)

[Carlos Perez]

They is something I have experimented with with no success. Looking at using WMI search feature and playing with it this week to see if I can use CIM_file class to archive it

[Seth @ FBT]

Thanks a lot Carlos. This sure is a simple solution to manage Java SE Environment.

[rick]

Is centralized updating of Java something within the realm of possibility without purchasing extra software? I don't mean actually pushing out the updates necessarily, but some way of triggering a PC to check for an update, and if found, install it silently. It's the silently part that's sadly deficient now, as any office worker being nagged by Java's update checker knows all too well.

[Carlos Perez]

Youtube can use Group Policy Software publishing to push to only those machines you want, next time they reboot they should get the update, it is prone to errors in some cases. If you have wsus using it with http://localupdatepubl.sourceforge.net/ tends to be more reliable

[Jeff Hayes]

Quick question,

I don't believe its explicitly stated but did you have to create the JavaPolicy folder under \\FQDN\SYSVOL\FQDN\ or was it there already? Just curious, as in ours, it is not there currently.

Sincerely,

Jeff Hayes