In most places users are restricted from running things such as the command prompt or the Registry Editor. But in certain situations they sometimes might need to be allowed to do this. Take, for example, a situation I found when working with a local government client. They were migrating from MPS 4 to XenApp 6 and already had the migration scripts working when I joined the project.
As part of my work on the AppSense side of things I set up Application Manager with a default set of restrictions. This included blocking Registry editing by disallowing regedit.exe for the Everyone group. However, I clearly hadn’t done my homework properly, as very soon I started noticing in the AppSense Application Manager logs a load of Denied requests for regedit.exe. It turns out that users generating this were all in the process of migration and their migration process wasn’t finishing correctly, which wasn’t good news!
After a quick bit of investigation I found that the migration script was called from AppSense EM and was a VB script that called out to regedit.exe with the command line options set. This wasn’t a very elegant way of doing things, but the client was adamant that the migration script had been working and rewriting and retesting it mid-project wasn’t a very efficient way of getting past the problem. I had to agree, but I needed to find a way to allow regedit.exe to run for certain users in certain situations.
The first idea I had was simply to allow regedit.exe for an AD group, add all the non-migrated users to it, and then set up a logoff script to remove the user from the group. This seemed a bit complex as it involved some custom scripting at logoff and also changing the default permissions on the AD group to allow users to remove themselves from it. Whilst it could be done this way, I couldn’t help thinking there must be an easier way to do it. When you are putting solutions together that you won’t be supporting long-term, it’s always better to do it the simplest way possible!
The answer lay in AppSense Application Manager’s process rules. You can create a rule based around a particular process, and then allow or deny other executables if they are called from the parent process. Notice that by default a process rule exists for Windows Installer (msiexec.exe) that allows *.exe and *.dll, so that the installer process is unaffected by any applicable rules.
Right-click on the Process tab in the AM Console and choose Add Process Rule. It is created with a default name, so you’ll need to right-click the rule and choose Rename to give it an intuitive title. You’ll also need to choose a Security Level. You should by now be familiar with using Restricted as much as possible!
Next right-click in the Processes window and choose Add | File. You can base it around the digital signature of an executable rather than the file path if you want to be more exact (or more secure).
Now we need to add the process that will be calling out to regedit.exe. In this case it’s a VBScript which is run from wscript.exe. However, it could just as easily have been done through the command-line windows script host (cscript.exe) or even the old-fashioned command line itself (in which case we’d use %comspec%). Browse to your required executable or type the command line in if you know it (ideally, using environment variables where possible to ensure cross-platform compatibility)
Now we’ve defined the Process, we simply need to allow or deny executables in the sections underneath the rule. I’m sure you’re familiar with this. In this case, we will add an Accessible Item which allows regedit.exe to execute
and then we’ll save and deploy the configuration. Now, when the Windows Script Host calls out to run regedit.exe, it will allow the program to run.
It’s interesting to note that this migration script was run from Environment Manager during logon. The default Application Manager options (which I had not changed) are meant to ignore restrictions during logon…
….which means I could have defined wscript.exe as a Prohibited Item for the Everyone group and the migration script should still have run (which is good practice really, doing it this way prevents users from exploiting this rule by writing their own scripts!). However, it seems that even though the script itself was allowed to run, the call to an external program was not recognized as part of the logon process and was therefore denied by Application Manager until this Process Rule was put into place. There’s probably a good reason for this, otherwise a call to a rogue executable inserted into the logon process somewhere would circumvent the Application Manager security.
Share
