Why read this post?

  • Find out how to run jobs in a limited user session with Admin privileges by creating a CentraStage Domain Admin user in Active Directory

The files mentioned in this post are available to download from here

Limited user permissions can be a pain when you want to run a job in the logged on user session but require Admin rights in order for it to work correctly. The default behaviour for CentraStage is to run all jobs in the Local System account which has full rights and permissions across all areas of the operating system. This is great and works for almost all of the things that you are likely to want to do with CentraStage. There are some notable exceptions however:

  • Running CCleaner for a logged on user account with access to all of the desired system files and locations
  • Installing the uVNC Mirror Driver (must be run in the user session with Admin rights to install correctly)

In the case of the uVNC Mirror Drivers this can be a major headache. The uVNC Mirror Drivers are important to get the best performance out of the CentraStage shared screen session functionality. More on this soon…

CentraStage allows you to specify to run the job in the user session (Advanced Options – Execution) in the scheduler. Here’s a screenshot to jog your memory:

With the options set as in the above screenshot, the job will wait indefinitely until a user with Admin rights logs on to the device and then execute the job in the user session. If your end users never log on with Admin credentials then your jobs will never be able to run.

The problem we have however is that you may have whole businesses over multiple sites and on separate domains that have all of their users logging in with limited user rights. Pretty sensible from an IT Management point of view but wreaks havoc with our plans of administering from a central location with CentraStage.

What we really want is to be able to use the following settings which will execute at any user login but have the elevated rights of an Admin:

There is a way to do this and it is up to you whether you see this as a good fit for your environment. The solution I suggest is to create a consistent Domain Admin user across all of your Domain Controllers that you can subsequently reference in CentraStage scripts. Using the LSRUNAS.exe command line tool will allow you to run commands within the user session but with the elevated rights of the Domain Admin previously created.

We’ll get to how you script this with CentraStage in a minute but first a little more on the strategy itself.

You may consider creating a Domain Admin user across all accounts a security risk but bear with me as I’m pretty sure you will agree that this is a non-issue after you hear what I have to say next.

By storing the Domain Admin username and password in CentraStage as account variables, they can be referenced in any scripts without having to ever store the usernames and passwords in the commands in plain text.


The Domain Admin username and password will never appear in plain text in any of the scripts that land on the remote device.


All CentraStage traffic is encrypted so there’s no chance of anyone sniffing packets as they are transferred around the network.

The last point to note is that you can make the password as strong as you like as it will only be entered once within the CSM and can be hidden from view. Go ahead and make them as crazily complicated as you want. You can even have a look over at https://www.grc.com/passwords.htm to come up with something that would be virtually impossible to type in even if you tried!

An example of the password that I got when I tried this site using the 63 random printable ASCII characters option was:


Certainly not something that anyone trying to log in with this user would be able to guess that’s for sure! According to http://howsecureismypassword.net/, this particular password would take a desktop PC “About 10 trestrigintillion years” to crack!

So the first step on this journey is to get these variables into the CSM (My Account – Settings – Variables)

These variables will now be available to call in any of your scripts using the following environment variables:



The variables will be available from jobs run across any profile as they have been set up at the account level. This really will be the last time you need to enter or even remember what that password is.

The next step is to run a Component against your desired Domain Controllers to add the Domain Admin user. This is easily accomplished using the DSADD command from the Local System account and doesn’t require you to know any existing passwords or anything else in order to do so.

The format of the command that I’m using is as follows:

DSADD USER “CN=%cs_admin_un%, CN=Users, %domain_info%” -samid %cs_admin_un% -desc “CentraStage DA” -pwd %cs_admin_pw% -disabled no -acctexpires never -pwdneverexpires yes -mustchpwd no -canchpwd no -memberof “CN=Domain Admins, CN=Users, %domain_info%”

That looks like some pretty brutal syntax right there! Breaking a long command line down with each switch per line can help readability in a situation like this:

DSADD USER “CN=%cs_admin_un%, CN=Users, %domain_info%”

-samid %cs_admin_un%

-desc “CentraStage DA”

-pwd %cs_admin_pw%

-disabled no

-acctexpires never

-pwdneverexpires yes

-mustchpwd no

-canchpwd no

-memberof “CN=Domain Admins, CN=Users, %domain_info%”

