Powershell Megathread: Verb-Noun Scripting is the future

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Powershell Megathread: Verb-Noun Scripting is the future

Jowj: Dec 25, 2010; My favourite player and idol. His battles with his wrists mirror my own battles with the constant disgust I feel towards my zerg bugs.

Anyone familiar with granting "Full Control" of an AD object to another AD object? I had asked for help with this in HangOps and Stubblyhead helped out a bit (thanks!) but after that ran into some errors that showed I needed more understanding. Backed up from doing AD stuff to just generic file permission stuff and got that ok. I pulled from a technet article and hosed around to get a better understanding. :

code:

# Pulled from here: [url]https://technet.microsoft.com/en-us/library/ff730951.aspx#mainSection[/url] and tweaked a tiny amount

$colRights = [System.Security.AccessControl.FileSystemRights]"FullControl" 
$InheritanceFlag = [System.Security.AccessControl.InheritanceFlags]::None 
$PropagationFlag = [System.Security.AccessControl.PropagationFlags]::None 
$objType =[System.Security.AccessControl.AccessControlType]::Allow 
$obj = get-ADComputer clusterobj01

$objUser = New-Object System.Security.Principal.SecurityIdentifier($obj.sid) 
$objACE = New-Object System.Security.AccessControl.FileSystemAccessRule `
    ($objUser, $colRights, $InheritanceFlag, $PropagationFlag, $objType) 

$objACL = Get-ACL "C:\Scripts\Test.ps1" 
$objACL.AddAccessRule($objACE) 

Set-ACL "C:\Scripts\Test.ps1" $objACL

Used info from that to fix some of my type declarations, but now I'm running into issues with the class I'm in. Here's the script that isn't working for setting permissions on the ADObject.

code:

# Pre-reqs set
import-module activedirectory
set-location -path "AD:\OU=SQL,OU=Servers,DC=dev,DC=test,DC=com"

# Declare FileSystemRights variables
$colRights = [System.Security.AccessControl.FileSystemRights]"FullControl" 
$InheritanceFlag = [System.Security.AccessControl.InheritanceFlags]::None 
$PropagationFlag = [System.Security.AccessControl.PropagationFlags]::None 
$objType =[System.Security.AccessControl.AccessControlType]::Allow 
$obj = get-ADComputer Clusterobj01
$objUser = New-Object System.Security.Principal.SecurityIdentifier($obj.sid) 
 
$objACE = New-Object System.Security.AccessControl.FileSystemAccessRule($objUser, $colRights, $InheritanceFlag, $PropagationFlag, $objType)
 
$objACL = Get-ACL ".\cn=testsql997" 
$objACL.AddAccessRule($objACE) 

Set-ACL ".\cn=testsql997" $objACL

This results in the following error:
Cannot convert argument "rule", with value: "System.Security.AccessControl.FileSystemAccessRule", for "AddAccessRule" to type "System.DirectoryServices.ActiveDirectoryAccessRule": "Cannot
convert the "System.Security.AccessControl.FileSystemAccessRule" value of type "System.Security.AccessControl.FileSystemAccessRule" to type
"System.DirectoryServices.ActiveDirectoryAccessRule"."

I had thought that the "FullControl" was a FileSystemRight but PS is trying to convert it to a System.DirectoryServices.whatever type and is failing. But under this DirectoryServices type there isn't a "FullControl" member. So my thinking so far has found 2 possibilities:

1) You can't do this (which seems unlikely) through PS
2) FullControl for ADobjects isn't actually a FileSystem member (which makes it Very Confusing :\) and instead exists in a different class, just not the class PS is throwing as the type convert failure.

I've looked through the System.DirectoryServices Namespace and I haven't found a class that actually contains the member "FullControl', but its possible I missed it I guess. Can someone help me bridge whatever gap I've got in my understanding?

# ¿ Sep 6, 2016 17:14

Adbot: ADBOT LOVES YOU

# ¿ May 20, 2024 15:21

Jowj: Dec 25, 2010; My favourite player and idol. His battles with his wrists mirror my own battles with the constant disgust I feel towards my zerg bugs.

Thanks GPF, cheese-cube. I do not use .net *ever* so apologies for the fundamental mistakes. I think I'm gonna buy a .net book once this quarter is over; it seems that there's a bunch of functionality in Powershell that I just can't get at well because I'm stuck not understanding .net poo poo very well.

quote:

Pro-tip: always be Googling full type names

Thanks

. If you have more Entry Tips or a place to go read them I'd definitely appreciate it.

quote:

However I'd like to be a dick and question your motives: why do you need to apply full-control permissions on objects in AD and is there a reason why you can't just use inheritance? The primary reason I ask is that explicit object-level permissions rapidly become an administrative and security PITA.

Naw, you're not being a dick, its a good question.

For context, this is part of a set of scripts I'm making for DB cluster build automation. Security doesn't want to grant the DBAs/MSSQL account permission to create instance objects in this OU so each time a new cluster is built every instance has to be manually added and have the clusterobj associated with the instance granted fullcontrol. As to why we're not doing inheritance its because I don't have enough time to get approval to change our process and then implement the change before the project is due. Everything I've read makes it look so much easier if I have poo poo configured at the OU level instead of at the individual object level, just :\.

So, no business justification really, just timelines from management.

# ¿ Sep 6, 2016 19:28

Jowj: Dec 25, 2010; My favourite player and idol. His battles with his wrists mirror my own battles with the constant disgust I feel towards my zerg bugs.

Ugato posted:

Alright I'm a bit stumped with my current project. I'm trying to automate a lot of the daily repetitive tasks my team and I face. I've actually done so pretty successfully so far but now I'm looking to automate things related to spreadsheet data.

Basically I'm starting from square 1 there. I've messed around a little but never stumbled across a way to do either of what I'm looking to do:

I have a spreadsheet. The first column is a list of 25-30 $number s which indicate a location. Based on these $number s I already have a test-connection based script which gets ping results for a bunch of formulaic IP addresses. The first step is assuredly the easiest - having one button for: read each $number, dump them all in an array and feed that array, one by one, through my function.

It may be significantly harder but I'd also like to automatically put the results in static fields on each row according to column 1's number.

Another thing that would help significantly would be done at the same time: take each $number and - in a separate spreadsheet - find the row where column 1 matches $number and pull columns (10-15) from that row. Each field is stored as a different variable to create a partial config that often times needs to be added to a router or switch.

e: oh, I'd also like to be able to output the results of my test-connection function back to the original sheet after pulling the list of $number s (to specific fields based on the ordering of the results). I'd also like to be able to output the same thing but for a given $number (only that row). I know the bulk of this will be the same thing but I guess it's the same question as the paragraph above, just inverted. How do I find a line based on a given $number and output data to specific fields?

I really only need help with the bolded sections, specifically. I can sterilize the script pretty quickly of anyone wants to look at what I have so far, but I think it wouldn't be especially enlightening or relevant. I realize now this is a lot of explaining and I'm trying to rush through it. So any clarification needed I'll be glad to giveAny help would be appreciated.

E2: vvv thanks. I'll check that out.

Hey, could you post the script? I'm mostly curious as I haven't done any real spreadsheet specific stuff (like moving between two different ones, like you are wanting to do). The first item seems pretty simply like you said. Define an empty array, pull in your data, iterate through data adding each line's location info to your $location array.

# ¿ Jan 27, 2017 04:28

Jowj: Dec 25, 2010; My favourite player and idol. His battles with his wrists mirror my own battles with the constant disgust I feel towards my zerg bugs.

Random Bitch: cmdlets that require multiple other cmdlets in order to be functional. Take a look at this:

code:

#schtasks.exe is used to create the scheduled task initially but I removed the line to avoid tablebreaking

# schtasks.exe cannot modify specific battery arguments without importing XML (not gonna do.dat). Modify it here:
$settings = New-ScheduledTaskSettingsSet -allowStartIfonBatteries -dontStopIfGoingOnBatteries 
$currentUser = [Security.Principal.WindowsIdentity]::GetCurrent().Name
# SchTasks.exe cannot specify a user for the LOGON schedule - it applies to all users. Modify it here:
$trigger = New-ScheduledTaskTrigger -AtLogon -User $currentUser
# SchTasks.exe cannot specify an action with long arguments (maxes out at like 200something chars). Modify it here: 
$action = New-ScheduledTaskAction -Execute "$PSHome\Powershell.exe" -Argument "-File `"$tempRestartScriptPath`""
Set-ScheduledTask -taskname $taskName -settings $settings -action $action -trigger $trigger

