With Windows PowerShell Scripting being one of the requirements in the current Common Engineering Criteria (CEC), all Microsoft server products need to comply with having Windows PowerShell scripting support. While some Active Directory technologies have not yet adopted PowerShell (Active Directory Certificate Services, for example), Active Directory Domain Services has adopted this criteria wholeheartedly in Windows Server 2008 R2.
In post 6 in this Command Fu series, I think it’s appropriate to look at the management stuff that’s only available through PowerShell, when restricted to built-in Windows Management Tools.
| In this blogpost: |  |
Creating and managing fine-grained password policies
PowerShell Cmdlets to use:
- Add-ADFineGrainedPasswordPolicySubject
- Get-ADFineGrainedPasswordPolicy
- Get-ADFineGrainedPasswordPolicySubject
- Get-ADUserResultantPasswordPolicy
- New-ADFineGrainedPasswordPolicy
- Remove-ADFineGrainedPasswordPolicy
- Remove-ADFineGrainedPasswordPolicySubject
- Set-ADFineGrainedPasswordPolicy
Note:
The domain functional level will need to be Windows Server 2008, to be able to utilize this feature.
The Windows Server 2008 Domain Functional Level introduced a feature called Active Directory Password and Account Lockout Settings Objects (PSOs) and the concept of fine-grained password policies. These groups-oriented objects can be used to set (and if you’d like, enforce using precedence) password and account lockout settings to users and groups in Active Directory.
Note:
Before Windows Server 2008, the only scope on which these policies could be applied was the domain.
You cannot use the built-in Active Directory tools, like Active Directory Users and Computers (dsa.msc), to create and manage PSOs.
Instead, you can use the AdsiEdit MMC snap-in (adsiedit.msc), your favorite low-level Active Directory tool (ldp.exe, admod.exe) or specialized software, like SpecOps’ free Password Policy Basic (as advertised in every Microsoft Press book touching the subject), Cristoffer Andersson’s (Swedish Directory Services MVP) Fine Grained Password Policy tool or Joe Richards’ (US-based Directory Services MVP) PSOMgr.exe.
I think all of the above tools are awesome. But, I hear you asking, isn’t there a built-in command-line tool, that you can use to build one-liners to manage these Password and Account Lockout Settings Objects (PSOs)?
Yes, there is, in the form of a PowerShell cmdlet.
First, load the Active Directory module into your PowerShell, using the command
Import-Module Active Directory
Then put the New-ADFineGrainedPasswordPolicy cmdlet in action, as shown here on TechNet:
New-ADFineGrainedPasswordPolicy -Name "SalesUsersPSO" -Precedence 500 -ComplexityEnabled $true -Description "Sales Users Password Policy"-DisplayName "Sales Users PSO" -LockoutDuration "0.12:00:00" -LockoutObservationWindow "0.00:15:00" -LockoutThreshold 10 -MaxPasswordAge "60.00:00:00" -MinPasswordAge "1.00:00:00" -MinPasswordLength 8 -PasswordHistoryCount 24 -ReversibleEncryptionEnabled $false
A long one-liner, I agree, but a one-liner nonetheless…
After creating the PSO, you can assign it to users and groups. Use the following command to make our good friend Jos Haarbos subject to the previously created Sales Users Password Policy:
Add-ADFineGrainedPasswordPolicySubject "Sales Users Password Policy" "Jos Haarbos"
Now, of course, with the possibility to assign Password and Account Lockout Policies to users and groups and users belonging to multiple groups, things tend to get messy fast. Therefore, a new cmdlet was created to get the Resultant Fine-grained Password Policy for a user:
Get-ADUserResultantPasswordPolicy "Jos Haarbos"
More information:
- PowerShell cmdlets (W2K8R2) for Fine-Grained Password Policy
- Fine Grain Password Policy Tool 1.0 (2300.0) RTM
- Windows Server 2008 – Fine Grained Password Policy Walkthrough
- PSOMgr.exe | Command line tool to manage Fine Grain Password Policies
- ActiveDir.org List Archive – Fine-grained password policy using ldifde.exe
- Using Microsoft's New AD PowerShell Cmdlets
- Active Directory Powershell Overview
Enabling the Active Directory Recycle Bin
PowerShell Cmdlets to use:
- Set-ADForestMode
- Enable-ADOptionalFeature
In part 3 of this series, I reflected on properly undeleting user objects from Active Directory in Windows Server 2003 with Service Pack 1 and onwards. However, in Windows Server 2008 R2, the Active Directory team has introduced a new feature, that makes this task even less of an effort. (You can read more on it in the next paragraph.)
This feature is called the Active Directory Recycle Bin. Enabling this feature requires three steps:
- Upgrade all Domain Controllers in the forest to Windows Server 2008 R2
- Raise the forest functional level to Windows Server 2008 R2
- Enable the Active Directory Recycle Bin Optional feature.
The first step is pretty basic. At least… in an environment where all Domain Controllers are created equally (except for Global Catalog and Flexible Single Master Operations role placements) and aren’t misused for other purposes.
The second step is also pretty easy. While most Active Directory admins perform this task on a writable Domain Controller using Active Directory Domains and Trusts, (domain.msc), in Windows Server 2008 R2 you can use the Set-ADForestMode PowerShell cmdlet:
Import-Module Active Directory
Set-ADForestMode domain.tld Windows2008R2Forest
The third step is also a simple PowerShell one-liner:
Enable-ADOptionalFeature –Identity 'CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration, DC=domain,DC=tld' -Scope ForestOrConfigurationSet -Target 'domain.tld'
After execution of the command and proper replication to all Domain Controllers, you will have the Active Directory Recycle Bin enabled. All link-valued and non-link-valued attributes of deleted Active Directory objects are preserved and the objects are restorable in their entirety to the same consistent logical state that they were in immediately before deletion.
More information:
- Introducing Active Directory Recycle Bin
- What's New in AD DS: Active Directory Recycle Bin
- Active Directory Recycle Bin Step-by-Step Guide
- How to raise forest / domain functional level using the command line
Restoring objects from the Active Directory Recycle Bin
PowerShell Cmdlets to use:
- Get-ADObject
- Restore-ADObject
As previously mentioned Windows Server 2008 R2 features the Active Directory Recycle Bin. After enabling it (on the command-line), I bet you’re wondering how to use it. Well… guess what… The easiest way to use it is through PowerShell.
That’s right! Again, the Active Directory released a kick-behind feature, without providing a graphical tool to manage it. As a command-line aficionado, by now, you should feel righteous about your move from the Graphical User Interface. [H]
Of course the usual built-in suspects (AdsiEdit.msc, Ldp.exe) can be used to restore objects from the Active Directory Recycle Bin, but none of these tools is actually worthwhile when you need to restore … say …. twelve hundred user objects, since it would entail changing the specific attributes for each one of them.
Of course Joeware’s admod.exe, the PowerGUI Active Directory Recycle Bin PowerPack and ADRecycleBin.exe can be used, but none of these are available by default on a vanilla Windows Server 2008 R2 Domain Controller. Instead, you can pipe the Get-ADObject Cmdlet to the Restore-ADObject Cmdlet.
For instance, when you want to restore the accidentally deleted account for Jos Haarbos, you would use the following PowerShell one-liner after importing the Active Directory module:
Get-ADObject -Filter {displayName -eq "Jos Haarbos"}
-IncludeDeletedObjects | Restore-ADObject
Of course, not merely user objects can be restored. The biggest caveat here, however, is to remember you can only restore an object, when it’s parent object is present. When restoring a whole Organizational Unit (OU) with user objects, for instance, first restore the OU, then restore the user objects.
More information:
- Active Directory Recycle Bin
- Active Directory Recycle Bin Step-by-Step Guide
- How to: Recovering Deleted AD Objects in Windows Server 2008 R2
- How do I use the Windows 2008 R2 Recycle Bin feature ?
- Revive Deleted AD Objects with Active Directory Recycle Bin
- Working with the Server 2008 R2 Active Directory Recycle Bin
Managing Managed Service Accounts
PowerShell Cmdlets to use:
- New-ADServiceAccount
- Add-ADComputerServiceAccount
- Install-ADServiceAccount
Note:
The domain and forest will need to be prepared for Windows Server 2008 R2. When running pre-Windows Server 2008 R2 Domain Controllers, the functionality will work, except for automatic password and SPN management. It is therefore advised to use Windows Server 2008 R2-based Domain Controllers when utilizing this feature.
Note:
Both the machine on which you want to run the PowerShell commands and the machine where the service runs with the credentials of the managed service account, need to be running either Windows Server 2008 R2 or Windows 7, to be able to utilize this feature. When you use Windows 7 to manage managed service accounts you will need to install the Remote Server Administration Tools (RSAT).
Using Service Accounts with just enough privileges, is a best practice in Windows environments. While most services function perfectly with Local System, Network Service or Local Service accounts (and benefit from additional security in these scenarios too) privileges, other services require more isolation, more fine-grained rights assignment, outside communication, or communication between an application and its data.
For long, the built-in Administrator account was used for these purposes, but in a lot of environments this practice was (wisely) abandoned the first time the password for this account would have needed to be changed.
The Local System, Network Service and Local Service accounts have a couple of nice touches. For instance, these accounts change passwords often.
Another new feature in Windows Server 2008 R2 Active Directory is the Managed Service Account. This new object type, derived from the computer account object, offers a big benefit: just like with a computer account and the typical local system accounts, the managed service account will automatically change it password regularly. IT can also update its Service Principle Name (SPN) automatically.
From a security point of view, this means, in a worst case scenario, a sniffed (and decoded) password(hash) can only be used for a limited amount of time. It also means that when the account is only given the barely minimum privileges, an attacker cannot exploit a vulnerability in the service, beyond the service itself.
Note:
Probably because of this security concern, a managed service account can only be assigned to one host at the time.
From a management point of view, it means you can create automatically changing service accounts per service per host. After renaming the host, the service will start like it did before.
The command to create a Managed Service Account after enabling PowerShell Active Directory Management (using Import-module Active Directory) would look something like:
New-ADServiceAccount -Name MSA-Host1 -Path "CN=Managed Service Accounts,DC=domain,DC=tld"
Note:
While creating a Managed Service Account is also possible using Active Directory Users and Computers (ds.msc), this is not the ideal way to create these accounts.
Then, to assign the Managed Service Account to a host, use the following command:
Add-ADComputerServiceAccount -Identity Host1
-ServiceAccount MSA-Host1
As a last step, install the Managed Service Account on the host, that hosts the service, in this case Host1:
Import-module Active Directory
Install-ADServiceAccount -Identity MSA-Host1
After this third step you can configure the service to run using the managed service account.
More information:
Login