Posts tagged 10 Minute Guides

How do we define object types in AD? Through Schema, a kind of blueprint describing the attributes of that object and what type of data they can hold (Syntaxes).

But, what about if I’m merging two different organizations with different Schema?  How can I distinguish between Time Warner’s Contractor vs. AOL’s Contractor object?  Fortunately, the X.500 standard defines an Object Identifier (OID) to identify each schema object:

• First part indicates the path to the branch holding the object in a 500 tree-like structure
• The second part uniquely indicates the object in that branch

The notation uses integers for each branch and object. Ex:

1.3.6.1.4.1.495 refers to object 495 in branch 1.3.6.1.4.1

To create a schema object, you need to have a unique OID branch & namespace for your organization.  You can refer to the IANA web page http://www.iana.org/ for more information on how to do this.

While we’re talking about objects, we should talk about what happens when you delete an object in AD.  You would think that it immediately gets deleted, right?  Nope.  It gets tombstoned.

The object is stripped of most of its attributes and gets moved to the Deleted Objects container.  Why does this happen? Well for one, you can undelete the object in case you made a mistake. And more importantly, these allows the delete operation to replicate to all domain controllers holding a copy of the object.

Finally, we’ll wrap up on a quick word on how you can define different classes.  Suppose you had a Contractor type in your organization.  The contractor type would probably share a lot of attributes with the User class.  It would be nice if you didn’t have to redefine everything.

Well, with class inheritance we can do exactly this.  Our schema classes can be defined as one of three things:

• Structural

These types of classes allow you to directly create objects of its type in AD.  For example, the group class.

• Abstract

If you’re familiar with object oriented programming, abstract schema classes behave just like abstract classes in programming.  They allow you to define a base set of attributes that are shared by any derived class but you would never want to create an instance of that base type.  Abstract classes are the same as structural, with the only difference being you cannot instantiate abstract types.

• Auxiliary

An auxiliary class is used to store sets of attributes that other classes can inherit.  You can think of these classes as a grouping mechanism to tie together a collection of loosely coupled attributes.  For example, the securityPrincipal is an auxiliary class that is inherited by the organizationalPerson class.  SecurityPrincipal attributes such as SID exists tangentially to a Person object; they can be applied to a person, a computer, a group, or anything that requires it to be a security principal.  Thus, it’s perfectly suited to be an auxiliary class.

Let’s step back for a second, and ask what is a domain in AD?  Really, it’s a big data partition that has some special rules on how that data gets replicated in a multimastery environment.  We refer to this as a naming context (NC). Only DCs that are authoritative for a domain need to replicate all the information within that domain. 

But, some data in AD must be replicated across all DCs within a forest:

Domain Naming Context: Each Active directory domain has a Domain Naming context, which contains domain specific data.  It’s represented by the domain’s DN and is replicated across every DC in the domain.

Configuration Naming Context: This NC is responsible for the configuration information for a forest and is replicated to every DC in the forest.

Schema Naming Context: The Schema NC contains objects that represent the object types and attributes that the AD deployment supports.  This is forest wide so it’s replicated across the forest.

But what if we wanted to leverage this multimastery replication mechanism for ourselves?  What if I had some data that’s only useful for my organization. Let’s say my org, an international crime syndicate, decided it needed to deploy AD across different continents.  And since the operations in Japan don’t affect the crime wing in the US, I wouldn’t need to replicate all the mob opportunities happening in Japan to my counterparts to the US. 

But, our mob deals don’t really fall into the categories listed above.

Luckily, we can also define our own partitions (application partitions) with our own replication rules (Note: they can contain everything but security principals e.g. users, groups).  You get to define which domain controllers hold a copy of each application partition, which is known as a replica.  However, with great power comes great limitations:

• They cannot contain security principals e.g. users, groups, computer objects
• Objects are not replicated to the global catalog
• Objects cannot be moved outside the partition