First, to know how I got here, I am working on a project with a friend who had already written most of this. However, we were running into a problem where this scheduled task we were creating wouldn't run. Turns out this is because I'm working from my laptop and it wasn't plugged in.

"Well, that should be easy to fix, just allow the scheduled task to start when on batteries and make sure to also allow it to continue when on batteries!"

Well sure, but through schtasks.exe you can't actually set that through the CLI; you'd have to import a loving XML file in and I wasn't gonna do that for just this one problem. So I start looking into the *-scheduledtask* cmdlets (side bitch: Set-scheduledtask and new-scheduledtasksettingsset are names that are FAR too similar gently caress you microsoft).

The long and short of it is, if I want to configure this in powershell I have to first define a variable = new-scheduledtasksettingSet with the proper parameters, and then use that cmdlet as a parameter itself in set-scheduledTask. Which makes it frustrating to figure out when you're approaching a new problem. Turns out microsoft is doing a lot of this sort of thing though, as a bunch of AzureCLI poo poo is the same way (you can't just run like new-azureVM, you have to pass it a bunch of parameters that are themselves cmdlets in order to configure things like memory, network adapters, etc).

I'm happy now though, this was the last bug to fix and now the project builds all the way through :3

# ¿ Feb 14, 2017 06:07

Jowj: Dec 25, 2010; My favourite player and idol. His battles with his wrists mirror my own battles with the constant disgust I feel towards my zerg bugs.

