I wanted to create an installer which creates some files under Program Data/{myprogram}, but with access limited to the Network Service user. I can assign ownership of the directory but at the moment the directory is readable by all other users.
I've tried adding 'Add Windows file rights' actions with trustees of 'Users' and 'Authenticated Users' with no permissions set - but maybe this can only add permissions, not remove them?
Is it possible to remove these permissions? Or is this the wrong idea and I should create the directory for program data elsewhere?
I've tried adding 'Add Windows file rights' actions with trustees of 'Users' and 'Authenticated Users' with no permissions set - but maybe this can only add permissions, not remove them?
That is correct, the "Add Windows file rights" action can only add permissions. I've created an issue for adding a "Remove Windows file rights" action.
Related
As a final step in our AD account creation process that is being moved to a powershell script a few folders need to be created on the filer for users and I am coming unstuck with permissions.
I am just using the basic new-item command to create folder but the locations need unix permissions (775) set before anything can be created. I can't go there and right click in Windows explorer and click new.. and the powershell script is being bounced also due to permissions.
The reasoning from one of the tech guys here is that I am trying to create a sub folder via smb mount from Windows using ntfs permissions. There is no correlation to unix permissions and any of our Linux users won't be able to access / use the location created for them.
Sorry if that is a clumsy way of explaining it, I am not a systems engineer, just the guy trying to translate a whole heap if pearl scripts into a new powershell process.
Thank you
S.
We're planning on AD migration, the headache part is to maintain file and folder permissions.
We opted not to use MS AD migration tool, but use Powershell get-acl to dump the existing file/folder permissions, then after a manual mapping of old and new AD accounts, use set-acl to restore.
The headache part is that once the file server is migrated to the new domain, existing permissions are all gone. The new Domain admins since is not owner cannot run the get-acl and (in powershell, to set file permission, you need first run get-acl, then run set-acl) directly. This is same even I run the script in elevated mode. I can take ownership of all the folders, but this will change the folder inheritance, so not a best way to do.
Is there a way to run 'elevated' powershell script on folders that have no explicit or implicit permissions?
Do you thought about creating temporary trust between AD domains?
For our installer application it is not necessary to install with administration privileges. But when the user decide to install to the system program folder like C:\Program File\OurApp then the user gets a dialog that privileges are missing and another folder has to choose/create. Now the question: is it possible to grand the previliges depending on the installation location during the installation instead before starting?
Yes, the "Request privileges" action can be added to any screen. By default it's in the "Startup" node, but you can delete it there and add it to another screen. It can have a condition expression, so it's only executed when necessary. The action starts an elevated helper process that will execute elevated actions.
As of install4j 6.0.4, the installation location screen will always show an error message if the selected directory is not writable. Starting with 6.0.5, you can deselect the "Check if directory is writable" property and handle writability yourself. Also added in 6.0.5 is the helper function Util::isDirectoryWritable that helps you to check if the currently available privileges allow you to write into a directory.
I have Word Add-in, which keeps updating "winword.exe.config.xml" file present at "C:\program files\microsoft office\.
I need to write changes to this file,update few parameters while running MS word.
when the User is "Administrator", the changes are updated successfully in the file without any problem.
In case of Non - Admin accounts(they do not have the file permission), the changes are not reflected as the write permission is not there.
Is there any way i can write to these files successfully from C# code for Non-Admin accounts also, without asking user to change the permission of the file.
If you are in control of the add-in then you simply need to choose a different location for the config file. A location to which a standard user has write permissions.
If you are not in control of the add-in, then you have two viable options:
Always run Word as administrator.
Add an ACL to the config file to grant write access to standard users.
You ask:
Is there any way I can write to these files successfully from C# code for non-admin accounts also, without asking user to change the permission of the file.
No there is not. Just imagine if there was a way to do this. That would completely negate the utility of file system security.
We made a backup of a web application through the central administration to move it to a different server on a different domain and it's a domain controller actually.
So we made a restore operation on the destination server from the central administration but never managed to succeed.
with errors like: Object failed in event OnRestore. For more information, see the spbackup.log or sprestore.log file located in the backup directory.SPException: The specified user or domain group was not found.
I tried every user account possible with no success. any clues?
Two things:
Did you try with "New Configuration" option while restoring? I believe the problem is related to the users/groups added to the site and those users do not exist in new environment!
Also can you try restore using PowerShell with -Force switch parameter and see if that is successfull?