Microsoft’s PowerShell (PS) management framework developed for systems management and automating administrative tasks extends far beyond simply replacing the venerable command line shell. No, PS offers much more by integrating with services and applications to provide holistic management of clients and servers alike.
As the underlying framework is updated, new, more powerful functions will become available. PS is further enhanced by importing modules of support services, such as Active Directory (AD), which allows admins greater control over the devices and user accounts stored in AD, for example. This capability expands to all facets of maintaining the directory services, including controllers and domain services.
Before diving into the cmdlets, there are a few requirements that must be met to ensure that AD cmdlets are available and fully supported:
- Administrative PC with Windows Vista installed (or newer)
- Remote Server Administration Tools installed on administrative PC
- Server with Windows Server 2008 (or newer)
- Active Directory Domain Services Role installed on server
- Windows Management Framework 3.0 (or newer)
- Switched network (Required for most cmdlets to function properly)
- Broadband Internet Access (Optional, but recommended)
- Domain Admin credentials
SEE: Windows administrator’s PowerShell script kit (Tech Pro Research)
Accessing Active Directory cmdlets
Start by importing Module Active Directory.
Before being able to run any of the cmdlets that allow for managing AD, the corresponding module must first be imported to the current PS session. Once this has been done, AD cmdlets will now be loaded and within your control.
Note: you must perform this each time PS is run before AD-specific cmdlets will become available.
1. Create computer object
To create a new computer object in a specified organizational unit (OU), enter the cmdlet:
New-ADComputer -Name "ComputerName" -SamAccountName "ComputerName" -Path "OU=Computers,DC=Domain,DC=com"
specifying the object’s name for both the -Name and -SamAccountName parameter. Do not forget to include the distinguished name (DN) in quotes after the -Path parameter, which designates where the object is to be created.
This is especially useful when managing multiple sites and/or domains, particularly when scripting changes to AD such as with new account creations, which may be linked to new hires when on-boarded by human resources.
2. Create new security groups
Enter the cmdlet:
New-ADGroup -Name "Security Group Name" -SamAccountName "SecurityGroupName" -GroupCategory Security -GroupScope Global -DisplayName "Security Group Name" -Path "CN=Groups,DC=Domain,DC=com" -Description "Brief description of the what security group is used for"
This cmdlet aids in the creation of such groups, which ease administrative overhead considerably. Managing accounts, and computers is made much easier when applying role-based management settings to security groups versus making changes to each and every account and object singularly.
3. Create a new user account
Enter the cmdlet:
New-ADUser -Name "User Account Name" -SamAccountName "UserAccountName" -AccountPassword (ConvertTo-SecureString "password" -AsPlainText -Force) -DisplayName "User Name" -Enabled $True -GivenName "FirstName" -Path "CN=Users,,DC=Domain,DC=com" -Server "controller.domain.com" -Surname "LastName" -UserPrincipalName "username@domain.com"
Creating and managing user accounts go hand-in-hand when AD serves as the backend to an organization’s centralized infrastructure. Generating new user accounts can grow to be a tedious task, given all the numerous parameters and text fields present. And while not all are required, many are certainly useful when populated, such as email and title to name a few.
A whole host of these attributes can be configured by adding the -OtherAttributes parameter and pairing it with the attributes you wish to configure, such as the former: @{title=”job_title”;mail=”username@domain.com”}, for example.
4. Create a new OU
Enter the cmdlet:
New-ADOrganizationalUnit -Name "OU Name" -Path "DC=Domain,DC=com"
OUs are essential to managing user accounts and computer objects on the back-end of the network. Put another way, a properly set up Active Directory will include a well-designed set of OUs with, which to compartmentalize all the objects that AD centrally manages, making for an orderly, structured directory and one that will seamlessly lend itself to hardening the network while keeping it easy to manage.
Note: Cmdlets beginning with “New” connotate the creation of that object. When the task requires removal of an object, use the “Remove” prefix in place of “New.” Additionally, this works when you need to modify an object, instead using the “Set” prefix in place of “New.” The syntax for these cmdlets follow a similar format to that of the New-prefixed cmdlets listed above.
5. Add/remove users or computer objects to/from groups
Enter the cmdlet:
Add-ADGroupMember SecurityGroupName -Members Username01 -Server "controller.domain.com" Remove-ADGroupMember SecurityGroupName -Members Username01 -Server "controller.domain.com"
Once user accounts and computer objects are created, admins can choose to add them to existing security groups for added ease of management. By executing this cmdlet, the -Members parameter listing the accounts to be added will gain membership to the security group. When adding multiple accounts, these may be separated by a comma on a single line. Additionally, the -Server parameter though optional, will specify which domain controller to connect to for processing the changes. To remove members from a group, use the Remove-ADGroupMember cmdlet which follows a similar syntax.
6. Obtain the locally stored password from a computer object
Enter the cmdlet:
Get-AdmPwdPassword -ComputerName "computer.domain.net"
For organizations that have implemented Microsoft’s excellent (and free) Local Administrator Password Solution (LAPS), there is a cmdlet that can grab the password stored in the computer object within AD and display it in one easy-to-retrieve step versus scouring the database for each object to track down the ms-mcs-AdmPwd attribute.
7. Joining a computer to a domain
Enter the cmdlet:
Add-Computer -DomainName "domain.com" -Credential Domain\Username -Restart -Force
Joining a computer to the domain is one of the most common tasks IT pros perform, tens of thousands of times in their career lifetime. And while the task only takes a few minutes per machine, it can be run from PS to streamline and with a few tweaks, the entire process may even be fully automated. Just remember that the cmdlet–as detailed above –will prompt the admin for their password to complete the domain join before rebooting the device.
8. Enable/Disable users, computers, or service accounts
Enter the cmdlet:
Enable-ADAccount -Identity "ComputerName"
Disable-ADAccount -Identity “Username”
It is fairly obvious what this cmdlet does. It enables (or disables) a user account, computer object, or service account managed by AD to allow (or prevent) the user or computer account from being authenticated with or to on the network.
9. Unlock user accounts
Enter the cmdlet:
Unlock-ADAccount -Identity "Username"
It is often noted by statistical analysis that IT spends in ordinate amount of time resolving help desk calls relating to unlocking user’s accounts and resetting their passwords. The latter is covered above with the Set-ADUser cmdlet, however, the former is this specific cmdlet. This basically applies to accounts in which users have exceeded their password retry counters and have effectively locked their account from being used. Once unlocked, AD functionality (including authenticating the account) is made available again.
10. Locate disabled computer or user accounts
Enter the cmdlet:
Search-ADAccount -AccountDisabled | FT Name,ObjectClass
The Search-ADAccount cmdlet can be used for more than just finding disabled accounts. There are many parameters that may be invoked to effectively search AD and report back matching results. However, to highlight its functionality, I decided to go with the disabled accounts since it is an important and useful cmdlet to know.
To limit searches to a particular OU, the -SearchBase parameter followed by the DN of the path will be necessary. Additionally, to focus these results on a particular controller, the -Server attribute followed by the Fully Qualified Domain Name (FQDN) should be appended as well.
11. Repair a broken trust between a client and the domain
Enter the cmdlet:
Test-ComputerSecureChannel -Server "controller.domain.com"
A broken channel, as PS refers to it, occurs when the client computer has a broken trust relationship between the domain. It will cease to authenticate domain logins since the client and domain no longer have the channel setup, acting as a link between the two. The cmdlet above tests this relationship against the domain controller to verify that the link still exists. If not, adding the -Repair parameter resets this link between the two, reestablishing the channel.
This is by no means intended to be an exhaustive list of all the cmdlets available to systems or domain administrator’s, but rather a listing of cmdlets that are commonly used daily to manage accounts, modify objects, and get relevant information used to resolve issues that impact productivity.
