What is the meaning of the “$” symbol at the end of the managed service account(msa)?

A service principal name (SPN) is the name by which a client uniquely identifes an instance of
a service. If there are multiple instances of a service on computers throughout a forest, each
instance must have its own SPN. One service instance can have multiple SPNs where there are
multiple names that clients might use for authentication. For example, an SPN always includes
the name of the host computer on which the service instance is running, so a service instance
might register an SPN for each name or alias of its host.
SPNs are of the format: serviceclass/host:port servicename where serviceclass and host
are required, but port and service name are optional. The colon between host and port is only
required when a value for port is present.

A service principal name (SPN) is the name by which a client uniquely identifes an instance of
a service. If there are multiple instances of a service on computers throughout a forest, each
instance must have its own SPN. One service instance can have multiple SPNs where there are
multiple names that clients might use for authentication. For example, an SPN always includes
the name of the host computer on which the service instance is running, so a service instance
might register an SPN for each name or alias of its host.
SPNs are of the format: serviceclass/host:port servicename where serviceclass and host
are required, but port and service name are optional. The colon between host and port is only
required when a value for port is present.

Some examples of SPN registrations include:
■■ HTTP/www.treyresearch.net:8080 Any page on the website on the non-standard
TCP port 8080 for www.treyresearch.net, that is http://www.treyresearch.net.
■■ HOST/WORKSTATION5 Any service running on the computer with NetBIOS name
WORKSTATION5
■■ HOST/SERVER7.treyresearch.net Any service running on the computer with
hostname SERVER7.treyresearch.net
■■ TERMSRV/FRONTRM.treyresearch.net The Remote Desktop Protocol (RDP) service
running on the computer with hostname FRONTRM.treyresearch.net
■■ MSSQLSvc/SQLSERVER2.tailspintoys.com:1433 The SQL Server listening on
SQLSERVER2.tailspintoys.com, port 1433.
■■ cifs/KHWIN7.tailspintoys.com The fle share on the computer with hostname
KHWIN7.tailspintoys.com
When creating an SPN for a well-known service, you do not need to specify the port
for the SPN when the service uses the default port. The default SPNs are registered by the
NetLogon service. They are refreshed every 22 minutes after startup.

Three different consoles are required to transfer all fve roles:
■■ Active Directory Users and Computers is used to change the three domain-wide roles.
■■ Active Directory Domains And Trusts is used to change the forest-wide domain naming
master role.
■■ Active Directory Schema is used to change the forest-wide schema master role.
Before you can use the Active Directory Schema console, you need to register the schema
management DLL. Follow these steps to transfer the schema master role:
1. Open an elevated command or Windows PowerShell window with an account that has
the Change Schema Master right. By default, only members of the Schema Admins
group have this right.
2. Type regsvr32 schmmgmt.dll to register the schema management dll.
3. Type mmc to open a blank management console and select Add/Remove Snap-in
from the File menu.
4. Select Active Directory Schema from the Available Snap-ins list, as shown in Figure 5-2.
5. Click Add and then click OK to open the Active Directory Schema console.
6. Select Active Directory Schema in the console tree and right-click.
7. Select Operations Master from the Action menu to open the Change Schema Master
dialog box shown in Figure 5-3.
8. Click Change to move the schema master role from to the new domain controller.

To transfer the domain naming operations master role, open the Active Directory Domains
And Trusts console. Right-click Active Directory Domains And Trusts and select Operations
Master from the Action menu.
To transfer the three domain-wide roles, open Active Directory Users And Computers, rightclick the domain in the console tree, and select Operations Masters to open the Operations
Masters dialog box. This dialog box has three tabs, one each for RID, PDC, and Infrastructure

