Managing Active Directory using PowerShell

I’ve been trying to do as much as I can in PowerShell these days.  I find it helps me learn better.  If I can figure out the solution in a few minutes through PowerShell then I’ll go off and use a GUI, but I’m getting a lot better and I find that I can usually figure out the PS solution pretty quickly now.

Among the various systems I am responsible for is Active Directory, and I have discovered that managing AD through PowerShell is really pretty fantastic using the AD module.  This will be the first of many posts I will write on the subject.  Each post will be based on a real world situation in which I used PowerShell to solve a problem I encountered.  Before I begin, note that you need to use the Active Directory PowerShell module to perform these tasks if you don’t want to get bogged down in LDAP syntax, which would sort of defeat the point of using PowerShell in the first place (it should be easy).  You can get the PowerShell module by installing the RSAT tools on Windows 7 or Windows 2008 R2.

A little note on preparation.  In order to use the AD module you need to import it first by using the following command:

import-module activedirectory

I use this module daily, and I hate having to type that every time I open PS.  On the flip side, I don’t like it to load unless I need it.  To get around that I saved the previous command to a file called load-activedirectory.ps1.  I then added the following line to my PS Profile.

set-alias ad c:\<path to scripts>\load-activedirectory.ps1

Whenever I want to load the module I just type “ad” and hit enter.

Now on to today’s problem.  It was actually pretty simple.  When HR terminates a user we disable the user account in AD and move it to a secure OU.  After a period of time it is automatically purged out.  The reason for the delay is for error handling and rollback, and today it came into play.  A user was accidentally marked as terminated in our HR system, which kicked off a workflow that ended with disabling the account and moving it to the aforementioned OU.  I was tasked with reversing out this error on the AD side.

For the sake of argument, we’ll assume that the user’s sAMAccountName was ABC123.  I need to re-enable the account and move it from the “Disabled Accounts” OU to the Users OU.

I decide to move the account back to the user OU first, the distinguished name of which is:

ou=users,dc=sweeneyops,dc=lab

To do this I issue the following command:

get-aduser abc123 | move-adobject -targetpath “ou=users,dc=sweeneyops,dc=lab”

Next, I decide to re-enable the account by issuing the following command:

get-aduser abc123 | enable-adaccount

All done!  Easy, right?  Once you get used to the syntax it’s easier than ADUC, and there’s all sorts of ways this could be mixed around and manipulated to support bulk adds/moves/changes.  Very cool if you ask me.  Ok, off to lunch!

Advertisements
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

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

%d bloggers like this: