MCITP 70-640: Domain Groups
Articles,  Blog

MCITP 70-640: Domain Groups


Welcome to IT Free Training. This video continues
on where the last video left off looking at the groups that are available in Active Directory.
In the last video I looked at the Active Directory groups that are available to Domain Controllers.
In this video I will look at the default domain groups that exist in Active Directory listed
here. If you are only interested in a particular group you can select the link for that group
or in the description for the video jump to that part of the video.
In any domain environment, you will want to use the default groups created in Active Directory
where possible. Doing so only makes administration of your domain a lot simpler.
The first group that I will look at is the enterprise admins group. This group is the
most powerful group in Active Directory. Users in this group have administrator rights for
all domains in the forest. There is also configuration information stored in the Active Directory
database that only the enterprise admins group has access to. This configuration information
is forest wide and thus this is why it is so tightly controlled. Since enterprise admins
have access to forest wide information, they are the only group in Active Directory that
can add or remove domains from the forest. This group only exists in the root domain
but members of this group can come from any domain. The next group that I want to look at is the
group Schema Admins. Like the Enterprise Admins group, this group only exists in the root
domain for the forest, but users can be added from any domain in the forest. This group
is the only group that can modify the Active Directory schema. The schema defines that
Active Directory Database and is forest wide. The schema defines what kind of data can be
stored in the Active Directory database. Since the schema affects all domains in the forest,
changes to the schema and thus members of this group should be carefully controlled.
The next group is the Domain Admins group. This group exists in each domain and provides
administrator access to that domain. The Enterprise Admins group is a member of this group by
default and this is where the Enterprise Admins groups gets it’s administrator power for
each domain in the forest. Members of this group have administrator rights for all computers
and users in the domain or in other words have all rights and permissions to these computers
and users. The Domain Admins group also has full administrator rights to all Domain Controllers
in that domain making it the most powerful group in the domain and for this reason users
of this group should be controlled. The next group is the Domain Users group.
Members of this group are allowed to perform tasks such as logon to workstations and running
applications. They can also make non administrative changes like changing settings for the desktop.
This group will normally represent all the users in your domain. Because of this, the
group is often used to assign permissions. For example, if you wanted to give all users
access to a particular printer or a share you would assign permissions on the resources
to the domain users group. The next group is the Domain Guest. This group
has no default rights in the domain. When you add a computer to the domain certain domain
groups are added to the local groups on that computer. For example, the Domain Users group
is automatically added to the local users group on that computer. This is where the
Domain Users gets its rights and permissions from. If you don’t want Domain Users to
have rights on that computer you would remove the Domain Users from the local users group
on that computer. The Domain Guest group is different from groups like the Domain Admins
and Domain Users in that it is not added to the local guest group when the computer is
added to the domain. For this reason, by default, members of this
domain guest group can’t login to any computers in the domain. Unless you give the Domain
Guest group access to a resource in your domain the group has no rights or permissions. The
only resources they can access are resources that have been given anonymous or everyone
access. The next group is the Domain Computers group.
When you add a computer to the domain, the computer account for that computer is automatically
added to the Domain Computers group, thus this group should contain all computers in
your domain. The only exception to this is Domain Controllers. When a server is promoted
to a Domain Controller, the computer account for that server is removed from the Domain
Computers group. The next group is the Domain Controllers group.
This group contains all the computer accounts for all the writeable Domain Controllers in
that domain. This group does not contain computer accounts for read only Domain Controllers.
When you promote a server from a server to a Domain Controller, the computer’s account
is moved from Domain Computers group to the Domain Controllers group.
The next group is Read Only Domain Controllers. Windows Server 2008 supports the ability to
have a read only copy of the Active Directory database stored on a Domain Controller. Later
in the course I will cover read only Domain Controllers in more detail. For the present,
if you deploy any read only Domain Controllers on your network, the computer account for
this Domain Controller will be placed in this group and only this group. It will not be
put in the Domain Computers group or the Domain Controllers group.
The next group is Enterprise Read Only Domain Controllers. This group only exists in the
root domain and is empty by default. Even if you promote a server to a Read Only Domain
Controller that exists in the root domain, the computer account for that server will
not be added to this group. If you upgraded your domain from Windows Server
2003, depending on how you upgraded the domain, this group may not exist. If it does not exist,
it will be created when you deploy your first read only domain controller.
The next group is allowed RODC Password Replication group. The passwords for the members of this
group will be cached on Read Only Domain Controllers. A read only Domain Controller does not replicate
the password attribute for a user account. This adds additional security because if the
Domain Controller is stolen the passwords will not be stored on the Domain Controller.
The problem with this approach is that if you have users that regularly authenticate
off that Domain Controller and the link between the read only Domain Controller and a regular
Domain Controller is down, the user will not be able to be authenticated. For this reason,
this group allows the password to be cached on the read only Domain Controller allowing
the user, if they have been authenticated from the read only Domain Controller, to be
able to be authenticated even during network outages.
The next group is denied RODC Password Replication group. This group prevents the password of
the user from being cached on a Read Only Domain Controller. If a user is a member of
the allowed and denied group, the denied group will always override the allowed permissions.
Keep in mind that no account will be cached on the Read Only Domain Controller unless
it is configured, but this group does allow you to quickly prevent a sensitive account
from being cached if it was included in the allowed group, maybe because it was a member
of another group. The next group is the DNSAdmins group. This
group allows basic DNS administration. In some cases you may not be able to create certain
records or zones, for example, if the data is stored at the forest level, because this
would require more access. The DNSAdmins group can start and stop the DNS service. If any
of the DNS groups are not present in your domain, they will be created when you install
DNS. The next group is DNSUpdateProxy. Computers
that are put into this group can perform DNS updates for other clients. If you are using
Windows Server 2000 DHCP server, the server will not have enough permissions to update
DNS. In order to grant this access, the computer account of the Windows 2000 DHCP Server needs
to be added to this group. This is just one example of how this group could be used.
The next group is DHCP Administrators. If any of the DHCP groups have not been created
they will be created when DHCP is first installed. Users in this group can administer DHCP servers.
This includes creating new records and zones and basically all aspects of DHCP administration
including stopping and starting the DHCP service. Membership of this group does not give any
other access on the server. For example, if DNS were installed on the server, being a
member of this group would not give you access to the DNS server even if a DNS record was
dynamically created by the DHCP server for a client. Also, being a member of the group
does not give you the ability to authorize the DHCP server in Active Directory. Before
a DHCP server can be used on the network it needs to be authorized in Active Directory.
Being a member of this group does not give you enough access to do this.
The next group is DHCP users. This group gives the user read only access to the DHCP server.
A user in this group can read the configuration of the DHCP server and also the records created
in the DHCP server. However, they can’t make any changes.
The next group is Group Policy Creator Owners. This group allows the user to modify group
policy in the domain. The administrator is automatically a member of this group. The
group has a lot of power so you should be careful whom you put in this group.
The next group is Cert Publishers. Members of this group can publish certificates in
Active Directory for users and computers. If you had a certificate authority on the
network or purchased certificates, members of this group could store this certificate
in Active Directory for use with a particular user or computer.
The last group is RAS and IAS Servers. Members of this group are able to access the remote
access properties for a user in Active Directory. For each user in Active Directory there are
a number of remote access properties stored with the user in Active Directory. If you
had a user or computer that needed to read these attributes in Active Directory, you
simply add the user or computer account to the RAS and IAS servers group.
This covers all the domain groups. Let us review and check what we have learned. Out
of all the groups that I have looked at, which group is able to perform administrative actions
across multiple domains? The answer is the enterprise admins group.
This is the only group that allows a user that is a member to perform administrative
action in other domains in the forest by default. The next question is, which group or groups
would you need to use to ensure all computers could access a resource?
In most cases you will most likely use the group Domain Computers. This contains every
computer in the domain including servers; however, it does not include Domain Controllers.
If you want to include Domain Controllers you will also need to add the Domain Controllers
group. If you are using read only Domain Controllers you will also need to add the Read-Only Domain
Controllers group. These 3 groups contain all the computer accounts for the domain.
Well that is it for all the Domain Groups in Active Directory. In the next video I will
look at special identities in Windows. These are similar to groups as they can be assigned
to a resource to grant or deny access; however, unlike a group, you can not make users a member
of a special identity. Membership is determined by authentication or the type of the connection.
I hope you found this video useful and thanks for watching.

13 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *