User Account Management

What is a User Account?

An object in AD DS responsible for controlling authentication and validation of access to

resources, containing many attributes about a particular user on your network.

Traditional Active Directory Management Tools

At this stage, it is important to get familiar with some of the management tools an administrator
is likely to come across in the execution of their daily tasks.

Active Directory Users and Computers – This tool is typically used daily to manage Active
directory objects such as users, groups, computers and OUs. Users with expired passwords or
locked accounts are common in network set ups and this tool will help you reset their accounts
and get them back up and running.

Active Directory Sites and Services – This tool is used to manage sites, network topology,
replication and related services.

Active Directory Domains and Trusts – Useful tool for managing trust relationships and forest
functional level.

Active Directory Schema – This tool is not installed by default and used to manage the schema.

Command Line Tools – A collection of tools used for basic scripting and command line
management.

New Active Directory Management Tools

The arrival of Windows Server 2012 R2 saw some additional tools added by Microsoft to further
extend the functionality and management of the operating system.

Active Directory Administrative Centre – A GUI built on Windows PowerShell with an

enhanced interface to perform object management using task-oriented navigation.
Windows PowerShell – A command line application like CMD used to create and manage
objects and provides scripting capabilities.

Creating User Accounts

Before we begin to create users on our server, some steps are required as by default the tools are
not readily in view. Click start to access the menu and right click on Active Directory Users and
Computers. This will become your most frequently used tool so it is advisable to pin it to your
task bar. Below the menu will be pull up options where you can choose to pin this tool for easy
access.

Active Directory Users and Computers

Launching the tool we just pinned above will open a very important administrative section of our
Windows Server 2012 operating system.

Here, you would see the domain you created along with a few other tools such as Builtin,
Computers, Domain Controllers, ForeignSecurityPrincipals, Managed Service Accounts and
Users which are extremely vital to administering resources on your server.
Right clicking on the Users tab on the left will drop down a menu, from which you can select
New > User to display the object screen as above. You will discover later as we explore servers
further, you can copy an existing user account to inherit permissions from the account such as
access to certain security groups.

Click next to choose a secure password for the user and notice the tick options; ‘User must
change password on next logon’, ‘User cannot change password’, ‘Password never
expires’ and ‘Account disabled’.

User Account Object Overview

Now that we have a new user created, let’s take a closer look at the user object itself to get
familiar with some of the properties. Right Click the user we just created, and select Properties as
shown below.
1. General Tab: More information about the new user such as first and last name, contact details
and email address created on your Exchange server can be found here.

2. Address Tab: Further information about the new user such street number, post code and
country can be populated in this tab. Third party applications like Exclaimer could leverage this
for managing company signatures, something we shall learn about in advanced future lessons.
3. Member Of Tab: This tab reveals vital information about the security groups the user belongs
to. Notice you have the ability to add and remove groups specific to each user, to control the
resources they have access to in your server environment.

4. Organization Tab: You can further define your new user in this tab with job title, department
and company they work for. Click Apply for any changes made to take effect.
5. Account Tab: Administrators will find themselves in this tab a lot. User accounts can be
unlocked, password policy changes and account expiry dates can be set in this interface. User
logon domain and names when a client forgets their credentials are also present in this tab.

6. Logon Hours: Administrators may sometimes wish to set up a time frame during the week
when users can access the server. In the Account tab, Click Logon Hours to display the day days
and times when a user can be permitted or denied logon for security reasons.
7. Logon To: Another important and useful security feature is the ability to lock down the
workstations from which a user is allowed to access the server. Click Logon To in the Accounts
tab to add/remove computers designated for a particular user to logon, trying to access resources
from unassigned workstation will see the user authentication denied.
 User Account Administrative Tasks
Server administrators in active environments will frequently get user related queries when there
is a problem accessing an account. Below, we’ll discuss some of the commonly known requests
and how to administer those tasks.

1. Copying An Existing User: This feature comes in handy when you have a new employee
starting at a department with existing users and resource permissions already assigned. Right
Click the user and select Copy from the menu to display the user object as below.

Populate the fields with your new user credentials including a strong password. Note that all
policies from the existing user will be inherited by the new user.
Double check the summary to ensure the existing user has been copied and click Finish.

You can confirm the new account has been created when you check the Member Of properties.

2. Resetting User Account Password: This task will most likely be the most requested task
from users to their administrators. Passwords may be set to expire after a period of time or users
may no longer be able to access their emails with the passwords they already have. In Active
Directory services, locate the user and Right Click on their object > Select Reset Password >
Type in new password > Apply.

3. Disabling An Active User Account: In the event an employee leaves the company,
administrators usually get a request from managers to delete the user account.

Bearing in mind that every active directory object carries a unique identifier, it is best practice to
disable the account, preventing the user from ever logging on until you are 100% sure the users’
email account for example will no longer be needed.
Right Click on the user in question and select Disable Account. You will be prompted to disable
the account and proceed with your action. Notice state of the object when disabled with
downward arrow.

You can always re-enable the account again by right clicking and selecting Enable Account

Creating Management Accounts for Protected Accounts and Groups in Active Directory

One of the challenges in implementing an Active Directory model that does not rely on
permanent membership in highly privileged groups is that there must be a mechanism to
populate these groups when temporary membership in the groups is required. Some privileged
identity management solutions require that the software’s service accounts are granted
permanent membership in groups such as DA or Administrators in each domain in the forest.
However, it is technically not necessary for Privileged Identity Management (PIM) solutions to
run their services in such highly privileged contexts.

This appendix provides information that you can use for natively implemented or third-party
PIM solutions to create accounts that have limited privileges and can be stringently controlled,
but can be used to populate privileged groups in Active Directory when temporary elevation is
required. If you are implementing PIM as a native solution, these accounts may be used by
administrative staff to perform the temporary group population, and if you’re implementing PIM
via third-party software, you might be able to adapt these accounts to function as service
accounts.

Note

The procedures described in this appendix provide one approach to the management of highly
privileged groups in Active Directory. You can adapt these procedures to suit your needs, add
additional restrictions, or omit some of the restrictions that are described here.

Creating Management Accounts for Protected Accounts and Groups in Active Directory

Creating accounts that can be used to manage the membership of privileged groups without
requiring the management accounts to be granted excessive rights and permissions consists of
four general activities that are described in the step-by-step instructions that follow:
 1. First, you should create a group that will manage the accounts, because these accounts
should be managed by a limited set of trusted users. If you do not already have an OU
structure that accommodates segregating privileged and protected accounts and systems
from the general population in the domain, you should create one. Although specific
instructions are not provided in this appendix, screenshots show an example of such an OU
hierarchy.
2. Create the management accounts. These accounts should be created as “regular” user
accounts and granted no user rights beyond those that are already granted to users by
default.
3. Implement restrictions on the management accounts that make them usable only for the
specialized purpose for which they were created, in addition to controlling who can enable
and use the accounts (the group you created in the first step).
4. Configure permissions on the AdminSDHolder object in each domain to allow the
management accounts to change the membership of the privileged groups in the domain.

You should thoroughly test all of these procedures and modify them as needed for your
environment before implementing them in a production environment. You should also verify that
all settings work as expected (some testing procedures are provided in this appendix), and you
should test a disaster recovery scenario in which the management accounts are not available to
be used to populate protected groups for recovery purposes. For more information about backing
up and restoring Active Directory.

Note

By implementing the steps described in this appendix, you will create accounts that will be able
to manage the membership of all protected groups in each domain, not only the highest-privilege
Active Directory groups like EAs, DAs and BAs. For more information about protected groups
in Active Directory.

Step-by-Step Instructions for Creating Management Accounts for Protected Groups

Creating a Group to Enable and Disable Management Accounts

Management accounts should have their passwords reset at each use and should be disabled
when activities requiring them are complete. Although you might also consider implementing
smart card logon requirements for these accounts, it is an optional configuration and these
instructions assume that the management accounts will be configured with a user name and long,
complex password as minimum controls. In this step, you will create a group that has
permissions to reset password on the management accounts and to enable and disable the
accounts.
To create a group to enable and disable management accounts, perform the following steps:

1. In the OU structure where you will be housing the management accounts, right-click the
OU where you want to create the group, click New and click Group.

2. In the New Object – Group dialog box, enter a name for the group. If you plan to use this
group to “activate” all management accounts in your forest, make it a universal security
group. If you have a single-domain forest or if you plan to create a group in each domain,
you can create a global security group. Click OK to create the group.

3. Right-click the group you just created, click Properties, and click the Object tab. In the
group’s Object property dialog box, select Protect object from accidental deletion,
which will not only prevent otherwise-authorized users from deleting the group, but also
from moving it to another OU unless the attribute is first deselected.
 Note

If you have already configured permissions on the group’s parent OUs to restrict
administration to a limited set of users, you may not need to perform the following steps.
They are provided here so that even if you have not yet implemented limited administrative
control over the OU structure in which you’ve created this group, you can secure the group
against modification by unauthorized users.

4. Click the Members tab, and add the accounts for members of your team who will be
responsible for enabling management accounts or populating protected groups when
necessary.

5. If you have not already done so, in the Active Directory Users and Computers console,
click View and select Advanced Features. Right-click the group you just created,
click Properties, and click the Security tab. On the Security tab, click Advanced.
6. In the Advanced Security Settings for [Group] dialog box, click Disable Inheritance.
When prompted, click Convert inherited permissions into explicit permissions on this
object, and click OK to return to the group’s Security dialog box.

7. On the Security tab, remove groups that should not be permitted to access this group. For
example, if you do not want Authenticated Users to be able to read the group’s name and
general properties, you can remove that ACE. You can also remove ACEs, such as those for
account operators and pre-Windows 2000 Server compatible access. You should, however,
leave a minimum set of object permissions in place. Leave the following ACEs intact:
o SELF
o SYSTEM
o Domain Admins
 o Enterprise Admins
o Administrators
o Windows Authorization Access Group (if applicable)
o ENTERPRISE DOMAIN CONTROLLERS

Although it may seem counterintuitive to allow the highest privileged groups in Active
Directory to manage this group, your goal in implementing these settings is not to prevent
members of those groups from making authorized changes. Rather, the goal is to ensure that
when you have occasion to require very high levels of privilege, authorized changes will
succeed. It is for this reason that changing default privileged group nesting, rights, and
permissions are discouraged throughout this document. By leaving default structures intact
and emptying the membership of the highest privilege groups in the directory, you can
create a more secure environment that still functions as expected.

Note

If you have not already configured audit policies for the objects in the OU structure where
you created this group, you should configure auditing to log changes this group.

8. You have completed configuration of the group that will be used to “check out”
management accounts when they are needed and “check in” the accounts when their
activities have been completed.

Creating the Management Accounts

You should create at least one account that will be used to manage the membership of privileged
groups in your Active Directory installation, and preferably a second account to serve as a
backup. Whether you choose to create the management accounts in a single domain in the forest
and grant them management capabilities for all domains’ protected groups, or whether you
choose to implement management accounts in each domain in the forest, the procedures are
effectively the same.

Note

The steps in this document assume that you have not yet implemented role-based access controls
and privileged identity management for Active Directory. Therefore, some procedures must be
performed by a user whose account is a member of the Domain Admins group for the domain in
question.

When you are using an account with DA privileges, you can log on to a domain controller to
perform the configuration activities. Steps that do not require DA privileges can be performed by
less-privileged accounts that are logged on to administrative workstations. Screen shots that
show dialog boxes bordered in the lighter blue color represent activities that can be performed on
a domain controller. Screen shots that show dialog boxes in the darker blue color represent
activities that can be performed on administrative workstations with accounts that have limited
privileges.

To create the management accounts, perform the following steps:

1. Log on to a domain controller with an account that is a member of the domain’s DA group.
2. Launch Active Directory Users and Computers and navigate to the OU where you will be
creating the management account.
3. Right-click the OU and click New and click User.
4. In the New Object – User dialog box, enter your desired naming information for the
account and click Next.
5. Log on to a domain controller with an account that is a member of the domain’s DA group.
6. Launch Active Directory Users and Computers and navigate to the OU where you will be
creating the management account.
7. Right-click the OU and click New and click User.
8. In the New Object – User dialog box, enter your desired naming information for the
account and click Next.
9. Provide an initial password for the user account, clear User must change password at next
logon, select User cannot change password and Account is disabled, and click Next.

10. Verify that the account details are correct and click Finish.
11. Right-click the user object you just created and click Properties.
12. Click the Account tab.
13. In the Account Options field, select the Account is sensitive and cannot be
delegated flag, select the This account supports Kerberos AES 128 bit
encryption and/or the This account supports Kerberos AES 256 encryption flag, and
click OK.
 Note

Because this account, like other accounts, will have a limited, but powerful function, the
account should only be used on secure administrative hosts. For all secure administrative
hosts in your environment, you should consider implementing the Group Policy
setting Network Security: Configure Encryption types allowed for Kerberos to allow
only the most secure encryption types you can implement for secure hosts.

Although implementing more secure encryption types for the hosts does not mitigate
credential theft attacks, the appropriate use and configuration of the secure hosts does.
Setting stronger encryption types for hosts that are only used by privileged accounts simply
reduces the overall attack surface of the computers.

For more information about configuring encryption types on systems and accounts,
see Windows Configurations for Kerberos Supported Encryption Type.

Note These settings are supported only on computers running Windows Server 2012,
Windows Server 2008 R2, Windows 8, or Windows 7.

14. On the Object tab, select Protect object from accidental deletion. This will not only
prevent the object from being deleted (even by authorized users), but will prevent it from
 being moved to a different OU in your AD DS hierarchy, unless the check box is first
cleared by a user with permission to change the attribute.

15. Click the Remote control tab.

16. Clear the Enable remote control flag. It should never be necessary for support staff to
connect to this account’s sessions to implement fixes.
 Note

Every object in Active Directory should have a designated IT owner and a designated
business owner, as described in Planning for Compromise. If you are tracking ownership
of AD DS objects in Active Directory (as opposed to an external database), you should
enter appropriate ownership information in this object’s properties.

In this case, the business owner is most likely an IT division, andthere is no prohibition on
business owners also being IT owners. The point of establishing ownership of objects is to
allow you to identify contacts when changes need to be made to the objects, perhaps years
from their initial creation.

17. Click on the Organization tab.

18. Enter any information that is required in your AD DS object standards.
19. Click on the Dial-in tab.
20. In the Network Access Permission field, select Deny access.This account should never
need to connect over a remote connection.
 Note

It is unlikely that this account will be used to log on to read-only domain controllers
(RODCs) in your environment. However, should circumstance ever require the account to
log on to an RODC, you should add this account to the Denied RODC Password
Replication Group so that its password is not cached on the RODC.

Although the account’s password should be reset after each use and the account should be
disabled, implementing this setting does not have a deleterious effect on the account, and it
might help in situations in which an administrator forgets to reset the account’s password
and disable it.

21. Click the Member Of tab.

22. Click Add.
23. Type Denied RODC Password Replication Group in the Select Users, Contacts,
Computers dialog box and click Check Names. When the name of the group is underlined
in the object picker, click OK and verify that the account is now a member of the two
groups displayed in the following screenshot. Do not add the account to any protected
groups.
24. Click OK.

25. Click the Security tab and click Advanced.

26. In the Advanced Security Settings dialog box, click Disable inheritance and copy the
inherited permissions as explicit permissions, and click Add.

27. In the Permission Entry for [Account] dialog box, click Select a principal and add the
group you created in the previous procedure. Scroll to the bottom of the dialog box and
click Clear all to remove all default permissions.

28. Scroll to the top of the Permission Entry dialog box. Ensure that the Type drop-down list
is set to Allow, and in the Applies to drop-down list, select This object only.
29. In the Permissions field, select Read all properties, Read permissions, and Reset
password.
30. In the Properties field, select Read userAccountControl and Write userAccountControl.
31. Click OK, OK again in the Advanced Security Settings dialog box.

Note

The userAccountControl attribute controls multiple account configuration options. You

cannot grant permission to change only some of the configuration options when you grant
write permission to the attribute.

