I need to programmatically create a new Windows account for running a Windows service I recently developed.
Due to lack of sufficient privileges I cannot use any of the existing service accounts (LocalService, NetworkService and LocalSystem), so I have to create my own account during installation of my service.
Unfortunately, I have no idea on how to accomplish this from code (C#). However, I know that the steps I have to go through include:
Create the account
Deny account log on via console
Grant log on as a service.
Add the account to the local administrators group on the PC
My service must install and run on all Windows PC operating systems ranging from Windows XP SP3 and up.
Question: Which command line tools are available for this purpose (I can very well call those command line tools from code)?
Further, any relevant links, code snippets or scripts will be very much appreciated!
If you just want a single command you can probably do:
net user /ADD "newuser" "Pass phrase" /passwordchg:no
However I looked into 'grant logon as a service' in the past, and had to download an additional .exe from a Windows Server Resource Pack to do this. That may be a pain as you'll need to redistribute the .exe.
Unless someone suggests a better way which uses only built in .exes I'd try and do this with one of:
Powershell
VBscript
Related
We are writing an installer for our Windows tool. As our tool uses an updater (wyUpdate) and we want that users WITHOUT Administator rights can performs updates. Which is the right directory to install the app to? The standard C:\Program Files requires Administrator rights, so we have discarded this option. After reading a bit on the Web, we have chosen AppData, i.e. C:\Users\USERNAME\AppData\Local.
Is this best practice? Or should we use another directory?
If you do not want to allow your users to mess with the installed program, you have to install it to a folder that needs Administrator privileges.
To allow an automatic update of such application, you need to develop/install a service that runs with Administrator privileges, which will update the installation. This is what Windows Update, Mozilla Maintenance Service, Google Chrome Elevation Service, Adobe Acrobat Update Service and similar services do.
If you do not want to implement a service, but you want the application to be used by all users of the machine, you need to install it to a folder that can be accessed by all users, yet does not need Administrator privileges. You can for example use C:\Users\Public. See also Is there a shared folder in Windows to which non-elevated users have write access?. You can use PUBLIC environment variable to resolve that path.
If the application is to be used by one user only, then you are ok with using C:\Users\Username\AppData\Local – {userappdata} in Inno Setup.
Related question: Deploying application with .NET framework without admin privileges
Many Windows programs are able to run an update when they start, without an admin prompt. Similarly, my program needs to update itself, without any user input. Any user who logs in needs to be able to use the program.
My program can already find new updates, download them, and run them, but the NSIS installer/updater requires admin rights.
What would I need to do to implement this using Free Pascal and NSIS, short of giving all users access to the installation directory?
Is your application that important that you need to do this? How often do you actually plan to push out updates?
Most applications can probably get away with just elevating with UAC each time it needs to install a update.
If you absolutely feel that you need to "bypass UAC" then you can do what Firefox does; install a NT Service. You don't start this service in the installer but you must call GetNamedSecurityInfo+SetNamedSecurityInfo so you can add SERVICE_START access for the Everyone group to the ACL. Your application running as a normal user can then start this service when there is an update and the service does the updating.
From a security standpoint there are some dangers here because the service runs with full access to the system so you must make sure that your updates are signed so it does not become an easy to use backdoor if someone is able to pull off a man in the middle attack.
I personally think that you should consider doing per-user installations if your program is not too big...
Looking for suggestions on how to go about the following, i.e what would be the best language to do it in etc, third party tools are a no :(
I've been tasked to create some sort of windows shell/command line interface that will allow a standard users to install a specific set of applications (configurable by administrators) (installation requires Admin/UAC elevation) due to security restrictions the user cannot have elevated privileges so they'll be able to run the shell as a standard user and it would have hidden/encrypted credentials built in to run the installs as.
Some of the requirements are as follows:
It would need to work on Server 2008 R2, 2012 r1 and 2012 r2
The credentials used to perform the install would have to be hidden (encrypted) from the end user.
Ideally it could work by us providing some config to it prior to handing that server over to the customer and limit what it could be used to install to a particular .exe or .msi (so we know of a need to install an app, we are advised of the name of the install and can logon and can enter it into a form maybe so only that app can be installed, then hand the server over to the customer who runs the same utility or shell extension or whatever and can then install their app.
Even more ideally it was more intelligent than that and some means of ensuring any .msi was indeed installing the application that the msi name related to (seems unlikely but just in case a normal user created an .msi to grant himself further admin access as per http://blogs.technet.com/b/fdcc/archive/2011/01/25/alwaysinstallelevated-is-equivalent-to-granting-administrative-rights.aspx )
Ideally its lifespan would be limited in terms of time (unsure if this could be for example to x number of days).
Any pointers on how to go about this, seems like a good challenge :)
Thanks for reading all that!
Mike
Thanks for the responses,
I managed to do this in C#, with no prior experience in the language :)
The application has 2 parts to it, a GUI and a service. It works by having the application send an install command via IPC to it's counterpart elevated service. (Thanks Hans Passant for pointing me in the right direction there). The service initiates the installer under it's own elevated account but displays the installer GUI on the users session. Files are HMACSHA1 checksum validated prior to install, on both the app and the service.
Thanks,
Mike
If a user requires the ability to install application in the Program Files folder, then instruct the domain administrator to give Full Control of the Program Files folder to Everyone:
Just because the default setting forbids standard users from modifying programs, doesn't mean you have to keep it that way. Windows is a secure operating system that gives you the capability to keep it secure.
If your administrator only wants some users to be able to modify the contents of the Program Files folder, then only give that permission to certain users.
The better solution is to re-design the applications so that they do not install in a (by default) protected location. Have them instead install in:
%APPDATA_LOCAL%\Contoso\Frobber\Grob.exe
e.g.
D:\Users\Ian\AppData\Local\Contoso\Frobber\Grob.exe
A user is always allowed to write anything in their own profile folder.
Is there a way to find out what privileges my application needs in order to run in a Windows 7 environment?
I have a Delphi application that is using BDE and ODBC for database connectivity. This application works on most computers with Windows 7 running on a normal user account. However on some computers it only works on accounts with administrative privileges and is not working correctly on normal user accounts. I suspect it's a permission problem. The computers also are running in Active Directory.
I tried to find some informations using Process Monitor from SysInternals, however the output for me is too advanced. The process monitor log for two runs of my app (1. successful with administrative rights, 2. unsuccessfull on normal rights) had over 22k lines and i could not find the answer (needle) in the process monitor log (haystack).
What could i do to determine the privileges that my app needs in windows 7?
Use the Standard User Analyzer from the Microsoft Application Compatibility Toolkit.
The Standard User Analyzer (SUA) tool and the Standard User Analyzer
Wizard (SUA Wizard) both enable you to test your applications and to
monitor API calls in order to detect potential compatibility issues
due to the User Account Control (UAC) feature in the Windows® 7
operating system.
UAC, formerly known as Limited User Account (LUA), requires that all
users (including members of the Administrator group) run as Standard
Users, until the application is deliberately elevated, by using the
security prompt dialog box. However, not all applications can run
properly with the Standard User role, due to the application requiring
access and privileges for locations that are unavailable to a Standard
User.
Aaron Margosis has a tool called LUA Buglight that is designed to help track down issues related to privileges.
You can download the latest version from this blog post:
LUA Buglight 2.1.1 with support for Win7/2008R2 SP1
It is similar in concept to the MS Application Verifier. However, in practice I found LUA Buglight much easier to use and understand. Same with ProcessMonitor. It will monitor your process in a similar way but only report actions that failed as a normal user but succeeded as a admin user.
There is no documentation but it is simple to use. From the main GUI window select your Exe and let the BugLight program launch it. You need to be running in an Admin account with UAC enabled. Run your program though the steps that fail when you are not an admin. When you are done click on the Stop Logging button to see a report that lists what calls would have failed without admin rights.
To get Windows users to log on as regular users instead of admin, I need to check that all their applications run OK with limited rights.
Is there an application specifically aimed at checking that an application can run with limited rights, or is SysInternals' Process Monitor what everyone uses for this purpose?
Thank you.
Create a test account that has the permissions as the domain users of your application Login in as this user on a non-development computer. Preferrably a computer with a new operating system installation and all of the other "standard" company software. Install the software and run. This is the only way to really test your application.
Make sure you exercise the entire application.
Make sure install and uninstall work as expected and do not leave any artifacts behind.
Having the ability to restore the operating-system and software on the test computer to its original state is a great help.
Use the Permission Calculator Tool to make sure you handle obvious issues before performing this test.
I'm not sure if it would help since I never used it but I know there's a Permission Calculator Tool (Permcalc.exe) at http://msdn.microsoft.com/en-us/library/ms165077%28VS.80%29.aspx.
Permission Calculator Tool
(Permcalc.exe)
The Minimum Grant Set Determination
tool (Permcalc.exe) is used to
estimate the permissions callers must
be granted to access the public entry
points of an assembly. This tool is
new in the .NET Framework version 2.0.
It is intended for use by advanced
users.
Run this application on Windows 7/Vista with access control enabled. You may consider Windows 7 as such testing application :)
It is recommended to use non-administrator account with activated access control on a developer computer, when you write and debug the program. This creates some problems, and Windows developers hate this, turning off access control or using administrator account. However, working on Linux/Unix, we don't have administrator rights, and this is OK.