What is an Active Directory?

We said Microsoft had the biggest implementation by force of numbers of LDAP. Their implementation is Active Directory, and it brings together a suite of protocols. And this is a very powerful implementation. It brings together LDAP. We’ve already said LDAP requires the use of DNS for the domain component. And so Active Directory uses DNS for Port 53, TCP 53 for zone transfers when it’s exchanging DNS information between different DNS servers, and UDP when it’s supporting communication between a server and a client. The TCP element is when the servers are talking to each other, gives the additional reliability, the error check. Within Microsoft implementation it supports Kerberos on the LAN, and it also supports certificate services.

Built-in support for PKI for certificate, for Public Key Infrastructure is powerful. We’ll look at that in a few slides time. Very, very useful, and it allows integration with technologies like 802.1X for authentication to wireless or to the network at Layer 2. So this can be a certificate-based authentication.

Concepts within Active Directory. We have objects, and an object can take many different forms - user, some kind of resource, a computer. We then have a forest, trees, and domains. These are different ways of dividing, logically subdividing, the LDAP repository into subgroups. So within a deployment, objects are grouped into different domains. And domain belongs to a tree. So a tree can have many domains. And a forest can have many trees. So you have a kind of hierarchical nesting of user objects within domains, domains within trees, and trees within forests. A domain is defined as a logical group of network objects, can be, as we said, computers, users. And these share the same Active Directory database.

A tree becomes a collection of one or more domains and domain trees in the same namespace.

Domains and trees must be in the same namespace to be within the same forest. At the top of the structure is our forest. A forest is a collection of trees that share a common global catalogue, a common directory schema, a common logical structure, and a common directory configuration.

Within Active Directory, we have a number of different servers. Helpfully, the domain controllers each hold a copy of the Active Directory tree. And so this allows for us to decentralize, to localize traffic, but also to provide resilience. There are a number of different roles that exist that are required within Active Directory. We have the schema master. There is one schema master per forest, and this helps us to standardize the format, all those different attributes, the schema that the LDAP implementation is using. And we have one per forest because we’ve just said that each forest needs a common schema. We have a domain naming master. And again, we have one of these forests.

This allows for the addition and the removal of domains from our forest. We have a PDC emulator. This is a bit of a throwback to Windows NT. We have one of these per domain, so we have far more PDC emulators, one per domain. The PDC emulator emulates the functions performed by the older primary domain controller. One of the key functions it serves though, is to coordinate password changes. If we have multiple domain controllers and a user changes that password at two different locations in close proximity in close time to each other, the PDC emulator coordinates all password changes. They’re all routed to the PDC emulator for it to coordinate.

We have the RID master, the Relative ID master. We have one of these per domain. This allocates the unique identifiers to each object within the domain. So if we create a new user, it’s granted a unique identifier, a UID. The RID master performs the task of ensuring that these are allocated and that they remain unique. We have an infrastructure manager role. We have one of these per domain. This synchronizes cross-domain group memberships, and the infrastructure master should not be run on the same server as the global catalogue. And we want to break that up for purposes of resilience. And you can co-locate those services, but it is best practice not to.

Within a forest, and between forests, we have different kinds of trust. So we can ask domains to trust each other or not.

And there are various ways: various titles, various ways of doing this. So with a one-way trust, this is where one domain allows access to users on another domain. So here domain A is trusting the users of domain B, but domain B is not trusting domain A back. This is a one-way relationship, a one-way trust relationship. We can have a two-way trust, which is where two domains trust each other. So the users on both domains become trusted entities. We can have a transitive trust.

And this is where if we had two domains in a forest, let’s say, domain A and domain B, if domain A forms a transitive trust with a third party domain, that trust will extend from domain A and encompass also domain B. The transitive means that it extends it, propagates forward that trust relationship. Conversely, an intransitive trust is a trust that does not extend. So if we have the third party domain, and our domain A and B within the same forest, if the third party created the trust, and intransitive trust with domain A, that would not extend then to domain B. Finally, we have a forest trust.

This is where the entire forest trusts another element of the domain or another forest. This can be transitive or intransitive. It can be a one-way trust or two-way trust.