32. In the Group or user names field of the Security tab, remove any groups that should not
be permitted to access or manage the account. Do not remove any groups that have been
configured with Deny ACEs, such as the Everyone group and the SELF computed account
(that ACE was set when the user cannot change password flag was enabled during
creation of the account. Also do not remove the group you just added, the SYSTEM
account, or groups such as EA, DA, BA, or the Windows Authorization Access Group.
33. Click Advanced and verify that the Advanced Security Settings dialog box looks similar to
the following screenshot.
34. Click OK, and OK again to close the account’s property dialog box.
 35. Setup of the first management account is now complete. You will test the account in a later
procedure.

Creating Additional Management Accounts

You can create additional management accounts by repeating the previous steps, by copying the
account you just created, or by creating a script to create accounts with your desired
configuration settings. Note, however, that if you copy the account you just created, many of the
customized settings and ACLs will not be copied to the new account and you will have to repeat
most of the configuration steps.

You can instead create a group to which you delegate rights to populate and unpopulate
protected groups, but you will need to secure the group and the accounts you place in it. Because
there should be very few accounts in your directory that are granted the ability to manage the
membership of protected groups, creating individual accounts might be the simplest approach.

Regardless of how you choose to create a group into which you place the management accounts,
you should ensure that each account is secured as described earlier. You should also consider
implementing GPO restrictions similar to those described in : Securing Built-In Administrator
Accounts in Active Directory.

Auditing Management Accounts

You should configure auditing on the account to log, at minimum, all writes to the account. This
will allow you to not only identify successful enabling of the account and resetting of its
password during authorized uses, but to also identify attempts by unauthorized users to
manipulate the account. Failed writes on the account should be captured in your Security
Information and Event Monitoring (SIEM) system (if applicable), and should trigger alerts that
provide notification to the staff responsible for investigating potential compromises.

SIEM solutions take event information from involved security sources (for example, event logs,
application data, network streams, antimalware products, and intrusion detection sources), collate
the data, and try to make intelligent views and proactive actions. There are many commercial
SIEM solutions, and many enterprises create private implementations. A well designed and
appropriately implemented SIEM can significantly enhance security monitoring and incident
response capabilities. However, capabilities and accuracy vary tremendously between solutions.
SIEMs are beyond the scope of this paper, but the specific event recommendations contained
should be considered by any SIEM implementer.
For more information about recommended audit configuration settings for domain controllers,
see Monitoring Active Directory for Signs of Compromise. Domain controller-specific
configuration settings are provided in Monitoring Active Directory for Signs of Compromise.

Enabling Management Accounts to Modify the Membership of Protected Groups

In this procedure, you will configure permissions on the domain’s AdminSDHolder object to
allow the newly created management accounts to modify the membership of protected groups in
the domain. This procedure cannot be performed via a graphical user interface (GUI).

the ACL on a domain’s AdminSDHolder object is effectively “copied” to protected objects when
the SDProp task runs. Protected groups and accounts do not inherit their permissions from the
AdminSDHolder object; their permissions are explicitly set to match those on the
AdminSDHolder object. Therefore, when you modify permissions on the AdminSDHolder
object, you must modify them for attributes that are appropriate to the type of the protected
object you are targeting.

In this case, you will be granting the newly created management accounts to allow them to read
and write the members attribute on group objects. However, the AdminSDHolder object is not a
group object and group attributes are not exposed in the graphical ACL editor. It is for this
reason that you will implement the permissions changes via the Dsacls command-line utility. To
grant the (disabled) management accounts permissions to modify the membership of protected
groups, perform the following steps:

1. Log on to a domain controller, preferably the domain controller holding the PDC Emulator
(PDCE) role, with the credentials of a user account that has been made a member of the DA
group in the domain.

2. Open an elevated command prompt by right-clicking Command Prompt and click Run as
administrator.
3. When prompted to approve the elevation, click Yes.

Note

For more information about elevation and user account control (UAC) in Windows,
see UAC Processes and Interactions on the TechNet website.

4. At the Command Prompt, type (substituting your domain-specific information) Dsacls

[distinguished name of the AdminSDHolder object in your domain] /G [management
account UPN]:RPWP;member.

The previous command (which is not case-sensitive) works as follows:

o Dsacls sets or displays ACEs on directory objects

o CN=AdminSDHolder,CN=System,DC=TailSpinToys,DC=msft identifies the object to
be modified
o /G indicates that a grant ACE is being configured
o PIM001@tailspintoys.msft is the User Principal Name (UPN) of the security principal
to which the ACEs will be granted
o RPWP grants read property and write property permissions
 o Member is the name of the property (attribute) on which the permissions will be set

For more information about use of Dsacls, type Dsacls without any parameters at a
command prompt.

If you have created multiple management accounts for the domain, you should run the
Dsacls command for each account. When you have completed the ACL configuration on the
AdminSDHolder object, you should force SDProp to run, or wait until its scheduled run
completes. For information about forcing SDProp to run.

When SDProp has run, you can verify that the changes you made to the AdminSDHolder
object have been applied to protected groups in the domain. You cannot verify this by
viewing the ACL on the AdminSDHolder object for the reasons previously described, but
you can verify that the permissions have been applied by viewing the ACLs on protected
groups.

5. In Active Directory Users and Computers, verify that you have enabled Advanced
Features. To do so, click View, locate the Domain Admins group, right-click the group
and click Properties.
6. Click the Security tab and click Advanced to open the Advanced Security Settings for
Domain Admins dialog box.

7. Select Allow ACE for the management account and click Edit. Verify that the account
has been granted only Read Members and Write Members permissions on the DA group,
and click OK.
 8. Click OK in the Advanced Security Settings dialog box, and click OK again to close the
property dialog box for the DA group.

9. You can repeat the previous steps for other protected groups in the domain; the permissions
should be the same for all protected groups. You have now completed creation and
configuration of the management accounts for the protected groups in this domain.

Note

Any account that has permission to write membership of a group in Active Directory can
also add itself to the group. This behavior is by design and cannot be disabled. For this
reason, you should always keep management accounts disabled when not in use, and should
closely monitor the accounts when they’re disabled and when they’re in use.

Verifying Group and Account Configuration Settings

Now that you have created and configured management accounts that can modify the
membership of protected groups in the domain (which includes the most highly privileged EA,
DA, and BA groups), you should verify that the accounts and their management group have been
created properly. Verification consists of these general tasks:

1. Test the group that can enable and disable management accounts to verify that members of
the group can enable and disable the accounts and reset their passwords, but cannot perform
other administrative activities on the management accounts.
2. Test the management accounts to verify that they can add and remove members to protected
groups in the domain, but cannot change any other properties of protected accounts and
groups.

Test the Group that Will Enable and Disable Management Accounts

1. To test enabling a management account and resetting its password, log on to a secure
administrative workstation with an account that is a member of the group you created
in Creating a Group to Enable and Disable Management Accounts.
2. Open Active Directory Users and Computers, right-click the management account, and
click Enable Account.

3. A dialog box should display, confirming that the account has been enabled.

4. Next, reset the password on the management account. To do so, right-click the account
again and click Reset Password.

5. Type a new password for the account in the New password and Confirm password fields,
and click OK.
6. A dialog box should appear, confirming that the password for the account has been reset.

7. Now attempt to modify additional properties of the management account. Right-click the
account and click Properties, and click the Remote control tab.
8. Select Enable remote control and click Apply. The operation should fail and an Access
Denied error message should display.
9. Click the Account tab for the account and attempt to change the account’s name, logon
hours, or logon workstations. All should fail, and account options that are not controlled by
the userAccountControl attribute should be grayed out and unavailable for modification.
10. Attempt to add the management group to a protected group such as the DA group. When
you click OK, a message should appear, informing you that you do not have permissions to
modify the group.
 11. Perform additional tests as required to verify that you cannot configure anything on the
management account except userAccountControl settings and password resets.

Note

The userAccountControl attribute controls multiple account configuration options. You

cannot grant permission to change only some of the configuration options when you grant
write permission to the attribute.

Test the Management Accounts

Now that you have enabled one or more accounts that can change the membership of protected
groups, you can test the accounts to ensure that they can modify protected group membership,
but cannot perform other modifications on protected accounts and groups.

1. Log on to a secure administrative host as the first management account.

2. Launch Active Directory Users and Computers and locate the Domain Admins group.
3. Right-click the Domain Admins group and click Properties.
4. In the Domain Admins Properties, click the Members tab and click Add. Enter the name
of an account that will be given temporary Domain Admins privileges and click Check
Names. When the name of the account is underlined, click OK to return to
the Members tab.

5. On the Members tab for the Domain Admins Properties dialog box, click Apply. After
clicking Apply, the account should stay a member of the DA group and you should receive
no error messages.
6. Click the Managed By tab in the Domain Admins Properties dialog box and verify that
you cannot enter text in any fields and all buttons are grayed out.

7. Click the General tab in the Domain Admins Properties dialog box and verify that you
cannot modify any of the information about that tab.
 8. Repeat these steps for additional protected groups as needed. When you have finished, log
on to a secure administrative host with an account that is a member of the group you created
to enable and disable the management accounts. Then reset the password on the
management account you just tested and disable the account. You have completed setup of
the management accounts and the group that will be responsible for enabling and disabling
the accounts.

Manage computer accounts

In Active Directory Domain Services,…there are many different types of objects that
you…would be responsible for managing.…One of those types of objects is the computer
object.…Now a computer, similar to a user account,…is a security principle.…In other words we
talked about the user account…being the interface between Active Directory…and a physical
person, you know, an actual human being,…well the computer account is the interface
between…Active Directory and actual physical computer.…
Now to demonstrate a little bit about computer objects…I want to jump into one of my domain
controllers,…so I'm going to go over to DC1.…Here in the server manager in DC1, let's go
up…to the tools menu, and I'm going to jump down…to Active Directory users and
computers,…here in Active Directory users and computers…you'll see I have my domain, and if
I expand that,…there are a couple of containers that, by default,…automatically get computer
accounts.…One container would be the computers container,…that seems fairly obvious, and if I
click on it,…
How to Create Computer Objects in Active Directory for Windows Server 2016

In this lesson, you will learn what computer objects are in Windows Server 2016 Active
Directory. You will also learn how to create computer objects using the Active Directory Users
and Computers (ADUC) interface. Other options for creating computer objects such as Active
Directory Administrative Center (ADAC), PowerShell and Dsadd will also be discussed.

The Active Directory Computer Object

Computer objects are used to uniquely identify and manage Windows-based domain clients
within Active Directory. They are used to specify computer names, locations, properties and
access rights. Computer objects can be created in Windows Server 2016 Active Directory by
using the Active Directory Users and Computers (ADUC) console. ADUC is a Microsoft
Management Console (MMC) snap-in that allows for centrally managing objects within Active
Directory.
ADUC is installed by default on Windows Servers with the Active Directory Domain Services
(ADDS) role enabled. Additionally, any Windows client can run ADUC by installing the
Microsoft Remote Server Administration Tools (RSAT). RSAT is commonly installed on
Windows clients for system administrators to perform job tasks.

Creating Computer Objects with ADUC

To create a computer object, open ADUC in Windows Server 2016. This is done by clicking
the Server Manager shortcut that is pinned to the taskbar by default. Once Server Manager is
open, select Tools from the top-right menu and then select Active Directory Users and
Computers from the list as shown below.

Image: Selecting Active Directory Users and

 Computers from Server Manager Tools Menu.

Once ADUC is opened, expand the domain. Computer objects can be created within
the Computers container or within an organizational unit. For this example, we are going to
create a computer named EXAMPLE01 within the computers container. To start, select
the Computers container in the left pane. Right-click and select New and then Computer from
the menu as shown below.

Image: The New Computer option in the Right-Click

Menu.

Once the New Computer dialog is displayed as shown below, input the computer
name EXAMPLE01. The name entered here is used to authenticate the computer's access to
domain resources and must match the name provided during Windows Setup. The Computer
name (pre-Windows 2000) property will auto-populate to match. This field is used to refer to a
domain configuration property called 'samAccountName'. The samAccountName is a Security
Account Manager name that is used for backward compatibility with older operating systems. In
most situations, these names will match.
It is a best practice to create a naming standard for computer objects so they are unique &
distinguishable from each other, for example named by their location within the building or for
which employee group (e.g. HR) the computers are assigned to.

The New Computer Object Properties Window.

In the User or group field, change the group that the computer should be a part of. This is done
by clicking the Change... button and then searching for the user or group to give access to the
computer. This user or group will be allowed to join the computer to the domain, even if they
wouldn't be able to otherwise. In most situations, computer objects should be a part of
the Domain Computers group, but other users and groups can be selected per any conditional
access requirements. Once finished, click OK.

Assigning a Computer Object to a User or Group.

Other Object Creation Methods
When creating a single computer object, using ADUC is a good option. However, there are three
additional ways to create computer objects in Active Directory:

• Active Directory Administrative Center (ADAC)

• PowerShell
• Dsadd

************************************************************************