Thursday, March 8, 2012

A "Privileged Event"

Today one of our .NET developers came to me with an interesting issue.  He was trying to debug an issue with one of his web services by writing to the Windows Application Event Log.  Unfortunately the event was only being written on one of two IIS servers, so I dove in to take a look.

Obviously something was different between the two servers, but what was it?  My first thought was to check permissions of the Application Pools, so after a quick check of the virtual folder properties, I was looking at the Identity tab of the responsible pool.  Here is a screenshot of what I saw on the first box with identifiable traits redacted to protect the guilty:

Upon seeing that this AppPool was running as "Local System", my eyes bugged out of my head a bit.  If you are not aware of the Predefined users available in this drop down box, here is a quick synopsis from Microsoft TechNet:
"By default, application pools operate under the Network Service account, which has low-level user access rights. That is, this account provides better security against attackers or malicious users who might attempt to take over the computer on which the World Wide Web Publishing Service (WWW service) is running. The LocalService account also has low-level user access rights, which is helpful for situations that do not require access to resources on remote computers. You can configure application pools to run as LocalSystem, which is an account with more user rights than the Network Service or LocalService account. However, be mindful that running an application pool under an account with increased user rights presents a high security risk."  -
In other words, an AppPool run as "Local System" is a bad idea.  That being said, this was naturally the box where the event log entry was working.  Too bad it took a sledgehammer to do it! *

Moving over to the other server, the Predefined drop drown was set to the default "Network Service".  I could have just switched it to "Local System" and called it a day, but we already established that wasn't a good idea.  The question now was, how could we make this work while leaving it set to "Network Service"?

After researching (aka Google-Fu) a bit, I ran across a question on Stack Overflow that covered a similar situation.  The answer provided by DOK referenced the following quote from Microsoft MSDN:
"Least privileged accounts have sufficient permissions to be able to write records to the event log by using existing event sources. However, they do not have sufficient permissions to create new event sources." -
This helpful information pointed me in the right direction.  From previous experience, I already knew the location where Windows stores the event source names.  If you fire up RegEdit, you will find them all listed in the following location: "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog".  Under this key are keys for each class of event log and under them their respective event sources.

The issue was resolved by manually adding the key under the Application key.  This was a great solution because we did not have to change the "broken" server from "Network Service".  In reality, the server wasn't broken at all and it can be argued that the server that was "working" initially was actually broken.  It has since been switched to "Network Service" as well.

And now it is time for the moral of the story if it hasn't hit home yet-- always follow a policy of least privilege.  There have been so many times I have encountered people who practically give away the keys to the castle in order to get a program working.  Don't take the easy way out.  Do a little troubleshooting.  Identify the root cause of the issue.  Compromising security is not worth the risk.

* This particular server is running IIS 6, so the quoted TechNet article is specific to that version.  As of IIS 7 there is now an additional option for "ApplicationPoolIdentity".  This user is unique to the specific AppPool rather than being a shared account like the other options.  This is inherently more secure and is thus the default and recommended option.

Friday, March 2, 2012

AnyConnect for Android 4.0

One of the largest complaints levied against Android is the fragmentation among devices.  One of the most glaring examples affecting enterprise adoption has been the limited availability of an official client for Cisco VPN solutions.  Cisco has stated that that the problem results from a lack of a robust VPN API in Android.

Starting in Q3 2011, beta versions of the Cisco AnyConnect client started to hit the Android Market-- unfortunately only for rooted devices   While this may not present an issue for those of us in IT, we all know what a support (and compliance!) nightmare it would be sending users out into the wild with a rooted device.  Shortly afterward, support devices manufactured by Samsung, HTC, and Lenovo.   This still left many devices out in the cold and no clear direction for future support.

With the release of Android 4.0 Ice Cream Sandwich (ICS), Google touted a new VPN client API to help mitigate the situation.  Here is a link to the platform highlights and a quote:
"Developers can now build or extend their own VPN solutions on the platform using a new VPN API and underlying secure credential storage. With user permission, applications can configure addresses and routing rules, process outgoing and incoming packets, and establish secure tunnels to a remote server. Enterprises can also take advantage of a standard VPN client built into the platform that provides access to L2TP and IPSec protocols."
Google took care of their end of the equation, but an AnyConnect client from Cisco was still outstanding-- until February 27th 2012.

Under the name AnyConnect ICS you will find the long awaited client.  While there a limited number of devices currently updated to ICS, most devices released in 2011 are scheduled to be updated within the coming months.  I can personally vouch for the functionality of the client with the Motorola Xoom and the Samsung Galaxy Nexus even though it is still labeled a preview release.

The coming months will be interesting.  Will the availability of an AnyConnect client that works across all OEMs be able to help Android penetrate more enterprise customers?  It is certainly a step in the right direction for the platform.

As a parting question, are there any business critical apps that you feel are missing from Android 4.0?  I would be interested to hear from you in the comments.

QR-Code link to AnyConnect ICS in Android Market