You should be able to see fairly easily how the command line works once broken down like this. I’ve specifically chosen to set the account to never expire, password to never expire and cannot change password. This is so that people can’t mess up the password settings and you won’t be faced with any on-going maintenance.

You’ll notice in the above command that there is a variable referenced called %domain_info% which we haven’t set anywhere within CentraStage just yet. This is because this piece of information changes with every domain and so I’m going to use a tiny snippet of VBScript in order to get the RootDSE in the Distinguished Name format. If not using variables to populate this information then the first part of the command would look something like this:

DSADD USER “CN=Username, CN=Users, DC=MyDomain, DC=com”

The elements here starting with DC are the bits that change every time so we can’t fix the information into the script or even use CentraStage profile variables very easily without a whole lot of messing about. So the easiest answer is to do this “on the fly” at run time. Check out this snippet of VBScript:

Set objRootDSE = GetObject("LDAP://rootDSE")

strDefaultNamingContext = objRootDSE.Get("defaultNamingContext")

WScript.Echo strDefaultNamingContext

All this does is read the RootDSE of the domain and fire it back out of the StdOut in the Distinguished Name format. Luckily we can use a simple batch command to call this piece of VBScript and read the output directly into a variable for use later on:

FOR /F “usebackq delims=” %%i IN (`CSCRIPT GetDomainDNC.vbs`) DO SET domain_info=%%i

The VBScript snippet is just saved in a file called GetDomainDNC.vbs and attached to the Component.

So enough explanation here’s the completed command in all its glory:


:: Force working directory to be current directory

PUSHD %~dp0

:: Run GetDomainDNC.vbs and read into %domain_info% variable

FOR /F "usebackq delims=" %%i IN (`CSCRIPT GetDomainDNC.vbs`) DO SET domain_info=%%i

:: Run DSADD USER command to add Domain Admin User

DSADD USER "CN=%cs_admin_un%, CN=Users, %domain_info%" -samid %cs_admin_un% -desc "CentraStage DA" -pwd %cs_admin_pw% -disabled no -acctexpires never -pwdneverexpires yes -mustchpwd no -canchpwd no -memberof "CN=Domain Admins, CN=Users, %domain_info%"

The flip side of this is when you want to remove the user in which case we would use the following very similar command just substituting the DSADD command for the much simpler DSRM command:


:: Force working directory to be current directory

PUSHD %~dp0

:: Run GetDomainDNC.vbs and read into %domain_info% variable

FOR /F "usebackq delims=" %%i IN (`CSCRIPT GetDomainDNC.vbs`) DO SET domain_info=%%i

:: Run DSRM command to remove Domain Admin User

DSRM "CN=%cs_admin_un%, CN=Users, %domain_info%" –noprompt

So that takes care of adding and removing our CentraStage Domain Admin user so next up is an example of how you can use this in a script via the LSRUNAS.exe mentioned earlier.

According to http://www.moernaut.com/default.aspx?item=lsrunas:

LSrunas can be used to run a command using another user account and passing the password as a parameter. This is a big improvement over the standard runas tool which is not able to accept a password. LSrunas can be used in scripts.

The LSRUNAS.exe command line tool is included in the .ZIP file that accompanies this blog post.

An example of a command that could be used to take advantage of this would be:


PUSHD %~dp0

SET command="CCleaner.exe /AUTO"

lsrunas /user:%cs_admin_un% /password:%cs_admin_pw% /domain:%cs_domain% /command:%command% /runpath:.

The %cs_admin_un% and %cs_admin_pw% variables are being pulled from the Account variables that were defined earlier. The eagle eyed among you will also see that there is a %cs_domain% variable in there too. This is a hidden CentraStage variable that is passed along with the job from the audit data for the device. This ensures that it will dynamically change the domain based on the device that is being targeted in the script.

Setting the %command% variable within the script allows you to put whatever command (or executable as in the example) you want to execute with the elevated credentials. If you want to execute a whole series of commands with these credentials then I would suggest attaching them contained within a batch file to the component and calling the batch file itself in a command.

Hopefully that’s not too much to digest in one go but it will be important in the next follow up post that will discuss problematic installations when strategizing a uVNC Mirror Driver rollout.

Just download the files from the beginning of the post and follow through one step at a time. I’m sure you’ll be fine!

Until next time…