Follow these steps to frst stage the RODC and then install it on the target computer:
1. From an elevated Windows PowerShell prompt, create the staging account for the
RODC. The basic command is this:
Add-ADDSReadOnlyDomainControllerAccount `
-DomainControllerAccountName "trey-rodc-03" `
-DomainName "TreyResearch.net" `
-SiteName "Default-First-Site-Name"
For a full list of available options, see http://go.microsoft.com/fwlink/?LinkId=291137.
2. On the target server, complete the installation of Windows Server 2012 R2. You can use
a full installation or a core installation.
3. Set the name of the target server to the name used to create the staging account.
4. Assign static IPv4 and IPv6 addresses to all adapters on the target server.
5. On the target server, install AD DS by using this command:
Install-WindowsFeature `
-Name AD-Domain-Services `
-IncludeAllSubFeature `
-IncludeManagementTools
6. Connect to the domain and promote the RODC by using the following commands:
$myCred = Get-Credential -Message "Enter your domain credentials"
Install-ADDSDomainController `
-DomainName "TreyResearch.net" `
-Credential $myCred `
-UseExistingAccount:$True
7. You'll be prompted for the SafeModeAdministrorPassword on the command line and
then to confrm the password. Make sure that you enter a password that meets the
length and complexity requirements for the domain.
When the domain controller promotion completes, the new RODC restarts.

If the RODC is not prestaged, you can still install it by using Windows PowerShell. Follow
these steps:
1. Install Windows Server 2012 R2, either full or core installation.
2. Install the AD DS server role, including the management tools and Windows
PowerShell cmdlets, by using this command:
Install-WindowsFeature `
-Name AD-Domain-Services `
-IncludeAllSubFeature `
-IncludeManagementTools
3. Assign the server fxed IPv4 and IPv6 addresses for all network adapters and set the
server's name.
4. Promote the server to an RODC and install DNS with the following commands:
$myCred = Get-Credential -Message "Enter your domain credentials"
Install-ADDSDomainController `
-DomainName "TreyResearch.net" `
-Credential $myCred `
-InstallDNS `
-ReadOnlyReplica:$True
5. You'll be prompted for the SafeModeAdministrorPassword on the command line and
then to confrm the password. Make sure that you enter a password that meets the
length and complexity requirements for the domain.
When the domain controller promotion completes, the new RODC restarts.

You can install an RODC graphically, whether it is prestaged or not. If the frst RODC you install is not a staged RODC, you don't need to prepare the domain for the RODC because the
wizard does it for you. However, if the frst RODC is a staged RODC, you have to manually run
adprep.exe /rodcprep one time to prepare the domain.
To stage an RODC, follow these steps:
1. Open the Active Directory Administrative Center. You can select it from the Tools menu
of Server Manager or by typing dsac.exe in a shell.
2. In the left pane, select the domain in which you want to create the RODC and click
Domain Controllers, as shown in Figure 5-6.
In the Tasks pane, under Domain Controllers, click Pre-create A Read-only Domain
Controller Account.
4. On the Welcome page, select Use Advanced Mode Installation and then click Next.
5. On the Network Credentials page, select My Current Logged On Credentials or select
Alternate Credentials. The credentials you use must be a member of the Domain
Admins or Enterprise Admins groups. Click Next.
6. On the Specify The Computer Name page, shown in Figure 5-7, enter the computer
name you want to use for the RODC and then click Next.
7. On the Select A Site page, specify the site in which the new RODC will reside and
click Next.
8. On the Additional Domain Controller Options page shown in Figure 5-8, specify
whether the new RODC will be a DNS Server and a Global Catalog server. The default
in domains with AD-integrated DNS is for both to be selected. Click Next.
On the Delegation Of RODC Installation And Administration page, specify a group or
individual user to have local administrative access to the RODC, as well as be able to
attach the RODC to the account you're creating. If you don't specify any additional
names or groups, only a member of the Domain Admins group can attach the RODC
to the account. Click Next.
10. On the Summary page, you see all the settings of the wizard and you can then export
the settings to an answer fle for use with unattended installations. Click Next and then
click Finish to close the wizard.
After the account is created, you can attach a server to the account either graphically or
by using the Install-ADDSDomainServer cmdlet, as described earlier. To attach it graphically,
follow these steps:
1. Install Windows Server 2012 R2 on the target computer.
2. Open Server Manager and click Confgure This Local Server.
3. Assign fxed IPv4 and IPv6 addresses for all adapters and set the Computer Name value
to the name chosen when you prestaged the RODC.
4. Select Add Roles And Features from the Manage menu. Click Next, Select Role-based
Or Feature-based Installation, and click Next twice.
5. On the Select Server Roles page, select Active Directory Domain Services. Click Add
Features when the Add Features That Are Required For Active Directory Domain
Services page opens. Click Next and then click Next again on the Select Features page.
6. Read the Active Directory Domain Services page and click Next.
7. On the Confrm Installation Selections page, click Install and then Close.
8. In Server Manager, select AD DS in the console tree, as shown in Figure 5-9.
9. Click More in the Confguration Required For Active Directory Domain Services At
warning bar.
10. In the All Server Task Details And Notifcations dialog box, shown in Figure 5-10, click
Promote This Server To A Domain Controller.
In the Active Directory Domain Services Confguration Wizard shown in Figure 5-11.
Specify the domain to connect to and the credentials to use to attach to the RODC
domain account.
FIGURE 5-11 The Deployment Configuration page
12. Click Next to display the Domain Controller Options page, as shown in Figure 5-12. The
precreated RODC account is identifed as shown by the yellow banner. Complete the
options, including a Directory Services Restore Mode (DSRM) password. Click Next and
complete the wizard to attach the RODC to the computer account you prestaged in
AD DS.
13. On the Prerequisites Check page shown in Figure 5-13, verify that all prerequisites have
been met. If there are anomalies identifed, correct them and click Rerun Prerequisites
Check until you get a green check mark. Then click Install to promote the RODC.
14. Click Install; the computer is promoted to an RODC and restarts to complete the
promotion.

