Unix permissions needed when running Powershell script - powershell

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.

Related

Is there a way to automatically update windows 10 OS for computers in domain on group policy?

I want to be able to push a new group policy out with a powershell script (or scripts most likely) that will make all computers on our active domain update to the windows OS that we want. Currently there are hundreds of users and we don't have a way to update their computers other than doing it via remote desktop for each computer individually. But every computer has the .exe file required to update, just hasn't been run yet. Something like
wuauclt.exe /updatenow
I am also open to other suggestion on how to do this. I was thinking of sending all the users a batch file and having them run that and they could do it themselves. Any help would be appreciated and if this post wasn't specific enough I can answer questions or take it down. Thanks!
Never and I mean NEVER let user deploy updates on his/her computer themselves by clicking on some batch or exe file. Two reasons:
It will just not work and big part of machines will not be updated.
You are teaching users that they can run various and unknown batch files / powershell scripts / exe files, because it's safe.
Since you said "hundreds of users" I believe that you have some domain there.
What you might be looking for are the Group Policies (https://learn.microsoft.com/en-us/windows/deployment/update/waas-wufb-group-policy) or WSUS (https://learn.microsoft.com/en-us/windows/deployment/update/waas-manage-updates-wsus).

update Unix permissions on a windows share

My Unix box has a mapping to a Windows share. On the Windows server, a Powershell script is copying folders to this share UDI/inbound throughout the day. On the Unix side where my Oracle database is running, I need to be able to update or write a file under one of these share folders. But permissions are blocking me. See visual below.
When looking at it from the Unix side, the owner/group(33448/32770) are different than my Unix login (orahubd/dba), so I cannot change the permissions from the Unix side. Is there some way from the Windows side, like in my Powershell script, to change the permissions so that Unix would allow me to write? I was able to set the permissions via Powershell to Everyone:Full, but that doesn't seem to change it from the Unix perspective.
I am an Oracle PL//SQL developer, just a novice dabbling in these other technologies.

Does Chef powershell_script have limited privileges?

I am encountering several situations where, in a Chef recipe with powershell_scipt, a command appears to fail, whereas if I run the same command in powershell outside of Chef, the same command works.
The two in particular are "regedit", which I am trying to use to set a key for app compatibility and the other is "net use z:...." to created a mapped drive. Both of these seem to work fine if I run them in powershell, but if I use them inside a recipe inside powershell_script, they don't appear to do anything.
So I'm wondering is this because Chef runs commands that are inside powershell_script at some lower privilege level?
Also if so, how do I change it so that the regedit and net use would work?
Thanks,
Jim
EDIT 1: This seems to work for adding the registry entry I needed:
registry_key "HKEY_CURRENT_USER\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags" do
values [{
:name => "{2b9034f3-b661-4d36-a5ef-60ab5a711ace}",
:type => :dword,
:data => 00000004
}]
action :create
end
That prevents the compatability popup that I am getting when we run the Sharepoint installer.
EDIT 2: I hope that this is ok, but for the record and more visibility and hope that I remember this, I found this re. mapping drives in Windows and Chef:
Mount windows shares on a windows node with Chef
and:
https://tickets.opscode.com/browse/CHEF-1267
I haven't tried that yet, but that seems like the answer to my drive mapping need.... hopefully..
The chef client service runs as Local System (SYSTEM) by default.
In Windows, that user has full privileges on the local system, like root basically, but on the network it authenticates as the computer object.
So it you are trying to use regedit to change something in for example HKEY_CURRENT_USER then you need to remember that the code will not see the same "current user" as you will when you run it in interactively. Also, regedit is an .exe; you should really do what you need through the PowerShell providers or .Net objects.
For net use you are trying to map a drive. It's likely that the computer account doesn't have the rights to the share that your user has. Again, net.exe is a separate executable. net use maps a drive to a drive letter (usually) and you shouldn't be doing that in a configuration script, in my opinion. You should access the UNC path directly, but either way I still think that you're probably running into a permissions issue here.
You could change the credentials of the service to use a user account that has all the rights you want, but before doing something like that you should consider changing your workflow to not need that.

PowerShell Script Cannot Write to File Share via Group Policy Startup Script

I have added a PowerShell script as a Group Policy computer startup script. The script runs fine and does all of the tasks fine. However, at the end of the script, it is supposed to copy a log file to a file share, which it is not doing. The file share shows that "SYSTEM" has full control, so I'm not sure what the issue is. I'm able to run the script as admin while on the same machine and it will copy the log to the server without a problem. It does not do this via computer startup script (under SYSTEM account) though. Any ideas?
You will need to give the computer account write permissions on the network share. When the SYSTEM account is used to access a network resource it will do so as the domain account of the computer (DOMAIN\COMPUTER$).

Accessing files over the network through a script running as NT Authority\System

I'm not sure if I am asking this in the right spot or not, sorry if I am wrong.
I would like to know please, SCCM is currently operational in our school, and we use it to install software across our network.
I have a piece of software that requires a different channel for each room or staff laptop that it is installed in.
I have managed to set up a powershell script that polls a csv for the channel that should be assigned to each room, and when the script it run, it pulls that channel and installs the software with that channel assigned.
What I am having trouble with now, is that SCCM installs the software using the local system account, and the csv is located on a network share.
When the System account goes to poll the csv file it gets an access denied error, even though System has full control of the csv and directory that the csv is located in.
Is it just me not understanding the permissions that System has, or can System not interact with other devices over the network, I assumed that being system on both devices, it would be able to cross to another device and impersonate system on that device.
Is there a way around this?
Thanks for any feedback.
The system account uses the machine account when accessing the network e.g. COMPNAME$, if you're on AD you can add a grant to that computer account to the file share ACL. If you don't have a domain you can create a local account with matching username and password on both machines and configure the service to run as that account.
By simply adding Domain Computers to the files permissions list and assigning it Read/Write permissions, I am able to let any computer in this group (all computers on the domain) access the specific files.
This is also what Andy Arismendi was saying, however just an already setup group.