I am trying to modify User Rights Assignment on Windows 10, using the command-line; specifically, I want to remove "NT VIRTUAL MACHINE\Virtual Machines" from the "Create symbolic links" right.
I have tried a few different methods so far, but nothing has worked short of manually configuring via the Local Group Policy Editor GUI...
What I've tried:
exporting User Rights Assignment via secedit, modifying them, then re-importing -- I've verified that the modifications are made correctly, and this appears to succeed, but the account is not actually removed from "Create symbolic links"
LGPO to export Security Settings, modifying them, then re-importing
this guy's excellent-looking Microsoft-signed script: https://blakedrumm.com/blog/set-and-check-user-rights-assignment/
ntrights.exe (a tool from Windows Server 2003 -- it does not appear to be aware of/support SeCreateSymbolicLinkPrivilege)
In all cases (except for ntrights.exe), I seem to be getting syntax right, but it is not being removed. It doesn't seem to be an especially privileged setting, because I'm able to do it as an Administrator through the Local Group Policy Editor GUI.
Anyone have any ideas? Any help would be appreciated.
Thanks!
Related
They might be quite obscure: i enjoy RazorSQL for all it can do, and it is the only tool i found that talks properly is Clarions's ODBC driver. It also allows for awesome command line calls to export data.
Trouble is: RazorSQL stores profile connection information based on the user that installed it, and when you set a Windows task to run the batch files of all the groovy export commands, the internal batch file fail without external notification because the user is SYSTEM (as we don't want this tied to any one user)..
I do not recall if there was an option on install allowing profiles to be seen by all, as i normally set this to everyone on my dev box (as it is only me).
So the question: has anyone encountered this obscure scenario, and knows how to have RazorSQL look in a generic location for connection details?
RazorSQL checks for system property named "razorPortable". When defined with a value of "portable" it keeps all its stuff in a RazorSQL folder under its main directory, so shared by all users launching it with said property defined.
So you know the drill: edit some of the bundled bat files and add -DrazorPortable=portable to the command line.
You'll need to re-enter yout registration code, connection profiles, preferences, etc. Or you can manually move them.
Is it possible for someone with Administrator access to easily create arbitrary files (e.g. text documents) within the C:\Inetpub\wwwroot folder under Windows 8.1?
Normally right-click presents me with many file types I can create; here, I'm only given the option to create a new sub-folder, even though I can (i) edit existing files there or (ii) create files elsewhere and move them there. (Also, gvim running with administrator access can't create a (new) swap file there).
I created a subfolder ("test"), and took ownership of it, but it made no difference. One of my colleagues thought that this was a "special case" overridden by IIS and could be configured by the Group Policy Editor somehow?
I've heard that disabling UAC solves the problem, but I don't want to do that!
Any ways round this? (Reference to an existing discussion I missed would be fine if it covers the same problem). Thanks!
Smychi
Solved this; I added the specific administrative user account I was logged in under ("User") to the list of permissions and granted myself "Full Control".
Not sure why this didn't already work with the existing groups settings, though I'll admit my knowledge of Windows permissions isn't as good as it should be.
Feel free to say whether this is a good or bad way to do it, or add any comment to this anyway, for my benefit or for others who might stumble across this.
Smychi
Our application is deployed to the target machine with an msi file. All works nicely. Our tester has gone through his plan, and one of the tests requires deleting the application's configuration file. The application is designed to alert the user with a dialog on startup saying "missing config". However, what happens is that - somehow! - the software starts the installer again and retrieves the missing file from the msi! Which is nice, but not what we want. How do we disable that behaviour?
without going into much depth of the windows installer mechanics (if you interested in that there a plenty of articles about this), the shortcut of the software is probably advertised, which means the windows installer checks if everything is in its place before the software is started.
if you can edit the msi, make the shortcut non advertised.
if you can't, install it with DISABLEADVTSHORTCUTS
e.g. msiexec /i myMsi.msi DISABLEADVTSHORTCUTS=1
please note that this is only a quick (and dirty) workaround,
to fix this proper you need to understand the whole windows installer advertising (also called repair or self resiliency) mechanism.
but explaining all the causes and the mechanism of the repair is far beyond this answer and there are quite some articles and posts about that on the internet (and especially on MSDN and stackoverflow)
There is a more correct answer to this, and it is NOT DISABLEADVTSHORTCUTS. You set the component id to null in the MSI file to prevent repair of that individual file. See ComponentId comments here:
http://msdn.microsoft.com/en-us/library/aa368007(v=vs.85).aspx
Edit the MSI file with Orca to delete the Componenty ID, and write an uninstall custom action to delete the file at uninstall if it's there.
In addition, that's a redundant test. Windows will restore that file for you if it's missing, so the idea that you need a test to notify that it's missing is pointless. The true test should be that Windows will restore the file if it's lost, and your app needs to do potentially nothing about the missing file.
You don't mention what tool you are using to make your MSI but I'm going to go out on a limb and guess Visual Studio Deployment Projects (.VDRPOJ).
One of the (many) horrible things about this tool was that it fails to expose the foundational concept of components. Instead it makes every file a key file of it's own component and hides the existence of the component from you. I say 'was' because Microsoft killed this project type in VS. There are around 50k people complaining on UserVoice to bring this tool back and I'm guessing that 49,990 of them don't know what a key path is.
Windows Installer has a concept called the component rules and each component has a keypath. The keypath teaches MSI how to handle repair scenarios. But your tool has to allow you to be able to control this to make it work.
Windows Installer is functioning exactly the way it's supposed to function. You just aren't up to speed on what that is.
However, if you want to ignore Windows Installer best practices and continue using the tool you use today, the trick is to install the app.config file as a different file. Then have the application copy the file to the real file name on run. Windows Installer won't service what it didn't install.
Several answers have been provided that can work:
You can install the file with a blank guid. Then you need to remove it on uninstall using the RemoveFile feature. You will also run into issues if you want to replace it during an upgrade. Could be tricky at times.
You can disable the advertised shortcut(s), but this affects too much in my opinion.
Finally you can use my suggestion to install a separate non-advertised shortcut to use to launch the application. Such a shortcut bypasses the self-repair check. It may still be invoked by other means such as missing file associations, COM registration or similar, but those are exception states.
However, my preference is that an application can start without a config file present, if at all possible. I always suggest a good startup routine with "internal defaults" available. The startup routine should also degrade gracefully if faced with any file system access denied conditions.
Most importantly you should place this config file in the userprofile so you can generate the file on first launch for the user in question. It can even be copied from a read-only copy in the main installation directory.
When you generate a file from internal defaults and put it in a userprofile location, the file will have no interference with Windows Installer at all. The issues that results is how to clean up user data on uninstall. I discussed this with Stefan Kruger (MSI MVP) at one point, and I agree with his notion that user data is indeed user data and should not be automatically dealt with by your installer at all. Leave it installed, and clean it up via system administrator tools if necessary - for example logon scripts.
I want my installer to create a folder in C:\Users\Public\Documents that will be readable and writable to all local users. This includes the right to create files/dirs there, and to modify and delete all existing ones. The installer is being ran as Administrator.
I don't have to programatically set the permissions for my dir, right? Just by creating the dir, it will have the correct permissions I think.
I'm interested in the behavior under XP, Vista and 7.
Note: I'm not hardcoding the path C:\Users\Public\Documents, I'm querying CSIDL_COMMON_DOCUMENTS from the Win API, which can return different values depending on machine and OS. For example on XP it returns a different path.
Edit: here's a relevant discussion. It points to MS docs about the question, but it also looks like those docs may be wrong.
Yes, it inherits rights from the parent folder. Which has write permission for anybody in the INTERACTIVE group. Which includes any logged-in user account.
Use the Security tab in the shell's Properties dialog to review these settings.
In the [Run] section of an Inno Setup script, there's a flag runasoriginaluser that allows the script to run a process as the original user:
the spawned process will execute with
the (normally non-elevated)
credentials of the user that started
Setup initially (i.e., the "pre-UAC
dialog" credentials).
Is there an equivalent flag or workaround for the {userdocs} shell folder constant?
This is apparently a known limitation within Inno Setup (and other installers, generally), but I'm hoping someone knows a workaround.
Excerpt from the Inno Setup help file:
The "user" constants refer to the
profile of the user running Setup.
This user is often not the same as the
currently logged-in user, so use the
"user" constants with caution.
The workaround I came up with was using an external script to perform the data copy and calling the script using the ExecAsOriginalUser function in the wpReady page of the NextButtonClick event function.
I'll provide more details if anyone is interested.
Your approach is not correct.
There two correct ways:
If the installer installs the application for the current (unprivileged) user only, do not require Administrator privileges, by setting PrivilegesRequired to lowest:
[Setup]
PrivilegesRequired=lowest
Then the "user" constants will correctly refer to the current user's folder.
If the installer installs the application for all users, it does not make sense to put some files to folder of one specific users. All users need the files, not just the one. In this case the recommended approach is to install the files to "Common" folder, using the {commonappdata} constant (or similar). And have the application copy the files to the user folder on the first run.
See also How to write to the user's My Documents directory with installer when the user used 'Run As Administrator'.
You can also allow the user choose between these two approaches.
See Make Inno Setup installer request privileges elevation only when needed.
For another similar questions, see
Inno Setup Using {localappdata} for logged in user
Inno Setup always installs into admin's AppData directory
Having that said, you can, as you have found yourself, by execute an external copy utility (copy, xcopy, robocopy) using the ExecAsOriginalUser function (or the runasoriginaluser flag in the [Run] section).
ExecAsOriginalUser(
'cmd.exe', '/c xcopy.exe "sourcefile" "%APPDATA%"',
'', SW_HIDE, ewWaitUntilTerminated, ResultCode);
For more detail on this approach, see a similar question Inno Setup Creating registry key for logged in user (not admin user).
Though, if the installer was started elevated straight away (as opposite to elevating itself), the above won't work. And it cannot work in this scenario anyway. See How to write to the user's My Documents directory with installer when the user used 'Run As Administrator'. For this reason, stick with the approaches described above.