When deploying a domain controller at a remote location, you can speed up the process
of initial replication by installing the AD DS database from disk: IFM. When combined with
staging, IFM enables the deployment of a remote RODC possible even over a slow link and
without any specialized knowledge at the remote site.
To create the media, use the Ntdsutil.exe ifm command. You can also create the installation
media by restoring a critical-volume backup of a domain controller in the same domain. The
requirements for IFM are these:
■■ You can't use IFM to create the frst domain controller in a domain; there must be a
Windows Server 2008 or later domain controller.
■■ The IFM media must be taken from the same domain as the new domain controller.
■■ If you're creating a global catalog server, the IFM must be from a domain controller
that is also a global catalog.
■■ To install a domain controller that is also a DNS server, the IFM must be from a domain
controller that is also a DNS server.
■■ To create installation media for a writable domain controller, you must create the IFM
on a writeable domain controller that is running Windows Server 2008 or later.
■■ To create installation media for an RODC, you can create the IFM on either a writeable
domain controller or an RODC.
■■ To create installation media that includes SYSVOL, you must create the IFM on a
domain controller running Windows Server 2008 Service Pack 2 or later.
To create the installation media, open a command shell or Windows PowerShell window
with Run As Administrator. In the shell, use the following commands to create the media:
Ntdsutil
activate instance ntds
ifm
create [Sysvol] <full/RODC> <pathtomediafolder>
The installation media can be saved to a network shared folder or to removable media. For
example, to create RODC installation media that includes the SYSVOL on the D:\IFM folder,
use create sysvol RODC "D:\IFM" to replace the last command in the preceding sequence.
After you have the installation media, create a new domain controller by specifying
the media source as part of the Install-ADDSDomainController cmdlet. Use the
-InstallationMediaPath parameter. For example:
$myCred = Get-Credential -Message "Enter your domain credentials"
Install-ADDSDomainController `
-DomainName "TreyResearch.net" `
-Credential $myCred `
-InstallDNS `
-InstallationMediaPath "D:\IFM" `
-ReadOnlyReplica:$True

After you verify that the environment meets the minimum requirements, you need to prepare
the source domain controller. The domain controller needs to be authorized for cloning by
making it a member of the Cloneable Domain Controllers security group in Active Directory.
You can use the Active Directory Administrative Center console, Active Directory Users and
Computers, or the Windows PowerShell ActiveDirectory module to assign the source domain
controller to the security group. The Windows PowerShell for this is the following:
Get-ADComputer <sourcedc> | Foreach-Object `
{Add-ADGroupMember -Identity "Cloneable Domain Controllers" $_.SamAccountName }
Identify any applications that will prevent cloning by running the
Get-ADDCCloningExclusionApplicationList cmdlet. Any applications or services identifed
must be either removed or added to the CustomDCCloneAllowList.xml fle. After you remove any services or applications that don't support cloning, you can use the -GenerateXML
parameter to create the CustomDCCloneAllowList.xml fle. For example, on trey-rodc-03, I got
the following:
Get-ADDCCloningExcludedApplicationList
Name Type
---- ----
Vim 7.3 Program
HyperSnap 7 WoW64Program
Both programs are simple utilities used in writing this chapter: one to edit fles and the
other to take screen shots. Neither one poses an issue with cloning, so I know I'm safe to add
them to the CustomDCCloneAllowList.xml fle. So I ran the cmdlet again:
Get-ADDCCloningExcludedApplicationList -GenerateXML
The inclusion list was written to 'C:\Windows\NTDS\CustomDCCloneAllowList.xml'.

