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?
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.
I've been having issues with people modifying powershell scripts and causing mayhem. Is there a one liner that I can insert into a current script to require a password that I set in order to modify the script? I still need everyone to be able to run it.
The easiest and most straightforward way is to put the scripts somewhere that the problem users don't have write access to. There's nothing you can do in the language itself to prevent a user from modifying a file they have write access to.
If you can't do this for some reason (they are admins and have too much access), then you can do a few other things.
Signing
Apply a digital signature to your scripts.
For this to work, you need to be able to enforce an execution policy of AllSigned (or RemoteSigned if these scripts are executed directly off of a share). You might do this with Group Policy.
You also need to control access to the signing certificate and ensure that it's the only one that's trusted.
Note that these users can still copy the script locally, make modifications, run powershell.exe -ExecutionPolicy Bypass and still run their modified script.
The difference is that this is their copy and doesn't break it for anyone else. And if they overwrite the central script without signing it or signing it with an untrusted certificate then everyone will notice.
If the users are privileged enough they be able to override more of this.
Central Deployment
Put the scripts in a custom local repository and use the package management functions Find-Script / Install-Script so everyone is referring to the same ones, and have a well-thought out deployment process. This can be combined with signing.
But...
Ultimately if these users are privileged and they are acting in bad faith, this is a personnel problem and can't effectively be solved with technology. In that case, The Workplace may be able to help.
I have a batch file where I copy file from a different server. I have no issues running it on the server. But when I try to run it from a web application, the file does not copy. I keep getting access denied error. I have used xcopy, copy and robocopy.
I have provided full access to source and destination folder for all users.
No luck. Keep getting the same error :
copy /y \N01APW280\d$\Oracle\Middleware\user_projects\epmsystem1\diagnostics\logs\essbase\essbase_0\app\PLPLAN\PLPLAN.LOG D:\Hyperion\ERPI_Actuals_Load\Logs\
It is rather awkward to try and use a command-line utility, such as copy, from a web app; you should rather be using the programmatic abilities within your web application instead.
Aside from that, you main issue is that web apps are typically executed with very limited privileges, using local machine accounts that have no way of accessing administrative level shares on remote machines such as \N01APW280\d$. Another possible issue is that the local account that is being used by the web app cannot write to D:\Hyperion\ERPI_Actuals_Load\Logs\ folder. And finally, your app may have enough privileges to instantiate an external process such as copy.exe.
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.
As I've explained in my other question, I'm busy setting up a PowerShell module repository in my enterprise.
My plan is to have a master repository (r/w access to a limited group of people) and slave repositories (read only access to everyone). I need multiple repositories because clients are located in different security zones and I can't have a central location reachable by all clients.
For this reason, I need to configure the PowerShell profile of the clients so that they can point to the correct repository to find the modules. I would like to define a $PowerShellRepositoryPath environment variable for this purpose.
Also, the profile needs to be customized in order for it to execute a script located in the repository (thus where $PowerShellRepositoryPath points to) when PowerShell starts (my goal here is to automatically add the latest module versions to the PSModulePath of the clients on startup).
We have a mixed environment with domain members and stand-alone servers in different network zones.
How would you proceed? Is it possible to push that variable and the profile via a GPO for domain members? Would customizing the $Profile variable via GPO be an option?
What about the standalone servers?
Edit:
I think that for creating the environment variable, I'll just use a GPO to create it and use it in PowerShell via $env:variableName. For non-domain situations, I'll probably have to use a script though..
I am not sure about pushing $profile via GPO. But, I'd simply put a logon script that copies the profile script from a network location based on the user's group/security membership.
Well if you're going to change the path to the modules, I'd have a file in the repository (say current.txt) that has the name for the current module (or current file path, whichever you are changing) in it. Then have the $profile script read the content of that file, and set the variable based on the contents. This way you don't have to screw around with updating the profile scripts, just update the central repository current.txt file with the path (or partial path, the part that changes, or filename or whatever), and when it replicates to the client repositories, all powershell profiles get updated with the latest modules when the profile script is executed.
Out of curiosity, why not just overwrite the module files in the client repositories with the latest version? If you did it that way, all clients would always have the latest versions, and you wouldn't have to update the $profile scripts.
Alternately you could always write another script to replace the $profile script on all machines. I think the first route I suggested would be the cleanest way of doing what you are after.
As far as the GPO thing goes, I don't believe you can do this. There is no GPO defined to control what is in the profile script. I would say you could maybe do it with a custom ADM file, but the profile script path is not controlled by the registry, so no go there.