1. Active Directory cmdlets
The PowerShell Active Directory module introduces
over 70 cmdlets to provide full support for almost any Active Directory
function an administrator might require. But before you can use this
newfound power, you either have to import the module or use the Active
Directory Module for PowerShell. The easy path is to use the AD Module
for PowerShell, but some people like to do things the challenging way.
To get the Active Directory cmdlets in your active PowerShell window,
type in Import-Module Active Directory. You can then check to see if it was imported properly by typing Get-Help *ADA*. If the get-help cmdlet returns some Active Directory commands, then you can be sure that the Module was installed (see Figure 1). Table 1 lists some Active Directory User focus cmdlets.
Table 1. Active Directory User Focus cmdlets
| cmdlet Name | Description |
|---|
| New-ADUser | This
cmdlet creates a new Active Directory User. Requires only a name and
will populate the rest of the fields with default values for you |
| Set-ADUser | This cmdlet sets/modifies the properties of the specified ADUser |
| Get-ADUser | This cmdlet gets an object representing the ADUser |
| Remove-ADUser | This cmdlet removes/deletes the specified ADUser |
If you actually want to list all the Active Directory cmdlets, then at the PowerShell prompt, type Get-Command *AD* and hit enter.
We must warn you that there are a lot of them. Now that the power is
within your grasp, you must learn to use it properly, or else great
destruction and loss of job could ensue. As soon as people hear you
have the power, requests start coming in for you. The first cry for
help comes from accounting. “Help brave superhero! We need you to
create a new user account in AD for us” is the call for help. An e-mail
arrives right afterward with all the details. The message reads, “Dear
Superhero,” we need a new AD User account for a new employee named
Justin Michaels. You keep in mind the first initial last name naming
convention that the company adheres to and quickly start on the task.
You type New-ADUser –Name “Justin Michaels” –SamAccountName “JMichaels”
and hit enter. This will create a basic user with the name of the User
object as Justin Michael and the SamAccountName as JMichaels. The only
mandatory field in the New-ADUser cmdlet is the –Name flag. If you
leave that out, then you will get a prompt asking for it. If you only
provide the –Name field and leave the SamAccountName out, the
SamAccountName will be populated with the –Name value by default. This
is because you need to have a SamAccountName for an Active Directory
User to exist. When the cmdlet executes, it will have created a new
Active Directory User for you. If a user with the same SamAccountName
already existed, you would have gotten an error similar to how you get
an error when trying to duplicate a user in the Active Directory Users
and Computers GUI, and would have had to create him with a
SamAccountName of JMichaels02 or as what the company naming convention
dictated. You can check that the account you created exists by using Get-ADUser “JMichaels” and hitting the enter key (see Figure 2). This created a very basic account with almost nothing populated.
You
could also have created the user from a template. This would allow you
to have a large amount of values already set consistent with the
company policy and only change the necessary ones for the user. In the
previous example of Justin Michaels, the account has all the default
values for password expiration, change at next log on, etc. With a
template, you would be able to specify universal properties for all new
users as long as you create them all from the same template. Imagine
you have a ADUser you created and populated completely with all the
default values for any new account. When the time comes to create a new
account, all you would have to do is to use the –Instance flag to
specify the new user. Assume that you decided to create user “Justin
Michaels” from the “New Guy” template, this is what you would do.
$templateAccountHolder = Get-ADUser –Identity “Nguy”
New-ADUser –Name “Justin Michaels” –SamAccountName “JMichaels” –Identity “JMichaels”
This would create the new user Justin Michaels using
Nguy as a template. In essence, you are taking all his set properties
and changing the ones you want for the new user you are creating. Once
you have finished creating his account, you realize you did not specify
his e-mail, and that Nguy@SuperTechs.com, the default one from the template, does not really work. It is time to use your skills again. You type Set-ADUser –Identity “JMichaels” –EmailAddress “JMichaels@SuperTechs.com
and hit enter. When the cmdlet executes, you will have updated or set
the e-mail for that user to the desired value. After clearly overcoming
your first task, you check your inbox for the next one and click on it
as soon as it arrives. A message comes in with a simple, yet sad
request. You are to delete the account for the user Jason Todd with
identity Jtodd. According to the message, he is no longer with the
company, and therefore his name must be removed from Active Directory.
You put your skills to use again and type Remove-ADUser -Identity JTodd and hit enter. You hit Y to confirm his deletion and then his name will cease to exist (see Figure 3).
You have now touched on the basics of the AdUser
operations in AD. The full potential of these cmdlets is astonishing to
say the least. But with the knowledge of these basic blocks, you can
accomplish great things. Always keep in mind that when a cmdlet asks
for the identity of a user, you will need to specify one of a few
specific things. For identity, you can use the Distinguished Name (DN),
the Global Unique Identifier (GUID), Security Identifier (SID), or the
Security Accounts Manager (SAM) Account Name. All these fields have
flags that correspond to their names like the –SAMAccountName flag.
Table 2 lists Active Directory group focus cmdlets.
Table 2. Active Directory Group Focus cmdlets
| cmdlet | Description |
|---|
| New-ADGroup | This cmdlet creates a New Active Directory Group. Requires the name and group scope fields to create the group |
| Set-ADGroup | This cmdlet is used to set/modify existing properties of the ADGroup |
| Get-ADGroup | This cmdlet gets an object representing the specified ADGroup |
| Remove-ADGroup | This cmdlet removes/deletes the specified ADGroup |
Your
skills still need to grow in the area of Active Directory Groups. The
next task that comes in proves to be the perfect testing ground. The
new task being delegated to you is to create a new distribution group
for all the users of special talents like yourself. You type New-ADGroup –SAMAccountName “Supers” –GroupCategory 0 –GroupScope 0 and hit enter.
The cmdlet will execute and create a new group for you with all the
default values, except for the ones you specified. The –GroupCategory
flag is what determines if the group is a security group or a
distribution group. A value of 0 is set as a distribution group, while
a 1 is set as a security group. The default value is 1, security group,
if the flag is left off. The –GroupScope flag 0 corresponds to
domain-local, while 1 is global and 2 is universal. You could have
simply typed New-AdGroup and hit
enter and it would have worked as well. It would then have prompted you
for a Name and a group scope. It would be fast and easy, but some of
the default values are not what you want. The Name would then be used
as the SAMAccountName as well, and you would have had to go back and
modify the group and change it to a distribution group since that is
what you wanted. To do this, you would have needed to use the
Set-ADGroup cmdlet by typing Set-ADGroup Supers –GroupCategory 0
and then hit enter. Another way you can create a new Active Directory
Group is by using a different group as a template. Assume that you have
a security group called “AM Shift” that has everything set perfectly
the way you need it. Now, you have the need to create a new group
called “PM Shift” but want to use the same settings and properties of
the AM Shift group. This would save you all the trouble of
reconfiguring the new group to match the already existing one, or even
worse, you are not even exactly sure what all the properties are. You
just know that you need another group just like that one. This is the
perfect example of why you would use the first one as a template. This
process is almost identical to what you did with the ADUser you created
from a template. You start by declaring a variable and assigning the
template group to it and then using the –Instance flag with the
New-ADGroup cmdlet to accept the variable. This creates a new group
based on the instance of the old group with all the properties of the
old group, except for anything you add.
$groupUsedAsTemplate = Get-ADGroup –Identity “AM Shift”
New-ADGroup –Name “PM Shift” –Instance $groupUsedAsTemplate –GroupScope 0
You will also need to specify the –GroupScope of the new group you are creating or it will prompt you for it.
You can check the properties of any of the groups you created by using Get-ADGroup Supers (see Figure 4).
As
you get more familiar with the cmdlets, you can see that groups are
very similar to users in how you create them, get them, and modify/set
them. So, it will come as no surprise to you that to remove them is
just as simple. If you wanted to remove the group you just created, you
would type Remove-ADGroup Supers. Once you hit enter, you will get the confirmation screen and then it is done.
Table 3. Active Directory Group Member Focus cmdlets
| cmdlet | Description |
|---|
| Add-ADGroupMember | This cmdlet adds a user to specified AD Group |
| Get-ADGroupMember | This cmdlet gets the members of an AD Group |
| Remove-ADGroupMember | This cmdlet removes a user from a specified AD Group |
Now that you have created the group, you need to
move on to the next part of your task and add the users on the list to
the Supers Group you just created. You will be using the
Add-ADGroupMember cmdlet to accomplish your task. This cmdlet and some
other Active Directory group member focus cmdlets are described in Table 3. Typing Add-ADGroupMember is enough since PowerShell will prompt you for the mandatory values it needs (see Figure 5).
But since it is better to learn the common flags for when you are
writing your own PowerShell scripts and need to automate as much as
possible, you will type Add-ADGroupMember –Identity Supers –Members “JMichaels,” “CKent” (see Figure 5).
Once you have added the AD Users to the group with
the Add ADGroupMember cmdlet, you check to see that they made it in
properly by typing Get-ADGroupMember Supers and hitting enter (see Figure 6).
You finish adding all the members on the list to the
group and start to relax thinking you are done when an updated request
is sent to you. Apparently, one of the names in the original list
should not be added to the group. His name is going to be cleared with
the rest of the members before he is added, since apparently he is very
volatile. You have already finished adding all the names though, so the
only thing you can do is delete him from the group. You type Remove-ADGroupMember –Identity “Supers” –Member “BBanner”
and hit enter. A confirmation pops up and you hit enter. The named
member is no longer a part of the group. You reply to the request that
you are finished and get a heart-felt “thanks, you saved us.”
You are taking a breather when your next task comes
in. Clicking it you see that now that they are identifying these gifted
individuals, they are going to need a way to apply GPOs to them as well
as administer them separately from the rest of the users. You are
tasked with creating an Active Directory Organizational Unit for them. Table 4 lists some Active Directory Organizational Units focus cmdlets.
Table 4. Active Directory Organizational Units Focus cmdlets
| cmdlet | Description |
|---|
| New-ADOrganizationalUnit | This cmdlet creates a new Active Directory Organizational Unit (OU). You must specify a Name at the bare minimum |
| Set-ADOrganizationalUnit | This cmdlet sets/modifies an AD OU |
| Get-ADOrganizationalUnit | This cmdlet gets an object representing an AD OU |
| Remove-ADOrganizationalUnit | This cmdlet removes/deletes an AD OU |
Creating an Active Directory Organizational Unit is
simple for someone with your powers. Just like a new AD User or AD
Group, you can start one from scratch with as many default parameters
or specific parameters as you want or you can base the creation on an
already existing one using the –Instance flag. You start by typing New-ADOrganizationalUnit –Name “VeteranSupers” –ManagedBy “CKent”
and hit enter. When the cmdlet executes, a new OU will exist. OUs do
not have as many parameters as AD Groups or AD Users but they have one
parameter that is worth mentioning, the one set by the
–ProtectFromAccidentalDeletion flag. If this is set to True, then you
cannot delete the OU by normal means without first setting the
parameter to False. So, assume that the OU you created was not supposed
to be protected from accidental deletion, but by default it is and you
did not specify otherwise. You need to change the parameter with the
Set ADOrganizationalUnit cmdlet. The tricky part is that to set or get
an OU, you need to know its DN; its regular name will not work. Trying
any set or getting an OU using its name as its –Identity will fail. So,
you need to get a list that would include the OU you need and get its
DN from there. We know what you are thinking. Instead of going through
all this, why not just delete
it and create the OU again, this time with the flag specified as false?
It won’t let you because the flag is set to true. The name, however,
lets you look for the OU with a –Filter. You type Get-ADOrganizationalUnit –Filter “Name –Like ‘VeteranSuper’” | FT Name, Distinguished Name and hit enter. You see the DN and can now use that to call the Set-ADOrganizationalUnit cmdlet.
Your DN will be different since you are going to have different AD
environments, so for the italic part, just replace with your specific
value. You type Set-ADOrganizationUnit –Identity “OU=VeteranSuper, DC=smeekers,DC=com” –ProtectFromAccidentalDeletion $false
and hit enter. When the cmdlet executes, the property will be updated
and VeteranSuper OU will no longer be safe from deletion, accidental,
or otherwise (see Figure 7). You decide to test it and type Remove-ADOrganizationUnit –Identity “OU=VeteranSuper,DC=smeekers,DC=com” and hit enter.
Once the cmdlet executes, the OU is gone. You create
the OU again, this time with the deletion protection absent. The
request has a list of users that needs to be moved into the OU. You
decide to get started right away.
You look at the list and it contains both users and
groups. You smirk and get down to work right away. To add the requested
users and groups to the OU, you will be using the Move-ADObject cmdlet.
This cmdlet is described in Table 5. You start by moving a user on the list to the VeteranSuper OU. You need to get the Identity of the user, so you start by
using the Get-ADUser cmdlet to show the DN and GUID, since you can use
either as an identity. If you still have the DN of the OU handy from
earlier, you won’t need to retrieve it again. If you need to get this
DN again, use the Get-AdOrganizationalUnit cmdlet as you did before.
Once you have both Identities, you type Move-ADObject -Identity “CN=Bruce Wayne, CN=Users, DC=smeekers, DC=com” –TargetPath “OU=VeteranSuper,DC=smeekers,DC=com” and hit enter (see Figure 8).
Table 5. cmdlet Used to Move Any Active Directory Object
| cmdlet | Description |
|---|
| Move-ADObject | This cmdlet moves an Active Directory Object specified by its DN or GUID to a specified location |
When the cmdlet completes, user BWayne will be part
of the VeteranSuper OU. You continue moving some of the other users and
then have to move a group. You use the same cmdlet, only this time you
use the DN of the group. You Type Move-ADObject –Identity “CN=Supers, CN=Users,DC=smeekers,DC=com” –TargetPath “OU=VeteranSuper, DC=smeekers,DC=com” and hit enter. When the cmdlet completes, the Supers Group will also be part of the VeteranSuper OU (see Figure 9). You finish all the moving you need to and reply that the task is complete.
The
day is almost done and you are about to hang up your cape when a final
request comes in. The user Justin Michaels needs his password changed.
Password operations are a very common request, and they require one cmdlet for setting or resetting (see Table 6).
The main difference is that if you use the –Reset flag, then you do not
have to worry about the old password. You type Set-ADAccountPassword
–Identity “JMichaels” –Reset – NewPassword (Convert-To-SecureString
–AsPlainText “JMichaels@1” –Force) and hit enter. His password has been
reset to the company-dictated reset. You then set his user account so
that he has to change it next time he logs in by using the SetADUser
cmdlet as follows: Set-ADUser “JMichael” –ChangePasswordAtLogon $true. The last request of the day is done.
Table 6. cmdlet for Setting and Resetting Passwords
| cmdlet | Description |
|---|
| Set-ADAccountPassword | This cmdlet is used to set or reset an account password. Setting involves knowing the old password while resetting does not |