After you verify that the environment meets the minimum requirements, you need to prepare
the source domain controller. The domain controller needs to be authorized for cloning by
making it a member of the Cloneable Domain Controllers security group in Active Directory.
You can use the Active Directory Administrative Center console, Active Directory Users and
Computers, or the Windows PowerShell ActiveDirectory module to assign the source domain
controller to the security group. The Windows PowerShell for this is the following:
Get-ADComputer <sourcedc> | Foreach-Object `
{Add-ADGroupMember -Identity "Cloneable Domain Controllers" $_.SamAccountName }
Identify any applications that will prevent cloning by running the
Get-ADDCCloningExclusionApplicationList cmdlet. Any applications or services identifed
must be either removed or added to the CustomDCCloneAllowList.xml fle. After you remove any services or applications that don't support cloning, you can use the -GenerateXML
parameter to create the CustomDCCloneAllowList.xml fle. For example, on trey-rodc-03, I got
the following:
Get-ADDCCloningExcludedApplicationList
Name Type
---- ----
Vim 7.3 Program
HyperSnap 7 WoW64Program
Both programs are simple utilities used in writing this chapter: one to edit fles and the
other to take screen shots. Neither one poses an issue with cloning, so I know I'm safe to add
them to the CustomDCCloneAllowList.xml fle. So I ran the cmdlet again:
Get-ADDCCloningExcludedApplicationList -GenerateXML
The inclusion list was written to 'C:\Windows\NTDS\CustomDCCloneAllowList.xml'.

EXAM TIP
Domain controller cloning is a new feature that is likely to get solid coverage in the exam.
Make sure you know the fle names and commands for the clone process; and which items
will defnitely prevent a successful clone, such as DhCp.

The fnal step to prepare the source computer for cloning is to gracefully shut it down.
You can use the GUI, the legacy shutdown.exe command, the Stop-Computer cmdlet, or the
Stop-VM cmdlet.

After the source domain controller is gracefully shut down, you can copy its VHDs by using
File Explorer, Xcopy.exe, or Robocopy.exe to the new location; or use Hyper-V export. Which
ever method you use, you should remove any snapshots prior to cloning, and merge any dif
ferencing disks prior to importing or creating the clone domain controller. After the fles for
the cloned domain controller are copied, you can restart the source domain controller.
Create the new target virtual machine (VM) by using whatever method you prefer. For
single-disk VMs with a single network adapter, it's probably easiest to rename the copied
VHD and create a new VM that uses it.
Start the target cloned VM, and the cloning operation automatically completes (see Figure
5-15), based on the settings in the DCCloneConfg.xml fle.

When the cloning is complete, both the original source domain controller and the new
cloned domain controller are in the Cloneable Domain Controllers security group. They
should be removed from this group except during active cloning operations.

You can optimize an Active Directory database by defragmenting it. Normally, defragmentation
automatically occurs online. However, you can do an offline defragmentation to recover
space in the AD DS database and optimize it. The tool for offline defragmentation is Ntdsutil.
exe. Use the following sequence from an elevated command prompt with Domain Admin
credentials on the domain controller where you want to defragment the database:
Net stop NTDS
Ntdsutil.exe
activate instance ntds
files
compact to "<location>"
quit
quit
If the compaction occurred without error, ntdsutil reports success and lists the remaining
steps, as shown in Figure 5-16.
Once back at the command prompt, copy the existing C:\Windows\ntds\ntds.dit fle to a
temporary location, just in case, and then delete the log fles, as described by the Ntdsutil.
exe shell, and copy the compacted ntds.nit fle back to C:\Windows\ntds. Use the following
Ntdsutil.exe sequence to verify the integrity of the compacted database:
Ntdsutil.exe
activate instance ntds
files
Integrity
If there are no integrity problems with the Active Directory database, ntdsutil.exe reports
success and you can type quit and then quit again to exit Ntdsutil.exe. Restart the ntds
service by typing net start NTDS

With each new version of Windows Server, Active Directory has gotten better at cleaning up
lingering metadata from decommissioned domain controllers. With Windows Server 2012 R2,
deleting a domain controller that is no longer available usually doesn't leave any lingering
server metadata, but this cleanup requires intervention in some circumstances.
Using active Directory Users and Computers
If you have to forcibly remove a domain controller that is no longer available, you can use
Active Directory Users and Computers to do metadata cleanup. To clean up metadata with
Active Directory Users and Computers, follow these steps:
1. Select Domain Controllers in the console tree, right-click the computer object of the
domain controller for which you want to clean up the metadata, and click Delete.
2. Click Yes to confrm the deletion.
3. The Deleting Domain Controller dialog box (see Figure 5-17) warns you that you
should run the Remove Roles And Features Wizard in Server Manager to remove the
domain controller from the domain.
f the domain controller is no longer available and can't be restored, select the
Delete The Domain Controller Anyway. It Is Permanently Offline And Can No Longer
Be Removed Using The Removal Wizard box and click Delete.
5. If the domain controller is a global catalog, you are warned again. Click Yes.
6. If one or more FSMO roles is hosted on the server, you are warned that the roles will
be moved to a specifc domain controller, as shown in Figure 5-18. You can't change
where the role will be moved to during this process. If you want the role on a different
domain controller, transfer the role after the domain controller deletion is complete.
7. Click OK; the domain controller is gone, along with its metadata.

You can also use the Active Directory Sites and Services console to clean up metadata. To
clean up metadata with ADSS, follow these steps:
1. In the Active Directory Sites and Services console, expand the site where the server is
located; then expand the Servers container and select the server name you want to
remove.
2. Expand the server name container. If there is an NTDS Settings container, select the
container and right-click.
3. Select Delete. In the Active Directory Domain Services dialog box, click Yes to confrm
the NTDS Settings deletion.
4. In the Deleting Domain Controller dialog box, if the domain controller is no longer
available and can't be restored, select the Delete The Domain Controller Anyway. It Is
Permanently Offline And Can No Longer Be Removed Using The Removal Wizard box
and click Delete.
5. If the domain controller is a global catalog server, click Yes to confrm the deletion.
6. If the domain controller currently holds one or more operations master roles, click OK
to move the role to the domain controller that is shown.
7. Right-click the domain controller that was forcibly removed and click Delete.
8. In the Active Directory Domain Services dialog box, shown in Figure 5-19, click Yes to
confrm the deletion.

An authoritative restore recovers the Active Directory database to a specifc point in time.
You can restore the entire database, an entire container, or a single object. Once restored,
that data is replicated to all other domain controllers in the domain. Usually an authoritative
restore is used to recover from a serious mistake or corruption. In all cases of an authoritative
restore, any changes to Active Directory since the snapshot was taken are lost.
Another concern with authoritative restores is the domain trust relationships between
workstations and the domain. Computer account passwords are changed automatically every
seven days, and a restoration to a snapshot older than seven days can result in workstations
being unable to connect to the domain.

To perform an authoritative restore, follow these steps:
1. Power on the domain controller you want to restore and interrupt the boot process to
boot to the Advanced Boot Options menu. Or from an elevated prompt on the running
domain controller, type bcdedit /set safeboot dsrepair and then reboot the server.
This will cause the server to boot into Directory Services Repair mode until changed.
2. Choose Directory Services Repair mode. Windows Server restarts in Safe mode without
loading Active Directory.
3. Log on to the Administrator account with the Directory Services Repair mode password
and open an elevated command or Windows PowerShell window.
4. Identify the version of backup you want to restore with:
Wbadmin get versions -backuptarget:<backupdrive> -machine:<DCName>
5. After you identify the version identifer for the version you want to restore, use the
following command to restore the system state:
Wbadmin start systemstaterecovery -version:<versionID> -backuptarget:<backupdrive>
-machine:<DCName>
6. After the restore is complete, open Ntdsutil.exe and type activate instance ntds;
then type authoritative restore.
■■ To restore the entire database, type restore database.
■■ To restore a container, type restore subtree <ObjectDN> where <ObjectDN> is
the distinguished name of the container to restore,
■■ To restore an individual object, type restore object <ObjectDN> where
<ObjectDN> is the distinguished name of the object to restore.
7. Quit out of Ntdsutil.exe, change the bcdedit sequence with bcdedit /deletevalue
safeboot if you altered it, and restart the server

Before you can use the Recycle Bin to recover deleted Active Directory objects, you need to
frst enable the Recycle Bin. The AD DS Recycle Bin requires a Forest functional level of at
least Windows Server 2008 R2.
Enabling the Active Directory Recycle Bin is a one-way, one-time process and is not
reversible. Enabling the feature requires membership in the Enterprise Admins group or
equivalent. You can enable the Recycle Bin by using the Active Directory Administrative
Center, by using Ldp.exe, or by using the Enable-ADOptionalFeature cmdlet. The Windows
PowerShell command to enable it on the TreyResearch.net domain is the following:
Enable-ADOptionalFeature `
-Identity "Recycle Bin Feature" `
-Scope ForestOrConfigurationSet `
-Target "TreyResearch.net"
To enable it in the Active Directory Administrative Center, select the domain in the left
pane and then click Enable Recycle Bin in the right Tasks pane. When prompted, click OK.
To restore a deleted object in the Recycle Bin, select it in the Deleted Objects container of
the Active Directory Administrative Center, and select Restore from the Tasks menu, as shown
in Figure 5-25.

