Inside Development : AutoMate and Windows Vista Security

by Scott Robinet, in Inside Development, posted 10/24/06

Microsoft's latest operating system, Windows Vista, is almost complete and nearing release (as of this writing, Vista is slated to be released to large corporate customers under an OEM license in November and the general public in January 2007). Vista promises to improve the user experience by enhancing the graphic user interface and increasing overall system security.

Network Automation has been assessing and working with Windows Vista since the first beta became available to see how this radically new operating system would affect AutoMate and IT automation tools in general. It quickly became apparent during initial testing that changes would be required to ensure AutoMate would work correctly on a typical Windows Vista configuration. In this installment of Inside Development, I'm going to discuss some of the problems we encountered and our solutions to them.

But before I do, I'd like to let everyone know that Network Automation will fully support AutoMate 6 and AutoMate 7 on all editions of Windows Vista. An update will be made available for AutoMate 6 shortly after the release of Windows Vista that will address the compatibility issues that are currently present in the product. And AutoMate 7 has been developed from the beginning for Windows Vista certification. Also, I should point out that this article is based on our testing and debugging builds running on Windows Vista RC1 and RC2.

Windows Vista is certainly a pretty operating system to look at, and it is clear from the first moment you start it that improved security was a high priority. This added security, however, comes at a cost as far as automation tools are concerned. The rules of the game changes somewhat, and solutions to the problems we encountered while testing AutoMate required some novel solutions at times. Aside from introducing a new, sleeker graphical user interface, the operating system has made several long strides to "locking down" systems out-of-the-box to make them harder to hack and compromise by viruses, malware and inadvertent changes to the system by unsuspecting users. Two of the most important and noticeable of these changes is the introduction of Windows User Account Control (UAC) and Windows Defender.

User Account Control (UAC) and AutoMate
UAC is a new security feature that treats all users (even Administrators or those users in the Administrator group) as standard users. In other words, a user may be an administrator, but the user is not immediately treated as such. This means that even if the user is a member of the Administrators group, he can't run about making changes to the system unless he first passes interacts with UAC. UAC acts like a gatekeeper, preventing access to privileged parts of the operating system unless the user specifically says it is acceptable to do so.

This directly affects AutoMate and most other automation utilities that were built on the assumption that a user that is part of the administrator group always has administrator rights just by authenticating themselves during logon. But in Vista this is not the case, because all users are assumed to be standard users until they are "elevated" into their administrator rights. In essence, being an administrator in Vista gives you the "right" to be elevated to an administrator, but doesn't do so upon logon.

When an application starts, it inherits the rights of the user executing the application. Because of this, applications are granted standard access by default, and tasks started by AutoMate (either triggered by the Task Service, run manually from the Task Administrator or while debugging in the Task Builder) will be forced into this restricted account, regardless of whether or not the logged on user has administrator rights. This causes AutoMate steps that require elevated rights (such as Start Service) to fail with an "Access Denied" error. Additionally, certain parts of the file system (such as the Program Files directory and the system root) are off limits to write access (no more writing debug files onto your root C:\ folder!). What is needed is a way to inform Vista that certain applications will require administrator rights to work properly, while would allowallowing the restricted administrator user to be elevated to it's full rights when the application starts. Vista provides a means to do this, but when it is invoked, AutoMate can be stymied again.

The UAC Prompt
Marking an application to "Run As Administrator" (or right-clicking on an application and choosing "Run As Administrator") will attempt to launch the application with the rights of an administrator. But doing so causes the entire desktop to gray and a modal dialog to appear, requiring the user to acknowledge that the elevation is acceptable to take place. This secure desktop blocks all other applications from working until the prompt is acknowleged. If the user allows the elevation, the application is started with administrator rights.

If the user blocks the elevation, the application is started as if the "Run As Administrator" option was not provided. Either way, for an automation tool such as AutoMate, this is not desired behavior. Imagine a user having to be in front of the computer each time a task is triggered, even if it occurs at 3AM! What is required is another way to elevate the user to their highest set of rights without prompting interactively. In a way, we need to automate UAC.

AutoMate Task Service To The Rescue
User Account Control isn't really the voodoo it may appear to be on the surface. In fact, the concept centers around a higher authority granting permission for a restricted user to shed their shackles and regain their ultimate privileges.

When an application is running on the interactive desktop, the higher authority is the user at the workstation. When an application that requires administrator privileges is started by a standard user (or a restricted administrator user), UAC will inform the user at the console that an elevation is necessary and ask for permission to proceed with the elevation. But this "higher authority" doesn't always have to be a human user. In fact, it only has to be an entity that has already been granted equal or higher privileges than what the child process requires. In our case, the AutoMate Task Service fits the bill perfectly.

Because the Task Service runs in the context of LocalSystem (a special account used exclusively by services that require administrator rights), AutoMate has the ability to elevate users to their highest allowable level. This is because AutoMate cleared the UAC provisions during the elevated installation of the software (in other words, the UAC prompt is shown during AutoMate's installation, at which point the Task Service is installed with the LocalSystem account).

Unfortunately, like most things in life, the solution isn't as easy at it may seem on the surface. Current versions of AutoMate 6 use the AutoMate Event Monitor to launch tasks in the context of the currently logged on user. This allows tasks to run as whatever user is logged onto the workstation at the time the task is run. But services typically cannot interact with a desktop because the service lives outside the Explorer shell (although there is a way around this: a service can be set to allow desktop interaction by enabling an option in the Service Control Manager, but doing so prevents other secure operations from being available to AutoMate, such as unlocking a locked workstation).

Not to fear, though. New versions of AutoMate will take advantage of new functionality provided in Windows Vista to allow tasks started by the Task Service to run not only on the currently logged on user's active desktop, but also onto the desktops of other users that may be logged onto the workstation as a result of Vista's Fast User Switching.

Windows Defender
The other change in Vista that directly affects current AutoMate installations is the roll-out of Windows Defender. Windows Defender is a Microsoft application that attempts to prevent unauthorized changes and access to a system by malicious software. It also restricts certain applications from performing actions that once went unchecked. For example, Windows Defender will prevent applications that require administrator privileges from running automatically at startup (either because the application is in the Startup menu or in the registry's Run key). In this way, malware and viruses cannot surreptitiously install themselves on a user's system and mark the Windows Registry to run the malicious software on startup in order to, for example, open a TCP/IP port to "phone home" to a hacker's machine.

The AutoMate Event Monitor is set to run on system startup so that tasks can be launched when a user logs on without them having to manually start the monitor. As a matter of convenience, it also checks if the AutoMate Task Service has been started, and if not, attempts to restart it (provided it hasn't been set to a "Disabled" state). In Windows Vista, however, this querying of services is an administrative action that requires elevated privileges.

When the AMEM attempts to perform these actions, it is denied access to do so because UAC will not allow it. Marking the AMEM to "Run As Administrator" has it's own problem as discussed before: when starting the AMEM manually, UAC displays a prompt, and when run on startup, Windows Defender flat-out prevents AMEM from starting at all until the user opens the Windows Defender application and allows it to run!

To prevent this, we've removed the service check when running on Vista. Because the AutoMate Task Service is set to run automatically on startup by default, there should be few occasions when the AMEM would need to start the Task Service. And in such cases when the Task Service cannot be contacted because it is not running, the AMEM will inform the user with a balloon tip so they can start the Task Service manually if they so wish.

Conclusion
Windows Vista is an exciting and bold new operating system from Microsoft. Network Automation is committed to supporting customers who intend to install and use AutoMate on Vista, and we'll continue to do our best to ensure maximum compatibility going forward. We'll continue next month with another status update on our progress to this end.

Thanks for using AutoMate!