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.