Alternately, you can use Windows PowerShell to locate and restore a deleted object. To
restore that same David Hamilton user shown in Figure 5-25, use the following:
Get-ADObject -Filter {Name -like "David*"} -IncludeDeletedObjects | Restore-ADObject
As shown in Figure 5-26, if you search for the David Hamilton object, you don't fnd it until
you use the -IncludeDeletedObjects parameter. After you restore it with Restore-ADObject,
the user object is found.

1. Select the Domain (Local) node in the console tree and then double-click the System
object in the details pane.
2. Select the Password Settings Container in the System details pane and then click
New, Password Settings (as shown in Figure 5-27).
3. On the Create Password Settings page, shown in Figure 5-28, enter the specifc settings
for this password policy. The items that are required are identifed by large asterisks.
4. Optionally, click Add to apply the new PSO to one or more specifc security groups.
5. Click OK to create the PSO.
To see the Windows PowerShell for the PSO creation, click Windows PowerShell History at
he bottom of the Active Directory Administrative Center. The Windows PowerShell for the
PSO creation shown in Figure 5-28 is the following:
New-ADFineGrainedPasswordPolicy `
-ComplexityEnabled:$true `
-description:"Set minimum 12 character passwords for all Finance users, with a
minimum 2 days between changes." `
-LockoutDuration:"00:30:00" `
-LockoutObservationWindow:"00:30:00" `
-LockoutThreshold:"0" `
-MaxPasswordAge:"42.00:00:00" `
-MinPasswordAge:"2.00:00:00" `
-MinPasswordLength:"12" `
-Name:"Finance Users Pwd Policy" `
-PasswordHistoryCount:"24" `
-Precedence:"10" `
-ReversibleEncryptionEnabled:$false `
-Server:"trey-dc-02.TreyResearch.net"
Note that when capturing the Windows PowerShell used for an action in the Active
Directory Administrative Center, a verbose version of the command is captured. You can use the
New-ADFineGrainedPasswordPolicy cmdlet by setting only the items you want to change from
the Default Domain Policy. So, for example, you could create a new "Domain Admins Policy"
with the following command:
New-ADFineGrainedPasswordPolicy `
-Name "Domain Admins Policy" `
-MinPasswordLength 10 `
-Precedence 20 `
-LockoutThreshold 5
If you want to use an existing PSO as a template for a new policy, use
Get-ADFineGrainedPasswordPolicy and pipe it to New-ADFineGrainedPasswordPolicy

