Here is the next free video for the Active
Directory course. In this video, I look at the default groups that are created in the
Domain and locally on Windows Server 2008. In the last video, I looked at the Windows
7 built-in local groups that are available. These groups are also available in Windows
Server 2008 and provide the same functionality, so I will not go into these groups again.
I will only cover the built-in groups in Windows Server 2008 that do not exist in Windows 7.
Before I look at these groups, I first want to look at what happens to the local accounts
database on a server that is promoted to a Domain Controller. When you promote a server
to a Domain Controller, the local user account database is longer available. This helps protect
the Domain Controller from unauthorized use. Of course you could always remove the hard
disk from the Domain Controller and put it in another computer or boot the Domain Controller
using a DVD boot disk to access the files on the hard disk. Since Active Directory uses
a higher level of security than the local user database, this makes it harder for a
hacker to modify or create accounts. Although it is not impossible to modify the Active
Directory database using an off line attack, disabling the local account database and forcing
only a domain user account to be used on a Domain Controller does strengthen security
on Domain Controllers. The question is what happens to the local
built in groups accounts when the server is promoted to a Domain Controller. If I open
the local users manager from the start menu this will give me access to the users created
in the local user database. Notice that “local users and groups” is
reported as being disabled. Local users on this computer can not be created or accessed.
If I close the local user manager and open Active Directory users and Computers from
the start menu, notice that there is a container called built-in. This contains all the built-in
groups that were originally stored in the local database. In other words, the built-in
groups have effectively moved into the Active Directory database.
Some of you many have already thought, “If the built-in groups for a Domain Controller
are in the Active Directory database rather than in the local user accounts database,
won’t they be replicated with the rest of the Active Directory data?” The answer to
that is, “Yes, they will.” The built-in groups will be replicated to all Domain Controllers
in the Domain. However, these groups will not be available to all computers in the domain;
they are only available to Domain Controllers. What this essentially means is that if you
make a change to a built-in group stored in Active Directory, the change will affect all
Domain Controllers in your domain. In other words, all Domain Controllers share the same
built-in groups. You cannot make a change to a built-in group for a Domain Controller
and have it affect only one Domain Controller. It is all or nothing.
If you have a member server, that is, a server that is a member of the domain but is not
a Domain Controller, built-in groups work the same as they would on a client operating
system like Windows 7. Built-in groups also work the same as if the Windows Server was
not in the domain. The only time the functionality of these groups changes is when the server
is promoted to a Domain Controller. In the last video, I looked at the built-in
groups that were available in Windows 7. I will now look at the extra built-in groups
that are available in Windows Server 2008 R2 that are not available in Windows 7.
The first group is the server operators group. This group in my opinion is poorly named as
it only exists in the Active Directory database as a built-in group and thus only affects
Domain Controllers. The group has no default members, but if you add a user to this group
they will be able to do the following: Login to all Domain Controllers in your Domain.
Start and stop services on the Domain Controllers. Perform backup and restore operations on the
Domain Controllers. Format disks on the Domain Controllers. Create shares on the Domain Controllers,
and finally shut down and restart the Domain Controllers.
Although this does sound like a lot of power and in a lot of ways it is, members of this
group can not perform Active Directory administrator tasks like creating user accounts. This group
is designed for someone who needs to perform maintenance on Domain Controllers but not
perform actual Active Directory administration. The next group is account operators. This
group by default has no members. Users in this group can create, modify and delete accounts
in the Domain. Users in this group can login to a Domain Controller to perform Active Directory
administration. They are however limited to what they can do on the Domain Controller
other than Active Directory administration. Since the account operators group are not
administrators, there are some Active Directory functions that they cannot do for security
reasons. First, the account operators group cannot make changes to the Domain Controller
OU. The Domain Controller OU holds all the Domain Controller computer accounts for the
domain. Next they can not make changes to any users in the Domain Admin group. The Domain
Admin group gives a user Administrator rights for the whole domain. An account operator
can not make changes to users that are members of this group nor can they make changes to
the Domain Admin Group. This prevents an account operator from putting themselves in the Domain
Admin group and thus giving themselves Administrator rights in the domain or removing access from
for an existing Domain Administrator. The next group is the print operators group.
This group by default does not have any members. Members of this group can manage printers
on the Domain Controller, which includes adding and removing printers and managing the jobs
on these printers. Active Directory allows printer objects to
be created in Active Directory. This allows a printer to be associated with a user account
inside Active Directory. A printer operator can manage these printer objects as well as
printers on Domain Controllers. Members of the print operators group can also
login locally to a Domain Controller and shut down the domain controller. This is a lot
of power so you should be careful who you put in this group. It also should be considered
that since this group can add printer drivers to a Domain Controller, if the printer driver
is buggy it could cause the Domain Controller to become unstable. Like all the other built-in
groups that we have looked at so far, remember the scope of this group only applies to Domain
Controllers. The next group is terminal servers licenses
servers. This group is used to provide tracking of user licenses in Active Directory. A user
account in Active Directory has licensing information stored in it. In order for the
terminal server licensing software to access this information, the license sever needs
to be added to this group. This group simply provides a bridge between the terminal server
licensing server and the licensing information stored in the Active Directory user accounts. The next group is incoming forest trust builders.
In a previous video, I looked at how to create trusts in Active Directory. In order to create
a trust in Active Directory, a user account is required in both domains that has enough
access to create the trust. If you place a user in this group, it has the ability to
create an incoming trust to that domain. For example, if I added an administrator from
the second domain to the incoming forest trust builders group on the first domain, the administrator
in the second domain is now able to create an incoming trust in the first domain. Normally
an Administrator in the first domain would be required to run the trust wizard in their
domain as well in order to allow the trust to be created. Using this group, the user
has enough access to create the trust without an administrator in the first domain having
to run the trust wizard on their side and thus approving the creation of the trust.
The next group is certificate services DCOM access. This group is present on Domain Controllers
as well as non-Domain Controllers that are running Windows Server 2008. If you are using
certificates in your organization, the users or computers that require access to a Certificate
Authority or CA’s need to be put in this group. If the server is running DCom with
certificates, add the users and computers accounts to this group. This is what allows
them to obtain certificates from the Certificate Authority.
The next group is Windows authorization access group. This group provides access to an attribute
in the user account that provides a computed token for that user. Remember that a token
is created when a user logs in and tells other systems what that user can access. This attribute
in Active Directory allows applications to determine what the user has access to by looking
at this pre computed token. This means that software can access information inside this
token without the user having to be logged in. Normally a user would have to be logged
in and a security token created for software to access the token. You should only add users
to this group if software requires it. The last group is Pre-Windows 2000 compatibility
access. This group allows read access to all users and groups in the domain. This group
should only be used if you have Windows NT computers in your domain.
That’s it for the built-in groups for a Domain Controller and the local groups on
Windows Server 2008 R2. In the next video I will look at the default Domain Groups that
are created in Active Directory. These groups provide the back bone for access in your domain.
Unlike the built-in groups that I have looked at so far, these groups provide access at
the domain level. Thanks for watching another free video from IT Free Training.