Introduction to FSMO Roles
So far in this article series, I have explained that the Active Directory consists of a forest filled with domain trees, and that the names of each domain indicate its position within the forest. Given the hierarchical nature of the Active Directory, it might be easy to assume that domains near the top of the hierarchy (or rather the domain controllers within those domains) are the most important. This isn't necessarily the case though. In this article, I will discuss the rules that individual domain controllers play within the Active Directory forest.
Earlier in this series, I talked about how domains in Windows NT were all encompassing. Like Active Directory domains, Windows NT domains supported the use of multiple domain controllers. Remember that domain controllers are responsible for authenticating user logons. Therefore, if a domain controller is not available then no one will be able to log on to the network. Microsoft realized this early on and designed Windows to allow multiple domain controllers so that if a domain controller failed, another domain controller would be available to authenticate logons. Having multiple domain controllers also allows the domain related work load to be shared by multiple computers rather than the full burden falling on a single server.
Although Windows NT supported multiple domain controllers within a domain, one of these domain controllers was considered to be more important than the others. This was known as the Primary Domain Controller or PDC. As you may recall, a domain controller contains a database of all of the user accounts within the domain (among other things). This database was called the Security Accounts Manager, or SAM database.
In Windows NT, the PDC stored the master copy of the database. Other domain controllers within a Windows NT domain were known as Backup Domain Controllers or BDCs. Any time that a change needed to be made to the domain controller’s database, the change would be written to the PDC. The PDC would then replicate the change out to all of the BDCs in the domain. Under normal circumstances, the PDC was the only domain controller in a Windows NT domain to which domain related updates could be applied. If the PDC were to fail, there was a way to promote a BDC to PDC, thus enabling that domain controller to act as the domain’s one and only PDC.
Active Directory domains do things a little bit differently. The Active Directory uses a Multi master replication model. What this means is that every domain controller within a domain is writable. There is no longer the concept of PDCs and BDCs. If an administrator needs to make a change to the Active Directory database, the change can be applied to any domain controller in the domain, and then replicated to the remaining domain controllers.
Although the multimaster replication model probably sounds like a good idea, it opens the door for contradictory changes. For example, what happens if two different administrators apply contradictory changes to two different domain controllers at the same time?
In most cases, the Active Directory assumes that the most recent change takes precedence. In some situations, the consequences of a conflict are too serious to rely on this type of conflict resolution. In these cases, Microsoft takes a stand point that it is better to prevent a conflict from occurring in the first place than to try to resolve the conflict after it happens.
To handle these types of situations, Windows is designed to designate certain domain controllers to perform Flexible Single Master Operation (FSMO) roles. Essentially this means that Active Directory domains fully support multimaster replication except in certain circumstances in which the domain reverts to using a single master replication model. There are three different FSMO roles that are assigned at the domain level, and two additional roles that are assigned the forest level.
Where are the FSMO Roles Located?
For the most part, the FSMO roles pretty much take care of themselves. It is important however for you to know which domain controllers host these roles. By default, the first domain controller in the forest hosts all five roles. As additional domains are created, the first domain controller brought online in each domain holds all three of the domain level FSMO roles.
The reason why it is so important to know which domain controllers hold these roles is because hardware eventually gets old and is decommissioned. I once saw a situation in which a network administrator was preparing to deploy an Active Directory network for his company. While waiting for the newly ordered servers to arrive, the administrator installed Windows onto a junk PC so that he could begin playing around with the various Active Directory management tools.
When the new servers finally arrived, the administrator configured them as domain controllers in the already created domain rather than creating a new forest. Of course this meant that the junk PC was holding the FSMO roles for the domain in the forest. Everything worked fine until the administrator decided to remove the “junk” PC from the network. Had he properly decommissioned this server, there would not have been a problem. Being inexperienced though, he simply reformatted the machine’s hard drive. All of a sudden the Active Directory began to experience numerous problems. If this administrator had realized that the machine that he had removed from the domain was hosting the domain and forest’s FSMO roles, the problems could have been avoided. Incidentally, in a situation like this there is a way of seizing the FSMO roles from the deceased server so that your network can resume normal operations.
What are the FSMO Roles?
I will talk more about the specific functions of the FSMO roles in the next article in this series. I do however want to quickly mention what these roles are. As you may recall, I mentioned that there are three domain specific roles, and two forest specific roles.
The domain specific roles include the Relative identifier, the Primary Domain Controller Emulator, and the Infrastructure Master. Forest level roles include the Schema Master and the Domain Naming master. Below is a brief description of what these roles do:
Schema Master: maintains the authoritative copy of the Active Directory database schema.
Domain Naming Master: maintains the list of domains within the forest.
Relative Identifier Master: responsible for ensuring that every Active Directory object at a domain receives a unique security identifier.
Primary Domain Controller Emulator: acts as the Primary Domain Controller in domains containing domain controllers running Windows NT.
The Importance of FSMO Roles
In the previous part of this article series, I explained that Active Directory domains use multi master replication except in certain situations in which it is critically important to avoid a conflict. In those situations, Windows reverts to a single master replication model in which a single domain controller acts as the sole authority for the change in question. These domain controllers are said to hold Flexible Single Operations Master (FSMO) roles.
As I explained in Part 7 of this article series, there are five different FSMO roles. Two of these roles exist at the forest level, and three of the roles exist at the domain level. The Forest level roles include the Schema Master and the Domain Naming master, while the domain level FSMO roles include the Relative Identifier Master, Primary Domain Controller (PDC) Emulator, and Infrastructure Master.
I actually debated as to whether or not to discuss FSMO roles so early in this article series. Ultimately I decided to go ahead because FSMO roles are so important to supporting Active Directory functionality.
As I’m sure you probably know, in order to be able to function, the Active Directory requires that the DNS services are accessible and that the domain have at least one domain controller. When an Active Directory based network is initially created, the first domain controller to be brought online is almost always configured to act as the network’s DNS server. This same domain controller is also assigned all five of the FSMO roles. If other domains are created within the forest, then the first domain controller within each domain will host the FSMO roles for that domain. The forest level FSMO roles are only hosted on a single domain controller regardless of the number of domains in the forest.
I tell you this because I want to talk about what will happen if a domain controller that is hosting the FSMO roles fails. If the domain controller that contains the forest level FSMO roles fails, you are definitely going to notice the problem. It isn’t that the FSMO roles themselves are all that critical to the network’s operation, but rather that the domain controller that hosts the forest level FSMO roles is usually also hosting the DNS services, which are considered critical to Active Directory. If the DNS services were hosted on a separate server and the domains within the forest each had more than one domain controller, you probably wouldn’t even notice the failure for a while (unless you had monitoring software to alert you to the failure).
Usually, there are no immediate consequences to an FSMO role failure, but some rather strange symptoms will develop later on if the problem is not corrected. That being the case, it is important to know the signs of an FSMO role failure. It is also important for you to know how to determine which server is hosting each FSMO role. That way, if symptoms matching that of an FSMO failure occur, you can check to see which server is hosting the role that may have failed, and can then begin the troubleshooting process on that server.
The Schema Master
The Active Directory is really nothing more than a database, and like any other database, the Active Directory contains a schema. Unlike many other databases, the Active Directory’s schema is not static. There are any number of operations that require extending the schema. For example, installing Exchange Server requires the Active Directory schema to be extended. Any time that changes are made to the Active Directory schema, those changes are applied to the Schema Master.
The Schema Master is by far the most critical of the FSMO roles, so Microsoft hides it from view. If you need to find out which server is hosting the Schema Master role, then insert your Windows Server 2003 installation CD, and double click on the ADMINPAK.MSI file that’s found in the CD’s I386 directory. When you do, Windows will launch the Administration Tools Pack Setup Wizard. Follow the wizard’s prompts to install the Administration Tools pack.
When the installation process completes, close the Setup wizard and open the Microsoft Management Console by entering the MMC command at the Run prompt. When the console opens, select the Add / Remove Snap-In command from the File menu. When you do, Windows will display the Add / Remove Snap-in properties sheet. Click the Add button found on the properties sheet’s Standalone tab to reveal a list of available snap-ins. Select the Active Directory Schema snap-in from the list and click the Add button, followed by the Close and OK buttons.
Now that the snap-in has been loaded, right click on the Active Directory Schema container and select the Operations Master command from the resulting shortcut menu. You will now see a dialog box that tells you which server is acting as the forest’s Schema Master.
The Domain Naming Master
As I have already explained, an Active Directory forest can contain multiple domains. It’s the Domain Naming Master’s job to keep track of these domains. If the Domain Naming Master were to fail, then it would be impossible to create or remove domains until the Domain Naming Master comes back online.
To determine which server is acting as the Domain naming Master for the forest, open the Active Directory Domains and Trusts console. When the console opens, right click on the Active Directory Domains and Trusts container and select the Operations Masters command from the resulting shortcut menu. When you do, Windows will display the Domain Naming master.
The Relative Identifier
As you know, the Active Directory allows administrators to create Active Directory objects on any domain controller. The catch is that each object must have a unique relative identifier number. To prevent relative identifier numbers from being duplicated, the Relative Identifier Master allocates a pool of relative identifiers to each domain controller. When a new object is created within a domain, the domain controller that the object is being created on takes one of its relative identifiers out of its pool and assigns it to the object. When the pool is exhausted, the domain controller must contact the Relative Identifier Master for additional relative identifiers. As such, the eventual symptom of a Relative Identifier Master failure is the inability to create objects in the Active Directory.
To determine which server is acting as the Relative Identifier for a domain, open the Active Directory Users and Computers console. When the console opens, right click on the listing for the current domain and select the Operations Masters command from the resulting shortcut menu. When you do, Windows will display the Operations Masters properties sheet. You can determine which domain controller is acting as the Relative Identifier by looking at the properties sheet’s RID tab.
The Primary Domain Controller Emulator
Throughout this article series, I have talked about the role that the Primary Domain Controller (PDC) plays in Windows NT environments. The PDC emulator role was created to allow Active Directory domain controllers to co-exist with Windows NT domain controllers. The basic idea was that when an organization is being upgraded from Windows NT to Windows 2000 or to Windows Server 2003, the PDC is the first domain controller to be upgraded. At that point, the newly upgraded domain controller functions both as an Active Directory domain controller and as a PDC to the domain controllers that are still running Windows NT.
Today the PDC emulator role is largely irrelevant because very few organizations still use Windows NT Server. If you need to determine which server in your domain is hosting the PDC Emulator role though, you can do so by opening the Active Directory Users and Computers console. When the console opens, right click on the listing for the current domain and select the Operations Masters command from the resulting shortcut menu. When you do, Windows will display the Operations Masters properties sheet. You can determine which domain controller is acting as the PDC Emulator by looking at the properties sheet’s PDC tab.
The Infrastructure Master
In an Active Directory environment, a forest can contain multiple domains. Of course the implication of this is that Active Directory domains are not completely independent entities. They must occasionally communicate with the rest of the forest. This is where the Infrastructure Master comes into play. When you create, modify, or delete an object within a domain, the change will naturally be propagated throughout the domain. The problem is that the rest of the forest is not aware of the change. It’s the Infrastructure Master’s job to make the rest of the forest aware of the change.
If an Infrastructure Master server fails then changes to objects will not be visible across domain boundaries. For example, if you were to rename a user account, the user account would still appear to have its old name when viewed from other domains in the forest.
To determine which server is acting as the Infrastructure Master for a domain, open the Active Directory Users and Computers console. When the console opens, right click on the listing for the current domain and select the Operations Masters command from the resulting shortcut menu. When you do, Windows will display the Operations Masters properties sheet. You can determine which domain controller is acting as the Infrastructure Master by looking at the properties sheet’s Infrastructure tab.
Active Directory Information
In the last few parts of this article series, I talked a lot about what the Active Directory is, and how it works in regards to your network's domain controllers. You already know from the previous articles in this series that the Active Directory is essentially a database containing various objects such as user accounts and computer accounts. In this article, I want to continue the discussion by showing you how the Active Directory is structured.
If you have ever used Microsoft Access or SQL Server, then you are probably used to being able to open the database and view it in its entirety. However, none of the primary administrative tools used for managing the Active Directory will allow you to see the entire Active Directory database. Instead, Microsoft provides you with a variety of management tools that each focus on a specific area of the database. As a new administrator, the administrative tool that you will probably use the most often is the Active Directory Users and Computers console.
You can access the Active Directory Users and Computers console from any Windows Server 2003 domain controller by selecting the Active Directory Users and Computers command from the server’s Start / All Programs / Administrative Tools menu. The console itself looks something like what you see in Figure A
Figure A: The Active Directory Users and Computers console is the primary administrative tool for managing Active Directory objects.
I will later discuss the process of creating or editing Active Directory objects, meanwhile I wanted to go ahead and show you this console because it reveals a little bit the structure of the Active Directory. If you look at Figure A, you will notice that there are a number of containers, each of which correspond to a specific object type. Every object in the entire Active Directory is assigned an object type (known as an object class). Each object also has a number of attributes associated with it. The specific attributes vary depending on the object type.
For example, the Users container is filled with user accounts, which are all classified as user objects as shown in Figure B. If you were to right click on one of these user objects and choose the Properties command from the resulting shortcut menu, you would see the user objects' properties sheet, as shown in Figure C.
Figure B: The Users container is filled with user accounts, which are all classified as user objects.
Figure C: When you right click on a user object and select the Properties command from the resulting shortcut menu, you will see the user’s properties sheet.
If you look at figure C, you will see that there are fields for various pieces of information such as first name, last name, telephone number, etc. Each of these fields corresponds to a specific attribute of the individual object. Although the majority of the fields shown in the figure are not populated, in a real life situation these fields could be used to create a corporate directory. In fact, many applications are designed to extract information directly from the Active Directory. For example, Microsoft Exchange Server (Microsoft’s e-mail server product) creates a global address list that is based on the contents of the Active Directory. This global address list is used when sending e-mail messages to other users in the company.
If you look at Figure D, you can see a screen in which I performed a search on the name Hershey (my cat’s name in case you are wondering), and Outlook returned all of the Global Address List entries that contain the name Hershey. Not surprisingly there is only one result. If you look at the results portion of the window though, you can see where Outlook would display the user’s title, business phone number, and location had these fields been populated. All of this information was extracted from the Active Directory.
Figure D
If you wanted to see even more information about the user, you could right click on the user’s name and choose the Properties command from the resulting menu. Doing so would display the screen shown in Figure E. Keep in mind that this is not an administrative screen. This is a screen that any user in the company can access directly through Outlook 2007 in order to find information about other employees.
Figure E: You can view Active Directory information directly through Microsoft Outlook.
It is easy to dismiss the significance of what I just showed you. After all, Outlook is a Microsoft product, so it only makes sense that Outlook would be able to extract information from the Active Directory which is a part of another Microsoft product.
What a lot of people do not realize though, is that it is fairly easy for anyone with the appropriate permissions to extract information from the Active Directory. In fact, there are countless third party products that are designed to interact with the Active Directory. Some are even capable of storing data in dedicated Active Directory partitions.
The reason why it is possible for you or for third party software vendors to interact with the Active Directory is because the Active Directory is based on a well known standard. The Active Directory is based on a standard called X.500. The X.500 standard is basically just a common way of implementing a directory service. Microsoft is not the only company to create a directory service based on this service. Novell originally created the NetWare Directory Service based on this standard.
There is also a standard way of accessing directory service information. In an Active Directory environment, accessing directory information involves using the Lightweight Directory Access Protocol, otherwise known as LDAP. The LDAP protocol runs on top of the TCP/IP protocol.
The first thing that you need to know about the LDAP protocol is that whoever named it must have been on crack, because there is nothing lightweight about it (although it is more lightweight than the original directory access protocol, which was not designed to take advantage of the TCP/IP protocol stack). Entire books have been written on LDAP, and an in depth discussion is not really appropriate at this point in the article series.
What I will tell you is that every object in the Active Directory is refered to by a distinguished name (often abbreviated as DN). The distinguished name is based on the object’s position within the directory hierarchy. There are many different components that can go into a distinguished name, but some of the more common ones are a common name (abbreviated as CN) and a domain name (abbreviated as DC). For example, suppose that the Contoso.com domain contained an account named User1, and the account was located in the Users container. In such a situation, the distinguished name for the user account would be:
CN=User1, CN=Users, DC=Contoso, DC=com
Distinguished Names
n the previous part of this article series, I explained that the LDAP protocol references objects in the Active Directory by their distinguished name, and that every object in the directory has its own unique distinguished name. In this article, I want to continue the discussion by explaining how distinguished names work.Before I Begin
Before I get started, I just want to remind you that distinguished names are not unique to the Active Directory. Microsoft built the Active Directory to take advantage of industry standards which are used by other companies such as Novell and IBM. By learning how distinguished names work, you will not only be better prepared to manage an Active Directory environment, you will also have some degree of familiarity if you are ever asked to work with a non Microsoft network operating system.
Basic Naming Rules
Distinguished names are made up of attributes, which are assigned values. A single distinguished name almost always contains multiple attribute value pairs. To see what I am talking about, let’s look at a simple distinguished name:
CN=User1, CN=Users, DC=Contoso, DC=com
In this particular example, the distinguished name is made up of four different attribute / value pairs, each of which are separated by a comma. The first attribute / value pair is CN=USER1. In this attribute / value pair, CN (which stands for Common Name) is the attribute and User1 is the value. Attributes and values are always separated by the equals sign, and attribute / value pairs are always separated from each other by commas.
Relative Distinguished Names
When you look at a distinguished name such as CN=User1, CN=Users, DC=Contoso, DC=com, one thing probably becomes immediately apparent; distinguished names can be really long. If you take a closer look at this distinguished name, you will notice that it is hierarchical. In this particular case, DC=com represents the highest level of the hierarchy. DC=Contoso represents the second level of the hierarchy. You can tell that COM and Contoso are both domains because both use the DC attribute. The domain hierarchy mimics the domain hierarchy used by DNS servers (you learned about the DNS hierarchy earlier in this series).
It is important to understand how the distinguished name hierarchy works for two reasons. First, by understanding the naming hierarchy, it becomes possible to know exactly where a particular object is located within the directory. The other reason why it is important to understand the nature of the directory hierarchy is because sometimes shortcuts are used in lieu of a full distinguished name.
To see what I am talking about, let’s take another look at our example distinguished name: CN=User1, CN=Users, DC=Contoso, DC=com. This distinguished name simply refers to a user account (more precisely known as a user object) named User1. The rest of the information in the distinguished name simply tells us the object’s position within the directory hierarchy.
If you were trying to tell another person about this object, you would probably casually refer to it as User1. Sometimes LDAP does the same thing. This is possible because it isn’t necessary to provide information about an object’s location in the hierarchy if the location is already known.
For example, if we are performing some operation on user objects located in the Users container in the Contoso.com domain, is it really necessary to explicitly state that every single object is located in the Contoso.com domain’s Users container?
In situations like this, the distinguished name is often replaced by a Relative Display Name (abbreviated RDN). In the case of CN=User1, CN=Users, DC=Contoso, DC=com, the RDN is CN=User1. The RDN is always made up of the most specific identifier. This will be the left most attribute / value pair in the distinguished name. The remaining portion of the distinguished name is known as the parent distinguished name. In this particular case, the parent distinguished name would be CN=Users, DC=Contoso, DC=com.
Before I move on, I want to mention that Microsoft tends to use a slightly different distinguished name format than some other network operating system manufacturers. As you have already seen, Microsoft’s distinguished names tend to be based on containers and domains. There is certainly nothing wrong with this format, because it does comply with RFC 2253, which sets the rules for distinguished names.
Some of the other network operating systems tend to base their distinguished name hierarchies on companies and countries rather than containers and domains. In these types of distinguished names, the attribute O is used to designate an organization (company) name, and the letter C is used to designate a country name. Using this naming convention, the distinguished name CN=User1, CN=Users, DC=Contoso, DC=com would look something like this:
CN=User1, O=Contoso, C=US
Keep in mind that the two formats both comply with RFC 2253, but they cannot be used interchangeably. Remember that a distinguished name’s job is to describe an object and its position within the directory. The reason for the two different distinguished name formats is that Microsoft structures their directory differently than some of their competitors.
Special Characters in Distinguished Names
So far you have seen that commas and equal signs have special meaning in the context of a distinguished name. There are several other characters that also have special meanings. These characters include the plus sign, the greater than and less than signs, the number sign, the back slash, and the quotation mark. I’m not going to bother covering most of these because you will rarely, if ever, have to use them in real life.
I do however want to talk about the back slash. The back slash allows you to tell an LDAP statement to ignore the following character. This allows you to store otherwise forbidden characters in your directory.
To see how this is of use, consider that full names are often expressed as last name comma first name. Even so, LDAP does not allow you to use the statement CN=Smith, John because the comma is used by LDAP to separate attribute / value pairs. If you wanted to store the value Smith, John in the directory, you could do so by making use of the back slash, as shown below:
CN=Smith\, John
In the statement above, the back slash tells LDAP to treat the comma as data rather than as a part of the command syntax. Another way to accomplish this is to surround the entire attribute value by quotation marks. Everything within the quotation marks is treated as data rather than as a part of the syntax.
There is a special rule regarding the use of the back slash within quotation marks. The back slash can only be used to force LDAP to ignore another back slash. To put it simply, if you needed to include a back slash as a part of the data, you would simply use two back slashes instead of one. Any other use of the back slash between quotation marks is considered to be illegal.
RSS Feed (xml)
No comments:
Post a Comment