Week 3: Active Directory Power

DISCLAIMER: This was originally a way to document what I was learning when I first ran into PowerShell as a student who had no prior scripting experience. The examples given and the posts done in relation to the project most likely do not follow best practices and should definitely be reviewed if they are going to be used in any fashion. You have been warned! ūüôā

The Active Directory is the administrative flagship of Windows platforms. User creation, group creation, permissions, shares, etc. it has it all. What happens if you need to create multiple users because a flurry of new employees and/or interns need to be in the system? What happens when chunks of that list need to be part of certain groups? You can painstakingly take the time to do this manually by way of GUI, or be awesome and use PowerShell!

What is this post about?

  • The Active Directoy
  • New-ADOrganizationalUnit
  • New-ADUser
  • New-ADGroup
  • Super Simple Script III
  • File Permissions
  • Mistake of The Week

The Active Directory

Import-Module ActiveDirectory

This module hosts the cmdlets of what we will be covering on Active Directory basics. You need Active Directory Services installed on your test Windows 2008 R2 server. If you have those services installed, and you still cannot load this module in PowerShell, then you need to do some ServerManager voodoo.

Import-Module ServerManager
Add-WindowsFeature RSAT-AD-Tools
Get-WindowsFeature RSAT-AD*

If you AT LEAST see RSAT-AD-PowerShell and RSAT-ADDS enabled, then you should be set. Now import the ActiveDirectory module! All set? Let’s take a look at everything you are able to do with this module:

Get-Command -Module ActiveDirectory 

For this basic runthrough, we will only go over a few from the massive list that shows up.


For this post, we are going to assume you’ve named your domain tacotime.com, because I can’t imagine naming it anything else at the moment. In PowerShell, you usually refer to the FQDN (Fully-Qualified Domain Name) like this:¬†“dc=tacotime,dc=com”. So let’s make that into a variable for ease-of-use:

$taco = “dc=tacotime,dc=com”

Now let’s start with making an Organizational Unit (OU) to split up our new employees:

New-ADOrganizationalUnit Interns -Path $taco
$interns = “ou=interns,$taco”
New-ADOrganizationalUnit FTE -Path $taco
$fte = “ou=fte,$taco”¬†

For simplicity, we made an Interns OU and FTE (full-time employee) OU to throw our users into. We also assigned variables to simplify further commands.


Now let’s make a user for each OU:

$secstring = (ConvertTo-SecureString -AsPlainText “1234abcd$” -Force)
New-ADUser jcheese -GivenName Jay -Surname Cheese -Enabled $true -path $interns -AccountPassword $secstring
Set-ADUser jcheese -ChangePasswordAtLogon $true
New-ADUser ebeef -GivenName Extra -Surname Beef -Enabled $true -path $fte -AccountPassword $secstring
Set-ADUser ebeef -ChangePasswordAtLogon $true

The first variable I made was to create a securestring out of the default password we are giving our users, 1234abcd$. The -Force at the end is used because otherwise the password doesn’t meet default minimum password requirements for an AD user password. After that, I created each user by starting with the username they will logon with, their fullnames, account enabled, and default password (being the variable we defined).¬†Even trying to view the contents of the $secstring variable gives you only the following output: System.Secure.SecureString

Though, we did make sure that the user must change their password at logon (which is why we forced a default logon that doesn’t meet requirements). If this was a brand new OU with all new users, like in our case, one command could apply it to all users within the OU:

# Make all users in $fte change their password at logon
Get-ADUser -Filter * -SearchBase $fte | Set-ADUser -ChangePasswordAtLogon $true

New-ADGroup & Add-ADGroupMember

Now let’s make some groups to throw our respective users in. Groups make permissions much easier all-around. Instead of adding a mass list of users to a folder for read and execute, for example, you could just place them all in a group. Simply add the group with the correct permissions to the folder, and then you’re set. I won’t go into what group scope is here, but I will simply use Global for this post.

New-ADGroup FTEs -GroupScope Global -path $fte
New-ADGroup Interns -GroupScope Global -path $interns

Here we made two groups, FTEs and Interns, in their respective OUs. Now we just need to add the users to their groups!

Add-ADGroupMember FTEs ebeef
Add-ADGroupMember Interns jcheese 

That was pretty easy. To add an individual user to a group, you easily do it with that command.

Super Simple Script III

# Prompt user to enter the ADUser, and add them to an ADGroup
Import-Module ActiveDirectory
$dagroup = Read-Host “What group are we adding to”

$dauser = Read-Host “What user are we adding to $dagroup”
Add-ADGroupMember $dagroup $dauser
[System.Windows.Forms.MessageBox]::Show(“$dauser was added to $dagroup”, “Done”)

Here we loaded a form from the .NET libraries for our confirmation window at the end. Keep in mind, that our scripts currently do NOT have error-checking and would give a big thumbs-up even if the script failed. This script could fail due to an incorrect user/group, or if the¬†individual¬†running the script doesn’t have permissions for this Active Directory administration.

File Permissions

Folders can have access given to people that only limit them to reading and executing what is within a folder. We can now use one of our groups to give interns read-access to a folder with directions to using the coffee maker.

$intcoff = “C:\Important\Coffees”
Get-Acl $intcoff

This shows us who has full control, readandexecute, modify, etc. permissions for a folder. We want to add our Intern group to that list! So first, we must make a copy of the current ACL (or really, security permissions list) and then add the precious interns.

$acl = Get-Acl $intcoff
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(“Interns”,”ReadAndExecute, Synchronize”,”Allow”)
Set-Acl $intcoff $acl

In this four-line script, we defined a variable with the current list and then made a new rule giving interns ReadAndExecute before adding the new rule to the $acl variable. Afterward, we applied the new permissions to our Coffees folder. Whew, that was complicated.

Mistake of The Week

I just said that the whole Set-Acl cmdlet was complicated, right? Well, guess what? That is where my Mistake of The Week deals with. I originally didn’t know I needed to copy¬†the current ACL before adding the new access rule. What I did looks just like the previous four commands, but with $acl not even defined.

$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(“Interns”,”ReadAndExecute, Synchronize”,”Allow”)
Set-Acl $intcoff $acl

This resulted in me completely replacing the current ACL with only one group that can ReadAndExecute: Interns, in this case. Suddenly, the folder couldn’t be moved, deleted, or added to by anyone. Anywhere. FOREVER.

Please don’t do that. Try to think logically before making an attempt like that…instead of blind, gleeful cmdlet-typing.

Next week I should finally delve into throwing error-handling into scripts. It’s pretty awesome! The examples will include improving the previous Super Simple Scripts we have created. See you next week!


Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s