So what’s a more common use case for application partitions?  Well assuming you’re not an international crime syndicate, app partitions tend to store dynamic data. Ex: dynamic data from DNS, or DHCP.  (Dynamic data has a default Time To Live or TTL after which it gets deleted

Welcome the first post in a high level crash course on Active Directory.  In the same vein as the Khan Academy, these posts are meant to be consumable or explainable in 10 minutes or less.  But unlike Sal, I’ll be providing these in text format instead of a video.  The intended audience is for someone who is technically proficient but may not know about AD and would like to ramp up to speed in a very short time while grasping all the major points about AD.  If you’d like an in-depth guide, check out this great book  written by AD experts.

Active Directory is a big central directory or repository of information.  You can think of the data stored in AD the same way it’s stored in a file system; and it’s presented in the same hierarchical manner to the user, just like a file system. Each object can be a container (“folder”) or a non-container (aka a leaf node or “file”). 

So how do we reference an object in this big directory?  Just like a filesystem, we can use it’s name, which is called it’s RDN (Relative Distinguished Name).  The RDN tells us the name of the object relative to its parent; and what happens when two objects in the same container (“folder”) have the same RDN?  Well you can’t! Same goes for two files in the same folder.

We can also refer to an object using its full “filepath” or it’s DN (Distinguished Name).  This uniquely identifies any object in the directory just like any object in a filesystem.

Finally, each  object has a GUID assigned to it, but since the GUIDs are hard to remember, we generally use DNs or RDNs.

What do these DNs or RDNs look like?

DN to a folder: cn=Users,dc=ikrima,dc=com

RDN: cn=Users

The file system equivelent would be:

C:\ikrima\Users

Users

You may hear the phrase LDAP (Lightweight directory access protocol); just think of this as a standard mechanism to access directories.

There are several attribute prefixes that are valid when describing a DN but the most common ones you’ll see are ou & cn.  For now, just think to always use OU since Group Policy can be applied to OU.  We’ll talk about use cases for why this is good later.

Active Directory is responsible for describing your corp’s domains. So how is the AD domain constructed?

• An x.500 based hierarchical structure of containers and objects

• A DNS domain name as a unique identifier

• A security service that’s in charge of authentication and authorization of resources

• Policies that dictate how functionality is restricted to certain accounts

It’s important to note that a  domain controller (DC or server running AD) can be authoritative for only one domain.  We can group domains into a domain tree.  Why would you want to do this?  Imagine having these domains  ikrima.com -> us.ikrima.com, emea.ikrima.com

A forest is a collection of these domain trees: ikrima.com & ikrimapersonal.com.  They share a common configuration container & schema and by default, have  implied transitive trust (more on all of this later).  An important consequence of this is that if you have business units that are independent and want to keep them isolated, then you have to place them in different forests.

Now you might ask, how do I access objects in my forest if there are multiple domain controllers (AD servers)?  Does every DC maintain copies of every object? Sounds inefficient, right?  Well, AD has this important concept of a Global Catalog, which is used precisely for these forest-wide searches.  It has a catalog of all the objects in a forest, but only maintains a partial list of attributes most often used for searching.  The GC is read only and replicated along servers that are defined as GC servers.  Now, what exactly are these attributes? Well there’s a default set but they are configurable (Partial attribute set).  Given this PAS, how does AD replicate the thousands upon thousands of objects to other AD servers?  More on the details of this later, but first we should talk about multimastery.

AD is multimaster directory (means just like it sounds, data is stored by multiple computers and can be updated by any member of the group).  But does that mean every operation can happen on any server?  Well, let’s consider what would happen if I changed the Schema (blueprint of your objects).  What would happen to the AD domain controllers that didn’t get this replicated change? And then what would happen if you made a conflicting change on that DC?  So it would make sense to allocate certain operations to single AD servers.

These are called Flexible Single Master Operators (FSMOs) and there are 5 types.  Some of these are per domain in your forest and some are per forest:

Schema Master(forest wide): owns schema updates

Domain Naming Master(forest wide): owns changes to the forest namespace e.g. adding/removing/renaming domains

PDC Emulator (domain wide): for back compat, acts as the Win NT Primary Domain Controller.  But it also maintains the latest password for any account

RID Master: If you’re familiar with SIDs, then this DC is responsible for allocating SID pools to other DCs. If not, think of a SIDs as security identifiers to uniquely identify users (and other security enabled objects).

Infrastructure Master(domain wide): Maintains references to objects in other domains. If users from Domain A are in a group in Domain B, the Infrastructure Master is responsible for maintaining these phantom objects

Now if these roles are assigned to a single DC, that would imply we would have some single points of failure.  What would happen if that one server went down?  How do we avoid this catastrophe?

Turns out, the immediate availability of each FSMO role owner is not as important as it might seem.  Let’s consider what would happen if each FSMO went down:

1. Schema Master: Well, you couldn’t make changes to your schema.  And usually that is an infrequent operation that is generally planned well in advance. So not a big deal
2. Domain naming master: Same as above. No big deal
3. Infrastructure master: Cross domain phantom updates will stop. Generally the updates happen over a period of a couple of days so you probably have some buffer time to bring it back up
4. RID Master: RIDs are allocated in pool blocks of 500 to DCs and when the DC exhausts 50%, they request another pool block.  So again, not super critical to bring this FSMO back online immediately
5. PDC Emulator: This DC is probably the most important out of the five.  Legacy APIs will talk to this DC and there are other items we haven’t discussed that are rooted in this DC (password chaining, time sync hierarchy, etc).  So, it’s important that this FSMO owner is in high availability

You might also wonder, how do different versions of AD interoperate with each other?  Does MS mandate that all DCs be a certain version?  The answer is functional levels: these are different levels that have an associated list of features that become available when the domain or the forest reaches a particular functional level. They also dictate the minimum OS Version (aka AD version) that can be deployed in a certain domain/forest.

Finally, we end on groups.  Groups can be of two types: distribution (mailing list) or a security group (which gets assigned a SID that enables access control for its members).  On top of that, there are three different scopes: domain local, domain global, and universal.

Local & Global groups can only have their members from the domains their created in.  Universal groups can have members from anywhere in the forest.  What’s the difference between local & global? Local groups can be used in Access Control Lists on resources contained in the same domain; Global (and Universal) groups can be used on any resource in the forest.

Now that we have a very basic understanding of AD, how does AD efficiently replicate data in its multimaster environment?  We find out next time in our continuation of this series.