You can view the results of fne-grained password policies by selecting the user in the
Active Directory Administrative Center and clicking View Resultant Password Settings,
or us the Get-ADUserResultantPasswordPolicy cmdlet. This cmdlet accepts a variety of
forms for the -Identity parameter, or you can use Get-ADUser and pipe the result to the
Get-ADUserResultantPasswordPolicy cmdlet:
Get-ADUser -Identity "Charlie" | Get-ADUserResultantPasswordPolicy
AppliesTo : {CN=Domain Admins,CN=Users,DC=TreyResearch,DC=net}
ComplexityEnabled : True
DistinguishedName : CN=Domain Admins Policy,CN=Password Settings Container,CN=
System,DC=TreyResearch,DC=net
LockoutDuration : 00:30:00
LockoutObservationWindow : 00:30:00
LockoutThreshold : 5
MaxPasswordAge : 42.00:00:00
MinPasswordAge : 1.00:00:00
MinPasswordLength : 10
Name : Domain Admins Policy
ObjectClass : msDS-PasswordSettings
ObjectGUID : 89a03866-756d-4bd1-9835-5553b6e221de
PasswordHistoryCount : 24
Precedence : 20
ReversibleEncryptionEnabled : False

The lower the precedence of the PSO, the higher the priority. If a user is subject to two
PSOs, one with a precedence of 50 and one with a precedence of 100, the PSO with a
precedence of 50 will be the password setting that is applied to the user.

What is MSA service account?

Managed Service Accounts are a Windows feature introduced in Windows Server 2008 R2 for increasing the security of non-user service accounts. Managed Service Accounts, shortened as MSAs, have an automatically-managed, complex password that removes the requirement of manually dealing with password rotation and security.

Does a managed service account have a password?

That account has its own complex password and is maintained automatically. This means that an MSA can run services on a computer in a secure and easy to maintain manner, while maintaining the capability to connect to network resources as a specific user principal.

What is the difference between MSA and gMSA?

This type of managed service account (MSA) was introduced in Windows Server 2008 R2 and Windows 7. The group Managed Service Account (gMSA) provides the same functionality within the domain but also extends that functionality over multiple servers.

How does managed service accounts work?

Managed Service Account (MSA) is a special type of Active Directory account that can be used to securely run services, applications, and scheduled tasks. The basic idea is that the password for these accounts is completely managed by Active Directory.