Before you start
Objectives: learn the difference between Workgroup and a Domain. Learn the definition of Active Directory, what objects does it contain, about the structure of Active Directory and about Group Policy.
Prerequisites: no prerequisites.
Key terms: workgroup, domain, active directory, objects, structure, trust, organizational unit, site, example.
Workgroup Versus Domain
When we create a collection of computers that are managed locally, we call this a Workgroup. So, the basic thing to know about Workgroups is that every computer in a Workgroup uses its local database (Security Accounts Manager – SAM database) for user management. Each computer holds information about its users and resources locally.
The second model for administering our computers is Domain methodology. In Domain model we use Active Directory (AD) database for administration, which is located on central server called Domain Controller. A domain is a collection of network resources that share a common directory database and security policies.
Domain is the basic administrative unit of an Active Directory structure. It shares a common directory database and security policies. A domain allows us to group computers running NT 2000 and later or even non-Microsoft operating systems. With a domain we get centralized administration and security management. Domains are identified using DNS names. Each domain maintains its own set of relationships with other domains.
Active Directory (AD)
AD was first introduced with Windows Server 2000. AD is a centralized database that resides on our Domain Controllers (DC). A DC is a server that holds a copy of the Active Directory database that can be written to. Replication is the process of copying changes to Active Directory between the domain controllers.
We use AD to manage our computers, users and resources. AD also provides network services like LDAP directory services, Kerberos based authentication, DNS naming, secure access to resources, software deployment and more. In the Active Directory model we have hierarchical structure of objects with their attributes, and because of that, we have a lot of flexibility in management. With Active Directory, all computers share the same central database. Since the domain is the basic administrative unit in AD it is used for central administration of security settings and other administrative tasks. Domains can contain a number of different types of computers and operating systems, even computers not using a Windows operating system.
The heart of AD is the NTDS.DIT database file . It is the physical database file in which all directory data is stored. This file consists of three internal tables: data, link, and security descriptor table. Data table contains all the information in the AD data store, which includes users, groups, application-specific data, and any other data that is stored in AD after its installation. Link table contains data that represents linked attributes, which contain values that refer to other objects in AD. Security descriptor (SD) table contains data that represents inherited security descriptors for each object.
When we want to add computer to the domain, it is not enough to connect the computer to the network where a domain exists. We must join our computer to a domain trough its System Properties.
Objects in AD
Everything that Active Directory tracks is considered an object. There are two general groups of objects in AD: resources (e.g. printers), and security principals (computers, users, and groups). Security principals are assigned with unique security identifiers (SIDs) that are used to control access and to set security. Active Directory uses DNS for locating and naming objects, so keep in mind that our domain structure has to be in compliance with the Domain Naming System (DNS) format.
Each object represents a single entity (one user, one computer, one group…) and is defined by its name and a set of attributes (properties) like user name, email address, etc. Certain objects can also be containers for other objects. All of this is defined by a Schema, which determines the kinds of objects (object classes) that can be stored in AD, their attributes and type of data that can go into attributes. The type of schema can also determine how objects are used. For instance, some objects with certain schemes cannot be deleted, they can only be deactivated. Other types of objects with certain attributes can be deleted entirely. For instance, a user object can be deleted, but the administrator object cannot be deleted.
AD Structure
When we talk about AD structure it’s important to know its hierarchy, so we need to know where doForests, Trees, and Domains belong to. When designing our domain structure, we start by a domain name. Domain name follows DNS naming structure, so our domain might be, for example, saadz26.sg-host.com. When drawing domains in AD, the domain is represented with a triangle. Depending on the size of the organization, single domain might be enough or we might have multiple domains. If we have multiple DCs in our organization, the NTDS.DIT file will be replicated between all DCs. We also might have remote offices in other cities or even countries. These remote offices could have their own domains, which would be child domains. For example, if we have a remote office in Zagreb (Croatia), the child domain could be something like zg.saadz26.sg-host.com., with zgrepresenting Zagreb. Inside of domains we can create Organizational Units (OUs). OUs can also have child OUs. This brings us great flexibility in organizing our AD. Structure like this is called a Treestructure. We can always add new domains or OUs to our Tree structure. But, we can even add other existing domains to our structure by using something called Forest Trust. When we do that, we create a Forest (collection of trees with configured trust between them). The Tree structure shares the same namespace, while the Forest has a separate namespace.
So, to recap: Tree is a collection of one or more Domains. Domins in a tree share the same contiguous DNS name space. Forest is a collection of Trees with established relationship. Trees in a forest have different DNS name spaces. The forest root domain is the top-level domain in the top tree. It is the first domain created in the Active Directory forest. The tree root domain is the highest level domain in a tree. Each domain in the tree that is connected to the tree root domain is called a child domain. Domains in a tree share a common schema and have common global catalogs.
The thing is, AD can be viewed at several levels, and at the top of the structure is the Forest. The Forest is a collection of every object, its attributes, and rules in AD. The forest, tree, and domains arelogical parts in AD that are linked by transitive trust hierarchy.
Trusts
Two types of trusts that Microsoft ADs incorporate are transitive trusts and one-way non transitive trusts. A transitive trust is when there is a trust that goes further than two domains in a set tree, meaning two entities are able to access each other’s domains and trees. A one-way non transitive trust is when a user is allowed access to another tree or domain; however, the other domain does not allow access to the further domains. Domains in a tree are connected with a two-way transitive trust.
Organizational Units (OU)
Objects can be grouped into containers called Organizational Units (OUs). Organizational Units enable us to create a hierarchy within a Domain, which makes it easier for administration. OUs are like folders which are used to logically organize resources. Organizational Units (parents) can contain other OUs (children) or multiple nested OUs. That means that they are container objects. Microsoft recommends few domains and more OUs when organizing AD structure. The OU is the common level at which to apply Group Policies, which are also Active Directory objects. Organizational Units are just an abstraction for the administrator, and do not function as true containers. Because of that it is not possible, for example, to create two user accounts with an identical username in two separate OUs in one domain.
Generic Containers
Generic containers are also used to organize objects in AD. They are created by default, and they cannot be created, moved, renamed or deleted. They only have few editable properties.
Sites
Active Directory also supports the creation of Sites, which are physical rather than logical aspect of AD structure. Sites are defined by one or more IP subnets. A subnet represents a physical network segment. Each subnet possesses its own unique network address space. Sites are independent of the domain and OU structure, and they are common across the entire forest. Sites are used to control replication between locations and also to refer clients to the nearest domain controllers. We can control how often and how sites replicate between each other by configuring the Site Link. Each DC on each site will have a copy of the NTDS.DIT database file.
Examples
How would all this look like in real life? Most of organizations are based on departments and around functionality (for instance, the accounting department, development department etc), so we would manage our Active Directory based on what are people doing or where are they working. For instance, we would create Development OU, in which we would hold user and computer accounts for people working in development department. We would do the same thing for other existing departments (like sales department, research department). This would give us enormous flexibility in managing rights for different users working in different departments. In our initial installation we will have one Domain Controller (DC). Depending on the size of our organization, we may also add other domain controllers. If we make a change on one server, that change will be replicated to other machines. If we do need to bring geography in AD (distant offices), we can create Sites. Sites are another type of container that reflect the geographical location of our offices. When we know that idea behind AD is centralized management and security, we can enforce the same security parameters throughout our organization.
As we get ready to deploy our security settings, we can organize them through the implementation of Group Policy objects. These are security settings that we can apply to our Domains, Sites and Organizational Units.
Group Policy
A Group Policy is a set of settings that are applied to users or computers. Collections of policy settings are stored in a Group Policy object (GPO). The GPO is a collection of settings that includes registry settings, scripts, templates, and software-specific configuration values. Computers that are not part of a domain use the Local Security Policy settings and computers that are part of a domain use both the Local Security Policy and the Group Policy. Local Policy settings take precedence over local user profile settings. Group Policy settings in Active Directory take precedence over settings in the Local Security Policy. Group Policy allows us to push out settings to all our machines at once. Security settings are not shared between domains.