Skip to main content

active directory Structor

Active Directory Data Store (Directory)

The Active Directory data store is the database that holds all the directory information such as information on users, computer, groups, other objects, and information on the objects which users can access. It also includes other network components. Another name used to refer to the Active Directory data store is the directory. The Active Directory data store or directory is stored on the hard disk of the server by means of the Ntds.dit file. The file has to be stored on a drive that is formatted with the NTFS file system. The Ntds.dit file is placed in the Ntds folder in the systemroot. When changes are made to the directory, these changes are saved to the Ntds.dit file. Because all the data in Active Directory is stored in one distributed data store, the availability of data is improved. A centralized data store means less duplication, and also needs less administration.

Because domain controllers are utilized to manage domains, each domain controller within the domain hosts a write copy of the Active Directory directory. This means is that if one domain controller is unavailable; users, computers and programs would still able to still access the Active Directory data store hosted on a different domain controller in the particular domain. When changes are made to the data store on one domain controller, these changes are replicated to the remainder of the domain controllers within the domain. Because of Active Directory replication, domain controllers in a domain remain synchronized with one another. Active Directory replication occurs automatically. Only domain data, configuration data and schema data is replicated.active directory terminology and concepts Active Directory Terminology and Concepts

Information stored in Active Directory is not all placed in the identical location. The different locations wherein data is stored is called directory partitions. The domain partition holds information about the domain such as users, and resources in the domain. The configuration partition contains information on the Active Directory structure such as the configuration of the domains, domain trees and forests. The schema partition stores information on object classes and attributes.

Active Directory Objects

All information on users, groups, computers, servers and security policies in Active Directory are organized and categorized into different Active Directory objects. An Active Directory object can be defined as a group of attributes that represents a resource in the network. Each object has a unique name or unique identifier called a distinguished name. Objects can also contain other objects. These objects are known as containers. In the Active Directory Users and Computers console, the default object types created in a new domain in Active Directory are:

  • Domain, Organizational Unit, User, Computer, Contact, Group, Shared Folder and Shared Printer

Active Directory Components

Domains, organizational units (OUs), domain trees and forests are considered logical structures. Sites and domain controllers are considered physical structures.

  • Domains are the main logical structure in Active Directory because they contain Active Directory objects. Network objects such as users, printers, shared resources, and more, are all stored in domains. Domains are also security boundaries. Access to objects in the domain is controlled by access control lists (ACLs). You can use the domain functional level to enable additional Active Directory features. You do this by raising the domain functional level of the domain controllers within the domain. In Windows 2000, the domain mode concept was used and not the domain functional level. The domain functional levels that can be specified are Windows 2000 Mixed, Windows 2000 Native, Windows Server 2003 Interim and Windows Server 2003.
  • Organizational Unit (OU): An OU is a container that enables you to organize objects such as users, computers and even other OUs in a domain to form a logical administrative group. An OU is the smallest Active Directory component to which you can delegate administrative authority. A domain can have it own unique OU hierarchy.
  • Domain Trees: When you group multiple domains into a hierarchical structure by adding child domains to a parent domain, you are basically forming a domain tree. Domains are regarded as being part of the same domain tree when they have a contiguous naming structure. A two-way transitive trust relationship is automatically created between the parent domain and child domains when you create the child domain.
  • Forests: A forest is the grouping of multiple domain trees into a hierarchical structure. Domain trees in a forest have a common schema, configuration, and global catalog. Domains within the forest are linked by two-way transitive trust. Through the forest functional level, you can enable additional forest wide Active Directory features. The forest functional levels that can be set are Windows 2000, Windows Server 2003 Interim, and Windows Server 2003.
  • Sites: In Active Directory, sites are formed through the grouping of multiple subnets. Sites are typically defined as locations in which network access is highly reliable, fast and not very expensive.
  • Domain Controllers (DCs): A domain controller is a server that stores a write copy of Active Directory. They maintain the Active Directory data store. Certain master roles can be assigned to domain controllers within a domain and forest. Domain controllers that are assigned special master roles are called Operations Masters. These domain controllers host a master copy of particular data in Active Directory. They also copy data to the remainder of the domain controllers. There are five different types of master roles that can be defined for domain controllers. Two types of master roles, forest-wide master roles, are assigned to one domain controller in a forest. The other three master roles, domain-wide master roles, are applied to a domain controller in every domain.
    • The Schema Master is a forest-wide master role applied to a domain controller that manages all changes in the Active Directory schema.
    • The Domain Naming Master is a forest-wide master role applied to a domain controller that manages changes to the forest, such as adding and removing a domain. The domain controller serving this role also manages changes to the domain namespace.
    • The Relative ID (RID) Master is a domain-wide master role applied to a domain controller that creates unique ID numbers for domain controllers and manages the allocation of these numbers.
    • The PDC Emulator is a domain-wide master role applied to a domain controller that operates like a Windows NT primary domain controller. This role is typically necessary when there are computers in your environment running pre-Windows 2000 and XP operating systems.
    • The Infrastructure Master is a domain-wide master role applied to a domain controller that manages changes made to group memberships.

