The problem is that in our clients their normal user doesn't have administrator privileges so when they have to install or update our programs they have to log again as administrator to install them and then log as their user which is cumbersome...
As some updates are automatic the "run as" solution isnt a valid one...
One good idea would be to mark a folder as "admin folder" so all the exes executed from that folder run as administrator (having configured the admin account previously)
or a configurable a list of executable names that must run as administrator (i say names because it could be different installers with different hash but with a generic exe name that identifies it as ours)
Does anyone know a program or windows configuration or c# code to achieve something like this?
It seems nobody knows how to do it or doesnt want to tell because its a security hole...ironically having this escalating privileges hole would be better than having the user as administrator for everithing :S... (Appart from not being a valid solution for our clients)
Related
As custom action of a WiX-based installer (MS Windows 7), I need to check out some files from a StarTeam server. stcmd seems to provide all functionality and I am able to perform the checkout with UID and password provided via parameter -p.
Since the installer is run by different users, I obviously need a mechanism to inquire the StarTeam login credentials at run-time instead of hard-coding UID/pw.
I was browsing the StarTeam manual but was not able to figure out if the StarTeam programs provide a solution to that problem. Any suggestions?
Sorry, this just doesn't make sense to me. Typically you include files from source control in the MSI at build time not install time. What does install time buy you other then complexity? Now application runtime would make sense to me. You could create and install an application that prompts the user for creds and then periodically polls star team for updated files. (Windows service, scheduled task, logon autorun...)
Couldn't you could prompt your users for the login information during the install and then pass them to the stcmd.exe?
Meh, the solution is trivial. When using an empty password, stcmd automatically asks for the password. Example:
stcmd connect username:#hostname:portnumber
Using the stateful commands is recommended since the credentials are stored internally for all subsequent commands.
So in IT environments we commonly lock down users profiles to prevent access to the registry, command, prompt, control panel,etc. This can easily be done via GPO. However, there are times when you need to make a quick change to the users profile when everything is locked down. Maybe it is to changes the video resolution or the wallpaper, or edit something under the restricted users HKEY_CURRENT_USER. So it is easy to reboot and login as an admin. Open their registry hive. and rename "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies" to Policies.disabled log them in and make the changes and refresh via gpupdate /force. But there should be a better way with impersonate user or Run As. But when you run RunAs as another user it runs it as the admin and you get the Admins HKCU.
How would you make it so you can run an app made in VB.NET that simply deletes "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies" so you can make those changes?
I'm currently developing an application which needs root privileges for several operations (e.g. deleting system log files, etc.). One solution would be to implement a privileged helper tool which will be launched automatically by launchd. This way the user has to type in an administrator password every time such operation shall be executed (or every time the helper needs to be installed).
Now I wonder if it is possible to create an installer package which will install the application with root privileges so the user types in the administrator credentials just once (during the installation process) and every time the application gets started it is being launched with root permissions (without prompting for admin credentials).
Is there any way to achieve this?
The usual way to do this on Unix systems is to use setuid. Basically, you change the owner of your program to be root, and set the "set user or group ID on execution" bit (s):
$ chown root:root myprogram
$ chmod u+s myprogram
Any time a user then executes your program, it will run as root.
Note, though, that there are very good reasons for prompting for admin credentials.
Using this mechanism (or doing what you're trying to do, in general), can very easily lead to very dangerous security holes like privilege escalation. Any executable you use setuid on should be thoroughly audited by somone familiar with the process, otherwise attackers will root all machines your program is installed on.
We work with a group of contractors that need access to our TFS 2010 server. I've got Active Directory running for our office, so every user has an AD account. Is there a way the TFS users can change their passwords through TFS? I've changed passwords before by having users RDP into computers and changing their account information there, but I'd rather not give the contractors RDP access (they just don't need it).
I tried selecting "user mush change password at next login", but TFS seems not to respond to that.
The only login vehicle the contractors use is TFS.
Thanks
That's correct, TFS doesn't provide a mechanism to change passwords. Your users will need to use some integration to Active Directory to change their password. It needn't necessarily be through an RDP session, as long as they can hit Active Directory's LDAP server, you should be able to allow this.
IIS ships with a tool called IISADMPWD that lets users change their password over the web.
In addition, you can build your own tool to change the password, like other people have done in PowerShell or perl. In addition, there appear to be various commercial tools to enable this.
I want my program to be able to edit a values within a registry key that resides in 'HKEY_LOCAL_MACHINE'
My.Computer.Registry.SetValue("HKEY_LOCAL_MACHINE\SOFTWARE\XYZ", "MyValue", "MyData")
The above works fine in Windows XP, but throws an UnauthorizedAccessException in Vista.
You are running into Vista's UAC feature. It will not let you write to arbitrary places in the HKLM hive because you are not running with Administrative priviledges.
There are two ways to work around this issue
Run the program with Administrative priviledges (different than running a program as an account which has Administrative priviledges)
Choose another place, perhaps HKCU, to store the data
The second option is much better as it allows your application to run with non-Admin priviledges which you can't always assume your user has.
Here is a fairly detailed article on UAC. It's not 100% programming material but it gives a good explanation as to what exactly it is and you can hopefully relate that to your particular program: http://technet.microsoft.com/en-us/library/cc709691.aspx
Since changes to the Local Machine hive can have affect across the system you will find that changes to it are restricted to non-administrative users. If you try to run your same code on an XP machine a non-admin account you will get the same error. On Vista since the process is non-admin by default you are getting this error. Information on this is in the "Made for Windows 2000", "Made for Windows XP", and "Made for Windows Vista" certification guidelines.
Given that I've got little information on what your program is doing more information may be needed to give you specific guidance, so I will speak in the general case. You want your application to leave the local machine hive alone unless you need it. When your program is run in non-admin mode it you can either disable the functionality that requires access to these admin keys or you can request that the admin privs.
Vista has tighter restrictions around Adminstrator accounts. If you're not logged in as an Administrator account, you'll have to write to HKEY_CURRENT_USER as opposed to HKEY_LOCAL_MACHINE.
IMO, this makes more sense. Each user has their own settings/etc for their programs. If you want to make global settings for your program, you'll have to do it with an Administrator account.