In my last post, I wrote about how setting the Execution Policy is not a viable security countermeasure, and is very easy to bypass by malicious actors. The examples provided work when the Execution Policy is set by running "Set-ExecutionPolicy"; however, it does not bypass an Execution Policy set by Group Policy.
This post will demonstrate a way to get around that as well.
Read MoreWhile there are some benefits to signing your PowerShell code, security really isn't one of them. If something is run on your system that attempts to execute a malicious PowerShell script, it does not matter what your Execution Policy is set to.
Read on for a brief explanation of what Execution Policy actually affects, and a demonstration of how easy it is to bypass.
Read MoreWhat do you do when you find your network file share permissions are a little...weird? That when you go to add permissions to a folder, some of the sub folders still remain out of reach? Then, when you check them manually, you find that someone, at some point, disabled inheritance on that folder, and for no good reason. Or, worse, someone set up the shares with a bunch of severed inheritance, mainly because they didn't know how to manage folder permissions well.
Whatever the reason, knowing where inheritance is severed in your file shares is not only useful, but critical to properly manage your shares. To discover those inheritances, just go through each folder, one by one, and write down each one tha...
Wait! There's got to be a better way to do this!
Fortunately, Get-Acl is here to help. The AccessControl.DirectorySecurity objects it returns for folders has a property called "AreAccessRulesProtected", which when set to True, means inheritance is disabled. So, I wrote a quick script to help locate and document this. Note that you will need to be using an account with at least read permissions to all of the folders you are targeting; also, I've done this for a single server with multiple shares, each share I've put in a text file. It will be easy to modify that as you need.
I was watching this video from Neil deGrasse Tyson where he explains just how rich Bill Gates is (it's a fun video to watch, check it out here: http://9gag.tv/p/a5XWnk/watch-neil-degrasse-tyson-explain-how-rich-bill-gates-is). In it, he talks about how old you will be when you've reached your billionth second (it's close to 32 years, BTW), and mentioned having taken the time to compute this, and that someone will probably write an app to do this.
So of course, I said "that should be easy enough for PowerShell!". It was. Ridiculously easy, in fact. So, for some fun, you, too, can quickly calculate when you can celebrate your billionth second! (I used some sample data not actually linked to anyone's birthday that I know)
Note that the time is in 24 hour format (though you can use 12 hour format by adding AM or PM to the end), and that the date is the US standard format, so if your localization is different, you'll probably need to use your localized standard.
Whoever has the above birthday will celebrate their 1 billionth second on Saturday, April 24, 2021 at 7:41:40 PM.
Anyone who's managed Active Directory long enough can tell you that one of the most (if not the most) important thing to a healthy AD is healthy DNS. While forwarders won't likely be a huge cause for AD problems, it's still nice to make sure your servers are configured in a consistent manner, and since forwarders can be set per DNS server, you'd have to log in to each and every one to verify the settings on it. Fortunately, PowerShell can help (but only if you're running Windows 8/Server 2012 or newer; don't worry, though, the target servers can be 2008 R2, though it does have to be Microsoft DNS (sorry, BIND users!)).
Note that if you supply the name of your domain, you should get back a list of IPs of all of your AD/DNS servers. If this is not the case, then you likely have bigger issues with DNS to resolve first. If you for some reason separate your AD and DNS servers, then you may have to do something else to get the list of servers. Also note that my idea of having all forwarders be the same is not necessarily a one-size-fits-all; there are times and places when having them be different for some servers makes sense. Even still, being able to quickly and easily document these settings could be a huge time saver, especially if you have a large environment.
Forwarders aren't the only thing you can get with Get-DNSServer; you can see just about any setting on the server with that. I recommend firing it off by itself against a single DNS server to see what all it gives you, and you could easily modify this snippet to document just about any setting in there that you want.
EDIT 5-18-2015: I've modified the part of the script that gets the name servers and makes it actually capture the name servers and not just assume that the A records for the domain will be a full list of name servers.
If you've run the Best Practice Analyzer (or BPA) for Active Directory Domain Services (ADDS), you may get the following warning: "All OUs in this domain should be protected from accidental deletion". Depending on the size of your domain, going through all OUs to check that could sit on your list of things you want to do somewhere between "Mindbogglingly boring and waste of time" and "SHOOT ME NOW!". Thankfully, this, too, can be done through PowerShell:
Here's where I tell you that this makes changes to your AD environment, and while there should be no ill consequences for this one, do take proper precautions; before running it, you should also just run the first two lines by themselves (minus the last pipe) to see what you'd be changing.
Other than that, this is another really simple, fairly self-explanatory snippet.
This one requires PowerCLI to work, and you will need to connect to your vSphere server first; I wrote this one to see what servers had which network adapters configured so we'd know which ones could be upgraded to VMXNET 3. This could easily be modified to capture just about any information you want, just by digging in to the VM objects a bit.
That's it; there's not much to this one other than what you see. Use in good health.
EDIT: Well, this is embarrassing. You could easily do the above faster and better with "Get-NetworkAdapter (Get-VM)". Well, this will work if you don't have Get-NetworkAdapter in your version of PowerCLI, or you could modify the above to target info that's not as readily available via cmdlet.
EDIT 2: "Get-NetworkAdapter (Get-VM)" won't show which server they're connected to, so I guess there is still use for my script. I may circle around and update it using Get-NetworkAdapter, but for now, there you go.
Testing Group Policies can be a chore if you have a lot of them, especially if you need to link a long list of GPOs to one OU that are linked to another OU. You could do this via the Group Policy Management console, but that can be time consuming, and you could wind up linking the wrong GPO or missing one if you're not careful. So, let's script it, instead!
You will need to have the AD RSAT tools installed, and have the GroupPolicy module. I've only tested this on Windows 8.1 with PowerShell V4, so your mileage may very (and, as this is one I've marked as "Dangerous", you absolutely should test this before using it in production, and be VERY careful: linking GPOs in the wrong place could have very bad adverse effects).
I highly recommend playing around with the output stored in $gpos; as you can see, what you want is nested fairly deeply ($gpos.gpos.gpo[*].LinksTo.SOMName).
Note that the SourceOU is the name of the OU itself, while DestinationOU is the full LDAP name.
I do very much recommend playing around with this on a test environment before going to town in production.
EDIT (2019-01-22): I didn’t spell this out, but this method will only work if the source OU name is unique on your domain. ColdPower in the comments below mentions an alternative way to get the GP links that will work with the full DN of the source OU, and will work a lot faster (especially if you have a lot of GPOs and GP links)
Someone else commented how this doesn’t copy additional properties like enabled state, permissions, etc. I didn’t approve it as the comment was rather rude and I’m not into that, so I’ll just respond up here instead. That is true, and it’s something to consider if your GP links are more complicated. I’ll again reiterate that I do very much recommend trying this on a test environment before using it in production. That includes finding and dealing with cases where the copy won’t be perfect. I didn’t share this as a heavily tested and battle tried method that should work in all circumstances. I don’t have one of those as my need for this sort of thing is very occasional and if I run into a few minor extra tweaks I need to make after, it’ll still be faster than accounting for it in the script at this point for me. I may come back and revisit this at some point in the future, if I feel up to it, and make it a much more comprehensive solution.
This is another one of those quick and dirty snippets to solve a problem or answer a question (I'm a real fan of those); it could easily be modified to create a much more professional looking report.
I was asked to go through a file server share and find out who had access to what at a pretty basic level; mostly, we're comparing groups in an old domain to make sure the corresponding groups have been set in the new domain, but this can be tweaked to help answer many questions.
I'm positive there's a better way to target only domain permissions without calling them directly, and when I find it, I'll come back and update this post; but for now, this works. Note that to strip out inherited permissions, you will need at least version 3 of PowerShell (that property isn't returned by v2's Get-Acl).
Depending on the size of the file shares you target, this will very likely take a long time to complete, and could give your shell a nice, very large memory footprint, so you'll want to watch for that. Once you have the output, though, you could easily do some quick manipulation in the shell, or export it to CSV and load it up into Excel to analyze it with pivot tables (the best reason for keeping Excel around, in my opinion).
Oh, and you will need access to read permissions on everything for this to actually work.
Update: There were issues with the original iteration of the snippet, mostly in that the output got messed up somehow when dealing with large-ish data sets (like you'd expect from any file server that's been in production for a length of time): it seemed to get "stuck" (for lack of a better word) on security principals and just list permission after permission tied to the same principal (which a quick sanity check against the file or folder's actual permissions showed to be false). I solved that by outputing each object to a temporary csv file, then importing it back at the end of the process, rather than hold everything in a variable while it worked.
The best way to do this is through Group Policy Preferences, but sometimes, we just need something quick and dirty. If you have Server 2012 or Windows 8 (or newer), you have access to such wonderful cmdlets as Get-Printer and Remove-Printer to help you out; most of us, however, still have to work with Windows 7 and Server 2008 R2 frequently. Fortunately, there's a way to do this using WMI, and I've written a quick snippet to show that off.
In my example, I needed to remove all of the printers on a server that came from one particular print server, and Group Policy wasn't really a good option at the moment. Note the 4 backslashes at the beginning and 2 at the end; this is because of how WQL queries work, meaning you have to do a double backslash for every backslash to escape them.
You can also use SystemName instead of Name in the filter; if you do, leave off the ending backslash (or just leave all backslashes off; it should work just fine that way).
Warning: this code could potentially cause unexpected and bad results if you aren't careful. I highly recommend testing before you use, and checking to make sure you've actually captured only the printers you want to remove by taking a look at what's in $printers before you run the last part (just do "$printers | select name" to see what printers you've targeted).
This is very crass and simplified, and frankly, other programs (such as Angry IP and (my personal favorite) NMap) do a much, much better job; however, if you need to do a scan in a script for whatever reason, this may do the trick. It would be very easy to make any changes to this you'd like, such as leaving out DNS resolution, or swapping it for a WMI query, or adding just about anything else you want. This is just a quick, dirty example, and as such, it doesn't have a lot of polish. (Note: as-is, this code requires Windows 8 due to Resolve-DnsName not being included in prior versions)
If you want to run this on Windows 7, here are two methods of resolving DNS names that work:
Using .NET methods (my preference):
Windows PowerShell One Liner: Name to IP Address
Using nslookup (more work to get the output you want, but always a good tool):
PowerShell v2 And DNS Queries
If you've ever run into a situation where you know you won't be needing those pesky first or last lines in a text file (this also works for other arrays, BTW), then this is a quick and easy way to get just what you're looking for:
Explanation: you can call a particular object by the index, or in this case, a particular line in the file. Remember, the index number will be one number lower than the line number, because the index starts at 0, so line 20 will be at index 19, or $test[19].
You can also call a range of indices, such as to get lines 1 through 5, you would use $test[0..4]. You can use a variable number to specify the index as well, such as $test[$index].
Put this all together, and you can strip the last line out of your variable with:
Since the count is going to be the full number of lines, $var.count - 1 would be the last line, so you want it to stop at the next to last line, or $var.count - 2.
Removing the first line is likewise simple, with just a tiny modification:
If you need more than one line off of either side, just tweak the numbers. Simple!
Sometimes when troubleshooting a problem, all you have to go on is an approximate time it happened (for instance, a report that a service was running slowly). Going through all of the event logs by hand can be time consuming, but luckily, PowerShell can do that for you!
I ran into this scenario this morning, so the times on my snippet will reflect that:
I've multi-lined it to make it more readable. Basically, it's getting a list of all of the Event Logs that PowerShell has access to, then expanding that list (so I get a list of strings rather than objects), and passing it to foreach. Then, I can pass the current log name to Get-EventLog using the current-item variable $_, and tell it that I want to see what happened between the -After and -Before times.
Note: if you don't run this as Administrator, you'll get an access denied error when it tries to read the Security log; however, if you don't suspect what you need is in there (it probably isn't), this is actually a good thing as Security can be rather noisy without much useful information.