anthonypants posted:

You can make a scheduled task once and then export the XML though.

You absolutely can, but I was irritated by having to do that for this one thing so I was trying to work around it. I think if I had started from the beginning that's the way I would've gone. This way I learned something, though!

# ¿ Feb 14, 2017 17:21

Jowj: Dec 25, 2010; My favourite player and idol. His battles with his wrists mirror my own battles with the constant disgust I feel towards my zerg bugs.

Briantist posted:

The be clear, the parameter values you pass are not cmdlets, they are objects that are generated by cmdlets.

This starts to make a lot of sense when the number and scope of objects starts to become really huge. The objects are instances classes, and the classes handle validation of the options. The class determines which options are valid together, which is something that might need to be evaluated at runtime.

In PowerShell this is possible with dynamic parameters but they can be flaky and when you start to have lots of them that can't all be used together. Encapsulation just makes sense at that point.

Sometimes though, it's just the fact that the cmdlets are thin wrappers around existing APIs and classes (*cough* WSUS cmdlets).

Yeah this is a really good point. It makes *logical* sense when I think about it, its just frustrating when I'm trying to learn how to do something. However, can you elaborate more on this?

quote:

If your use cases are narrow enough in scope and used often enough, you should write a function that takes only the parameters you need to specify that wraps the whole process.

I'm not sure I'm following what you mean here. Do you have an example I could look at?

# ¿ Feb 15, 2017 20:25

Jowj: Dec 25, 2010; My favourite player and idol. His battles with his wrists mirror my own battles with the constant disgust I feel towards my zerg bugs.

thebigcow posted:

You can make functions that themselves behave like cmdlets. https://technet.microsoft.com/en-us/library/hh360993.aspx

If you really wanted to, you could make a function that takes what you feel is important in a scheduled task as parameters and then does all the work for you. The problem with this is that after you learn the scheduled task cmdlets well enough to make a function to handle them you may feel like you don't need one at all.

OH, yeah I already do that. I thought there was something more complex I'm missing. Thanks for clarifying! That snippet of code I posted earlier is actually within a function, I just sanitized it. I'll post when I get home if I remember to show the full thing.

# ¿ Feb 16, 2017 00:05

Jowj: Dec 25, 2010; My favourite player and idol. His battles with his wrists mirror my own battles with the constant disgust I feel towards my zerg bugs.

Seconding splatting - it makes poo poo so much easier to read.

# ¿ Jan 3, 2018 22:39

Jowj: Dec 25, 2010; My favourite player and idol. His battles with his wrists mirror my own battles with the constant disgust I feel towards my zerg bugs.

What issue is moving the line out of the foreach block solving? I'm sort of confused as to what the end goal is.

code:

$shitheads = (
    "methanar",
    "a big pile of garbage",
    "jowj",
    "submarine sandpaper"
)
foreach($shithead in $shitheads)    {
    $someText = "hi this policy is dumb, how else will i know which $shithead to blame?"
    Write-Host $someText
}

this works just fine and is a fuckload more readable than setting the variable scope or anything outside of the loop unless i'm missing something.

# ¿ Nov 12, 2018 20:16

Jowj: Dec 25, 2010; My favourite player and idol. His battles with his wrists mirror my own battles with the constant disgust I feel towards my zerg bugs.

Submarine Sandpaper posted:

It's not solving an issue and the $ExecutionContext.InvokeCommand.ExpandString($description) has potential security concerns but I don't get paid enough to care or fight. I got to learn something new which is cool though. The next review may tell me to revert it due to the security concerns, which I'll then function it or do the replace like Commando.

Ah. I've been there. Good luck and glad you're learning poo poo

# ¿ Nov 12, 2018 20:24

Jowj: Dec 25, 2010; My favourite player and idol. His battles with his wrists mirror my own battles with the constant disgust I feel towards my zerg bugs.

I'll echo The Fool, that's what I would do. I will mention a weird finnicky thing:

code:

$jsonObjects = # pretend this is valid json that when converted from json has a name property.
$workingObjects = $jsonObjects | ConvertFrom-Json

# this must exist on a new line. I don't know why. 
# ConvertFrom-Json must just....not finish processing before piping fwd?
$workingObjects = $workingObjects | select -ExpandProperty name

To make sure that makes sense: ConvertFrom-Json must be the last section of a pipeline; i cannot pipe its output further along in one line, I have to split it up. its weird.

# ¿ Jan 10, 2019 20:03

Jowj: Dec 25, 2010; My favourite player and idol. His battles with his wrists mirror my own battles with the constant disgust I feel towards my zerg bugs.

Methanar posted:

json is more readable than yaml.

fight me

i guess maybe depending on what you�re doing?

for �never needs to be human edited� usecases, ok maybe.

for like, configuration files that are always human edited though json loses because of comments

# ¿ Jan 13, 2019 16:21

Adbot: ADBOT LOVES YOU

# ¿ May 20, 2024 15:21

Jowj: Dec 25, 2010; My favourite player and idol. His battles with his wrists mirror my own battles with the constant disgust I feel towards my zerg bugs.

Strict checkers of json data / proximity to the thing you actually wanna comment IMO.

For instance: If you want to do something like configure an IAM policy in AWS through JSON, you can't just add a json key called "comment"; aws only allows certain keys within the thing. Which is a real pain if something is counter-intuitive and you want to comment it for posterity! You just! Can't!

loving json.

# ¿ Jan 16, 2019 18:03

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Powershell Megathread: Verb-Noun Scripting is the future