I'm writing a perl script for a website, and I need to be able to control VirtualBox via the website. I'm not sure where to start, or if I'm even trying to debug in the right area, but here goes.
My server is running IIS7 on Windows Server 2008 R2. I'm also running 2 virtual machines through the vboxmanage command line interface. These VMs are running under SERVER\administrator.
When I open my website, it requests a login. I login to the website as SERVER\administrator and click a link that calls my script using an xmlhttprequest. Now, normally, it doesn't matter what user I run these as, but with vboxmanage, if I run the command as a different user, the list of VMs is different. I tried whoami, which returned SERVER\administrator, but %DOMAINNAME%\%USERNAME% returns the domain that the server is connected to as dommainname and SERVER$ as the username. The vboxmanage command then fails.
On the website, impersonation is turned on. When I turn impersonation off, the whoami request changes to be iis apppool\website. Any ideas on how to get around this?
As a final note, I've thought about using runas, but since it prompts for a password, there's no way to call it through scripting (and that would be a poor security decision, I'd imagine).
This is an oft recurring, well-known and well-solved problem. Instead of having one big program dealing with requests from the Web and managing the VM (strong coupling), separate the concern and write two programs, each doing exactly one task.
The user facing program running in the Web server context can continue with limited privileges. The VM manager is a stand-alone program running with the necessary admin privileges, either repeatedly from the scheduler or as daemon/service.
Have the first communicate with the second over a message-queue.
Related
I have a bunch of PowerShell scripts that call out to external programs to perform certain actions (no choice about this). I'm trying to find a way to allow users to connect to a constrained remote session using delegation to run these scripts (and the external binaries) as a privileged account, WITHOUT the user being able to execute the binaries with the privileged account.
I've found that if I constrain the endpoint using NoLanguage and RestrictedRemoteSession, or using a startup script to remove access to those parts of the system that it breaks the scripts because they're no longer able to execute the binaries.
Is there any possibility of making this work, or will I have to rewrite my existing scripts as DLL cmdlets which could then make the calls to the external binaries (or write just a proxy command in a DLL to make the calls)?
Create scheduled tasks without a trigger, configure them to run as a privileged user, and have your restricted users start them from the Task Scheduler.
You are looking for JEA or Just Enough Admin. It does exactly what you are trying to do with restricted endpoints.
http://blogs.technet.com/b/privatecloud/archive/2014/05/14/just-enough-administration-step-by-step.aspx
Start with the video. Jeffery Snover may give you the details needed to make your solution work as he explains step by step how JEA was built.
I am looking to collect data snapshot on a random interval from various machines in our network that we don't own, but may get access to install an agent to collect these data.
These machines are either in a domain or work-group and kind of data i get are based on the role they play and information they have. The machines are "Windows Server 2003" and above and I do not want to install anything on those machines before i get started, so thought I can use the PowerShell scripts that I can remote invoke form my server and pass the script it has to run to return the data.
I was wondering if this is possible to do that with the PowerShell scripts and as this is supposed to run in a secure environment, is there any major security implications with this approach. i.e. do I need to do anything on the client machines that can make them vulnerable to security threats.
BTW these machines are not exposed to internet and are behind a firewall.
I would appreciate if you point me to any other alternatives that can be useful for my analysis.
Regards
Kiran
Hello Folks,
I have a powershell MTA (GUI script using winForms), which works well, lets take the script name to be "ENDUserMTA.ps1" which does invoke certain commands and does something which really needs admin rights. this works fine when run manually or via task scheduler or when set via [registry] RunOnce or Run or whatever when there is admin rights..
The problem is i want to invoke this script on the END users laptop and make them to work with it [interactively]
Options that i have tried so far:
Tried Scheduling the "ENDUserMTA.ps1" in Task Manager SYSTEM account [using When running the task, use the following user account] - this starts and run NOT INTERACTIVE [since system account does not have interactive session]
Tried Scheduling the "ENDUserMTA.ps1" in Task Manager with Different user account which has admin rights [using When running the task, use the following user account] - This again starts but the GUI is not shown to the End User who has logged without admin rights, rather shown to only the user who was set under the option [When running the task, use the following user account]
My situation is not possible to create PSSessions or Delegated Remoting. I am now is middle of forest and no where to go!!!
Not sure how to invoke the script as admin to a user who has logged into a machine without admin rights..
WHat i exactly need or similar solution: When scheduling this script, i schedule the script to start atlogon[any user], after the script completes it will delete the scheduled task
Pls help..
Balaji
Begining on Vista Microsoft has started to separate UI stacks for security reasons.
My advise for your problem is to change the architecture of your code in order to create two scripts.
The first one with no UI will be scheduled with administrative rights
The second one with UI will be started with the user rights and will be a client of the first one.
You can use Inter-Process Communication between the two scripts, but you will met a security issue, you server part vill need particular ACLs to allow the client part to connect.
It exists other way to communicate between scripts, but it's not so easy with an asynchronous UI architecture on one side. It would be simple using managed code (.NET code) or native code(unmanaged code). For me, you are on the limit of the scripting place even if scripting capacities are very large as far as PowerShell is built on the top of .NET.
I am working on an automated deployment process for a web application. The deployment will need to:
Deploy DB changes to database using sqlpackage.exe
Deploy reporting services reports to the reports server using the web service
Deploy web app to web server(s)
Deploy fonts for reports
among other things
The first two are reasonably straightforward to run from the web server, as the web service and db are contactable, and the tools to deploy run over the network.
From reading it appears that powershell remoting should be the way to go, and internally this would not be a problem. However when deploying to production, this will be being carried out in a datacentre, where the machines (2web, 1db) are not on a domain at all. I'd like to come up with a generic process that can run both internally and externally with the appropriate configuration. Powershell remoting, with machines not in a domain appears to require a fair bit of configuration using https etc., as NT credentials can't be validated.
Should I battle out configuring powershell remoting, or would configuring this to just use psexec to execute a powershell script directly on the remote machien, copying the deployment artifacts to a drop folder on the remote machine be the best way to go?
psexec seems to "just work". It appears powershell remoting comes with a lot more pain.
Why not use psexec then? You can restrict it's role to just getting you on to the remote machine, and not let it infect your scripts. I have not attempted to get ps remoting working on a non-domain, but it general I have found it to be fairly high effort to get going. Psexec, as you say, can often be simpler.
Excuse the peddling, but the open source framework I helped build called PowerUp essentially does all this for your. It uses a model in which the powershell (well psake) scripts can move execution to another machine by calling a specific function. This can either be done with powershell remoting or psexec - you wouldn't need to change the script, it just requires a setting per environment to say which you would like to use.
Check other the sample at https://github.com/AffinityID/PowerUpSamples/tree/master/SimpleWebsite.
Hopefully that shows you enough, but if not let me know and we can go into more detail.
I am DBA. I am trying to write bunch of scripts that I could execute from one central server. Ideal would be to send all the scripts from central server to say 50+ servers across multiple win domains (for databases management purposes).
The problem I am running into is - security. Seems like PowerShell Remoting is the way to go. But when I send a script to another server, I get 'not digitally signed' error.
I could 'self sign'. But that cert if only trusted on local machine. So that option is out.
Maybe Certificate Authority is a way to go. Or adding trusted hosts. I just have no clue on this one, so if you know any blog posts or how to do this - it would be big help.
Well, it's a security risk, but there's always the possibility of setting the execution policy to RemoteSigned, keeping a local repository on each server and calling those as needed via PS-Remoting. I don't like that idea one bit though.
If you are doing remote execution, you will need to sign your scripts. A detailed step by step can be found here. It even covers deploying the cert via GPO so that it's domain trusted.
I would use PowerShell remoting. This would allow you to run it as remote commands instead of remote scripts. If you catch the bottom of this SimpleTalk article, after "Persistent Sessions". It shows the option of executing a set of commands against each server instead of the script. This should prevent having to deal with the remote signed issue and provide a little more control.
The only thing to deal with on remote sessions is your credentials. I have not tried this on multiple domains but a few stand-alone servers.