Active Directory Schema

The Active Directory schema defines what types of objects can be stored in Active Directory. It also defines what the attributes of these objects are. The schema is defined by the following two types of schema objects or metadata:

  • Schema class objects, also known as schema classes: Define the objects that can be created and stored in Active Directory. The schema attributes store information on the schema class object when you create a new class. A schema class is therefore merely a set of schema attribute objects.
  • Schema attribute objects, also known as schema attributes: Schema attributes provide information on object classes. The attributes of an object is also called the object’ properties.

Although Active Directory includes a large number of object classes, you can create additional object classes if necessary. These additions are known as extensions to the schema. Extensions can only be performed on the domain controller acting the Schema Master role.

The object classes that can be used on access control lists (ACLs) to protect security objects are User, Computer, and Group. These object classes are called security principals. A security principal has a Security Identifier (SID) which is a unique number. A security Principal’s SID consists of the security Principal’s domain and a Relative ID (RID). The RID is a unique suffix.

A few other concepts associated with the Active Directory schema are:

  • Class Derivations: Set a way for forming new object classes using existing object classes.
  • Schema Rules: The Active Directory directory service implements a set of rules into the Active Directory schema that control the manner in which classes and attributes are utilized, and what values classes and attributes can include. Schema rules are organized into Structure Rules, Syntax Rules, and Content Rules
  • Structure Rules: The structure rule in Active Directory is that an object class can have only specific classes directly on top of it. These specific classes are called Possible Superiors. Structure rules prevent you from placing an object class in an inappropriate container.
  • Syntax Rules: These rules define the types of values and ranges allowed for attributes.
  • Content Rules dictate what attributes can be associated with a particular class.

Global Catalog

The global catalog is a central information store on the objects in a forest and domain, and is used to improve performance when searching for objects in Active Directory. The first domain controller installed in a domain is designated as the global catalog server by default. The global catalog server stores a full replica of all objects in its host domain, and a partial replica of objects for the remainder of the domains in the forest. The partial replica contains those objects which are frequently searched for. It is generally recommended to configure a global catalog server for each site in a domain. You can use the Active Directory Sites and Services console to set up additional global catalog servers.

Group Policies and Active Directory

Active Directory enables you to perform policy based administration through Group Policy. Through group policies, you can deploy applications and configure scripts to execute at startup, shutdown, logon, or logoff. You can also implement password security, control certain desktop settings, and redirect folders. When you create new group policies in Active Directory, the policy is stored as Group Policy Objects (GPOs). In Active directory, you can apply a GPO to a domain, site or Organizational Unit.

Active Directory Object Naming Schemes

Each object in the Active Directory data store must have a unique name. Active Directory supports a number of object naming schemes for naming objects:

  • Distinguished name (DN): Each object has a DN. The DN uniquely identifies a particular object and uniquely identify where the object is stored. The components that make up the DN of an object are:
    • CN – common name
    • OU – organizational unit
    • DC – domain component
  • A canonical name is merely a different manner of depicting the object’s DN in a method that is simpler to interpret.
  • Relative distinguished name (RDN): The RDN identifies a particular object within a parent container or OU.
  • Globally unique identifier (GUID): A GUID is a unique hexadecimal number that is assigned to an object at the time that the object is created. The GUID of an object never changes.
  • User principal name (UPN): The UPN is made up of the user account name of the user, and a domain name that identifies the domain that contains the user account.

Active Directory Replication

In Active Directory, replication ensures that any changes made to a domain controller within a domain are replicated to all the other domain controllers in the domain. Active Directory utilizes multimaster replication to replicate changes in the Active Directory data store to the domain controllers. With multimaster replication, domains are considered peers to one another.

With Windows Server 2003, the Knowledge Consistency Checker (KCC) is used to create a replication topology of the forest, to ensure that the changes are replicated efficiently to the domain controllers. A replication topology reflects the physical connections utilized by domain controllers to replicate the Active Directory directory to domain controllers in a site, or in different sites. Intra-site replication occurs when the Active Directory directory is replicated within a site. When replication occurs between sites, it is known inter-site replication. Since the bandwidth between sites are typically slow, information on site link objects is utilized to identify the most favourable link that should be used for moving replication data between sites in Active Directory.

Active Directory Trust Relationships

In Active Directory, when two domains trust each other or a trust relationship exists between the domains, the users and computers in one domain can access resources residing in the other domain. The trust relationships supported in Windows Server 2003 are summarized below:

  • Parent/Child trust: A parent/child trust relationship exists between two domains in Active Directory that have a common contiguous DNS namespace, and who belong to the identical forest. This trust relationship is established when a child domain is created in a domain tree.
  • Tree Root trust: A tree root trust relationship can be configured between root domains in the same forest. The root domains do not have a common DNS namespace. This trust relationship is established when a new tree root domain is added to a forest.
  • Shortcut trust: This trust relationship can be configured between two domains in different domain trees but within the same forest. Shortcut trust is typically utilized to improve user logon times.
  • External trust: External trust relationships are created between an Active Directory domain and a Windows NT4 domain.
  • Realm trust: A realm trust relationship exists between an Active Directory domain and a non-Windows Kerberos realm.
  • Forest trust: Forest trust can be created between two Active Directory forests.

Comments

Popular posts from this blog

Docker Container Management from Cockpit

Cockpit can manage containers via docker. This functionality is present in the Cockpit docker package. Cockpit communicates with docker via its API via the /var/run/docker.sock unix socket. The docker API is root equivalent, and on a properly configured system, only root can access the docker API. If the currently logged in user is not root then Cockpit will try to escalate the user’s privileges via Polkit or sudo before connecting to the socket. Alternatively, we can create a docker Unix group. Anyone in that docker group can then access the docker API, and gain root privileges on the system. [root@rhel8 ~] #  yum install cockpit-docker    -y  Once the package installed then "containers" section would be added in the dashboard and we can manage the containers and images from the console. We can search or pull an image from docker hub just by searching with the keyword like nginx centos.   Once the Image downloaded we can start a contai

Remote Systems Management With Cockpit

The cockpit is a Red Hat Enterprise Linux web-based interface designed for managing and monitoring your local system, as well as Linux servers located in your network environment. In RHEL 8 Cockpit is the default installation candidate we can just start the service and then can start the management of machines. For RHEL7 or Fedora based machines we can follow steps to install and configure the cockpit.  Following are the few features of cockpit.  Managing services Managing user accounts Managing and monitoring system services Configuring network interfaces and firewall Reviewing system logs Managing virtual machines Creating diagnostic reports Setting kernel dump configuration Configuring SELinux Updating software Managing system subscriptions Installation of cockpit package.  [root@rhel8 ~] #  dnf   install cockpit cockpit-dashboard  -y  We need to enable the socket.  [root@rhel8 ~] #  systemctl enable --now cockpit.socket If firewall is runnin

Containers Without Docker on RHEL/Fedora

Docker is perfectly doing well with the containerization. Since docker uses the Server/Client architecture to run the containers. So, even if I am a client or developer who just wants to create a docker image from Dockerfile I need to start the docker daemon which of course generates some extra overhead on the machine.  Also, a daemon that needs to run on your system, and it needs to run with root privileges which might have certain security implications. Here now the solution is available where we do not need to start the daemon to create the containers. We can create the images and push them any of the repositories and images are fully compatible to run on any of the environment.  Podman is an open-source Linux tool for working with containers. That includes containers in registries such as docker.io and quay.io. let's start with the podman to manage the containers.  Install the package  [root@rhel8 ~] # dnf install podman -y  OR [root@rhel8 ~] # yum