Implementing Samba 4 (2014)

Chapter 7. Extending the Active Directory Schema Using Samba 4

This chapter explains how to extend the default Active Directory schema for some specific applications when using Samba 4 built in as the Active Directory Domain Controller. This chapter covers more advanced topics for which some prior knowledge of LDAP / Active Directory protocol specification and general system administration is preferred.

The process will be explained using examples and scripts to extend the Samba 4 / Active Directory schema, and will use a simple application that uses a specific object class and attribute. This is so you understand how to extend the Samba 4 LDAP schema and accommodate the attribute and class for this application.

The following is the list of topics that will be covered in this chapter:

· Key consideration points when planning an Active Directory schema extension

· Exporting the current Active Directory schema configuration

· A practical example for extending the Active Directory schema

· Applying the Active Directory schema extension

· Tests and validations of the Samba 4 Active Directory schema extension

Planning an Active Directory schema extension

The point we need to have foremost in mind when planning an Active Directory schema extension is the word "schema". As in a Relational Database Management System (RDBMS) schema [27], just in case the reader is familiar with database systems, every change we make to the predefined data types or the relationships between tables can lead to unwanted results. So, before going forward, it's important to understand what the changes are and whether or not we really need to make them; as in the case of the Active Directory schema extensions, once created they are not reversible [28].

In the Active Directory world, maybe the schema does not have much of the complexity of an RDBMS schema, but it is a crucial, very important definition all the same, as any error can lead to the unavailability of the service. The Active Directory schema maintains definitions for all objects in the directory; thus, the creation of any new object is validated using the object's definition in the schema before it can be actually written in the directory [29]. Yet, from the Active Directory schema documentation, the object classes and attributes in the default schema configuration are wide and rich, and so intended to meet the needs of most organizations [29].

Another important characteristic of how the Active Directory schema is organized is the fact that the attributes are defined in the schema separated from the classes [30]. This is really important as an attribute, for example, description, does not need to be tied to just one object class, as we can have descriptions for jobs, roles, and machines; thus, we do not need to have one specific description attribute for each of those objects.

Obviously, the possibility of extending the Active Directory schema is a real and powerful option. Its purpose is legitimate as the default schema does not suit specific use cases; this is because users and companies have different requirements and it's very difficult to have all specifications implemented in a standard configuration (such as, a schema). However, the point is that many use cases can be fulfilled with the standard options, and the general advice is to make sure that the requirements are specific enough where a schema extension is really needed. The Microsoft documentation website has great articles about Active Directory, and is an excellent resource for Active Directory terminology, syntaxes, classes, attributes, and so on [30]. So, the user can look at all the classes and attributes to get familiarized with the structure and data types.

The second point to keep in mind is that after we have realized that a schema extension is really needed by our new application / use case, we need to understand how the directory is organized and how to accommodate our changes in a way that it can coexist with other information we have and will have in the directory. A well-defined procedure is to execute the operation to extend the schema itself, and a proper procedure is to test it and make sure everything is still working and will continue to work as usual.

Some users do utilize some reserved namespaces from the X.500 standard or other options for private use. Here, we will show you how to do it properly, as the next step necessary to extend the Active Directory schema is to register with the Internet Assigned Numbers Authority (IANA) and asking for a Private Enterprise Number (PEN) [26]. IANA is the entity responsible for the global coordination of many Internet protocol resources (there are no costs; obtaining a PEN assignment is free of charge).

Tip

An Active Directory forest has just one schema and it is replicated to all the domain controllers on that forest, but only the schema master has control over its structure and content [29].

The Private Enterprise Number is needed as the classes and attributes (classSchema and attributeSchema) use an object identifier (OID) that is derived from the uniqueness of the PEN we received from IANA. Let's look at the EALL example OID 1.3.6.1.4.1.42768.2.1, so we can understand the whole tree as these objects are referenced in the following figure [37]:

As you can see in the preceding figure, we have a hierarchy that starts with the top authority (which is the root; in this case, ISO), until we get to the EALL (for example, Marcelo Leal) that owns the OID 42768, and where a more specific and fully controlled division can be executed in the EALL site. In the next steps, we will see how to create a division in our PEN and start to organize our new classes and attributes to include them in our Active Directory services. Now, let's look at the OIDs from the output of the following command executed on a Samba 4 Active Directory Domain Controller:

root@addc:~# ldapsearch -x -h localhost -s base | grep supportedCap

supportedCapabilities: 1.2.840.113556.1.4.800

supportedCapabilities: 1.2.840.113556.1.4.1670

supportedCapabilities: 1.2.840.113556.1.4.1791

supportedCapabilities: 1.2.840.113556.1.4.1935

supportedCapabilities: 1.2.840.113556.1.4.2080

root@addc:~#

Based on the Microsoft documentation [32], we can get great insights about the capabilities of this Samba 4 AD DS, as we've shown in the following table:

So, based on the preceding table, we can correlate the capabilities present on the Samba 4 version we are using as the Active Directory Domain Controller, and the correspondent Microsoft Windows Server 2008 R2 operating system Active Directory Domain Services [32]. From the capabilities described on the referenced website, we can see that the only feature not present in our Samba 4 Server AD DS for our matching to be 100 percent is LDAP_CAP_ACTIVE_DIRECTORY_PARTIAL_SECRETS_OID. However, as you can see in the notes of the web page, that capability is only exposed by the respective server in specific conditions (for example, RODC, which is an additional DC in a domain that hosts read-only partitions of the AD database).

Exporting the current Active Directory schema configuration

As usual, for us, for all procedures that will change the state and configuration of our Active Directory services, we will base our AD DS schema extension with a prior plan in place to test and validate our results. Thus, we can make sure that the environment is functional after the schema extension and everything is stable as before.

Microsoft Windows servers have a great tool that we can use to generate a file (the LDIF file) with all our schema configurations: ldifde. To use this tool, we just need to be logged into a Microsoft Windows server (for example, 2008 R2) and execute the following script in a command-line prompt window:

C:\Users\Administrator.POA> cd Desktop

C:\Users\Administrator.POA\Desktop>ldifde –f old-adds-schema.ldif \

-d CN=Schema,CN=configuration,DC=poa,DC=msdcbrz,DC=eall,DC=com,DC=br

Connecting to "adds.poa.msdcbrz.eall.com.br"

Logging in as current user using SSPI

Exporting directory to file old-adds-schema.ldif

Searching for entries…

Writing out entries .................................................

.....................................................................

.........................

1550 entries exported

The command has completed successfully

C:\Users\Administrator.POA\Desktop>

If the preceding command is executed successfully, we should have a file named old-adds-schema.ldif in our current directory; its content should be like that shown in the following excerpt:

dn: CN=LDAP-Display-Name,CN=Schema,CN=Configuration,DC=poa,DC=msdcbrz,\

DC=eall,DC=com,DC=br

changetype: add

objectClass: top

objectClass: attributeSchema

cn: LDAP-Display-Name

instanceType: 4

whenCreated: 20121113212243.OZ

Tip

It seems that there is an option to use custom OIDs inside Microsoft's private number, but we will not cover that in this book and prefer to point out the procedure so users and companies can have their own address space.

We need to save the old-adds-schema.ldif file in a well-known place on our server, as we will use it after executing our AD DS schema extension to conduct an assessment of the changes we have made. Another important tool to be used in conjunction with this file after executing the schema extension is the AD DS / LDS Schema Analyzer. This tool should be installed on Microsoft Windows Server 2008 R2 if this server has Active Directory Lightweight Directory Services installed as we do on the server exemplified in the following screenshot:

In case if it has not been installed yet, we could install it using the Add Roles Wizard, shown in the preceding screenshot, in a quick and simple process.

Extending the Active Directory schema in practice

Here, we will take a look at the requirements of our example application and the attribute it needs in Active Directory in order to work properly. It's important to keep in mind that the attribute presented here is not the most relevant part, except the procedure we will present and the points related to naming convention. Very often, I use an existing attribute to accomplish what this example application requires, but again, the procedure is the most important part here.

Tip

In a real-life scenario, you should not extend the Active Directory schema if you can use an existing attribute.

For security, a system administrator implements an authentication module (for example, the PAM module) to add another layer on the authentication process and enhance access control on the GNU/Linux servers in the environment they manage. As the schema they were using earlier was a custom version on OpenLDAP, which utilizes this module on an Active Directory environment, they need to extend its schema.

The module is named pam_hostscheck, and it needs an attribute named allowedhost containing the hostname of the host on which some user is trying to authenticate: permit (for example, allowedhost=myservername) or decline the authentication process. Note that we can have many allowedhost instances for each user object (for example, it's a multivalue attribute), as a user may be allowed to access many machines. The attribute can contain some wildcards that the application knows (for example, netgroups) and other tricky options, but that is application-specific, and the content of the attribute is not very important for our AD DS schema extension.

With this task at hand, the first concern we need to address should be that related to the attribute's name. We need to think about the present and the future and choose a name that will not conflict with other applications we may need to use. The system administrator has created this module with a cool feature to help in this matter: we can specify the name of the attribute that the module will use in a configuration file. So, for the EALL company, if the system administrator decides to use eALLallowedHost as the attribute's name, there's a very low probability that it will clash with other attribute names we may use in the future.

Extending the Active Directory schema

Before we are able to extend the Active Directory schema in Samba 4, we need to enable the schema extension feature as it is disabled by default [33]. According to the referenced Samba documentation, you can enable this feature by adding a specific option in the Samba configuration file (/usr/local/samba/etc/smb.conf), or directly on the command line [33]. We have opted for the latter.

As we need to execute three modifications on the directory for our example case, we will do it in three distinct steps to make it clearer, as I believe this way is better to understand the whole process. So, we will start adding the eALLallowedHost attribute to the AD DS, and to do that, we need to create an LDAP Data Interchange Format (LDIF) file with all the information about this new attribute to extend our AD schema. The following is the LDIF file for this (/root/eALLallowedHost.ldif):

# Samba 4 Active Directory Schema Extension for PAM_HOSTSCHECK

# byLeal

# Attribute: eALLallowedHost

dn: CN=eALLallowedHost,CN=Schema,CN=Configuration,DC=poa,DC=msdcbrz,DC=eall,DC=com,DC=br

objectClass: top

objectClass: attributeSchema

attributeID: 1.3.6.1.4.1.42768.2.1

cn: eALLallowedHost

name: eALLallowedHost

attributeSyntax: 2.5.5.12

lDAPDisplayName: eALLallowedHost

Description: Hostname the user is allowed to authenticate

oMSyntax: 64

-

In the LDIF file, the first three lines are just comments (for example, about what the file is, who created it, and the attribute name to be created). We can have as many comment lines as we think are needed to organize and provide information for the people that will handle this piece of configuration.

In an LDIF file, we always have a Distinguished Name (DN) that is composed of a common name for the object itself (for example, eALLallowedHost), and the Relative Distinguished Names (RDN), which in this case, is cn=schema,cn=configuration, plus a constant string for the Domain Component (DC): DC=poa,DC=msdcbrz,DC=eall,DC=com,DC=br.

The directive objectClass will define some characteristics (for example, type) of this object (for example, top, attributeSchema). We have a display name, a name, and a description; additionally, we have attributeSyntax (Unicode String) and oMSyntax as they are mandatory for all new attributes we create (the first is an OID and the latter is an integer) [34]. The attributeID is based on our registered OID (for example, EALL's registered OID) and the specific number assigned within the company for that new attribute.

Tip

To organize the new classes and attributes, the EALL company has chosen to reserve the number 1 for classes and 2 for attributes. So, 1.1 is the first new class created and 2.1 is the new first attribute.

Now we have the first LDIF file ready, and we can actually execute the first Active Directory schema extension. Remember to never (and I will say it again: never) execute an AD DS schema extension in production directly. All the procedures here need to be executed and tested in a lab environment, and just after you are satisfied that the procedure has proven consistent and without negative impact on your simulated environment, you can plan for an implementation in production. That being said, let's look at the following command to extend the AD DS schema:

root@addc:~# ldbmodify -H /usr/local/samba/private/sam.ldb \

/root/eALLallowedHost.ldif --option="dsdb:schema update allowed"=true

Modified 1 records successfully

root@addc:~#

Tip

Remember to have the $PATH bash variable configured with the correct location of the Samba 4 installation before all other paths in your shell, for example, export PATH="/usr/local/samba/sbin:/usr/local/samba/bin:$PATH".

As you can see in the preceding output, the command was executed and one record was modified successfully. This is good news! The next step is to add to the schema a new custom user class (for example, eALLUser), so we can associate this class with the standard user class and make our schema extension less intrusive. The following is the eALLUser.ldif file:

# Samba 4 Active Directory Schema Extension for PAM_HOSTSCHECK

# byLeal

# ------

# Class: eALLUser

dn: CN=eALLUser,CN=Schema,CN=Configuration,DC=poa,DC=msdcbrz,DC=eall,DC=com,DC=br

objectClass: top

objectClass: classSchema

cn: eALLUser

name: eALLUser

governsID: 1.3.6.1.4.1.42768.1.1

mayContain: eALLallowedHost

rDNAttID: cn

lDAPDisplayName: eALLUser

Description: EALL Custom User Class

objectClassCategory: 3

-

Tip

I don't remember talking about backup in this chapter. So, here we go… Before changing, maintaining, or even looking at a production server, perform a backup. Then, do it again. That's cool; I just said it and I already feel better!

The most important differences between the LDIF file we just saw and the first one are the objectClass type and the mayContain clause. Observe that in this specific case, we are creating a class (for example, classSchema) and not an attribute as we did earlier in the chapter. The procedure to add a class to our AD DS schema, shown as follows, is pretty much the same as described earlier:

root@addc:~# ldbmodify -H /usr/local/samba/private/sam.ldb \

/root/eALLUser.ldif --option="dsdb:schema update allowed"=true

Modified 1 records successfully

root@addc:~#

So far, so good! We are almost done; the last step we need to perform is to add our auxiliaryClass class to the user class, and for that, we can use our third and last LDIF file (User.ldif), as follows:

dn: CN=User,CN=Schema,CN=Configuration,DC=poa,DC=msdcbrz,DC=eall,DC=com,DC=br

changetype: modify

add: auxiliaryClass

auxiliaryClass: eALLUser

-

Now we can execute the last command to finish our AD DS schema extension, as follows:

root@addc:~# ldbmodify -H /usr/local/samba/private/sam.ldb \

/root/User.ldif --option="dsdb:schema update allowed"=true

Modified 1 records successfully

root@addc:~#

All executions went well and by now, we should have the new eALLUser class available on our AD DS; as you may remember, this new class may contain our new attribute eALLallowedHost. So, now we will use a Microsoft Windows 2008 Server machine that is a member of our domain in order to configure this attribute to two EALL users to make sure that the new attribute is available and really ready to be used. Follow the ensuing steps:

1. After we have logged onto the Microsoft Windows machine, we will execute the Active Directory Services Interfaces Editor tool (adsiedit.msc) to manage the new attribute for our users, as shown in the following screenshot, as the standard Active Directory Users and Computers (ADUC) Microsoft Windows tool to manage users does not work with custom attributes by default (for example, in standard mode):

2. There is a PowerShell script in the references [40] to perform a schema conflict analysis on LDIF files against the production schema. After some executions, it seems to be another good resource publicly available at the Technet Microsoft website. Looking at the source code, the drawback seems to be that the OID for Microsoft is hardcoded, and using any other OID will result in errors. The following is an excerpt of the code:

3. $OIDCheck = $values[1].StartsWith("1.2.840.113556.1").

Besides, insights provided by the script on the LDIF file can be valuable.

4. After we have been presented the default window for the ADSI Edit tool, we need to click on the top-most menu in the Action | Connect to… option, which will give us a Connection Settings window, as shown in the following screenshot:

5. Just click on OK, as the default naming context should point accurately to our domain. Just double-click on the tree structure and expand the domain component to select CN=Users, as shown in the following screenshot:

6. We will use two users for our configuration test: djfox and joliu; so, the procedure we will show for the first user will be the same as that for the second one, and that's why the second execution will be omitted. Just right-click on the djfox user and chooseProperties, as shown in the following screenshot:

7. An Attribute Editor window (CN=djfox Properties) will appear, listing all the attributes for that user. If we select the first one and start to edit eALLallowedHost, we should be routed directly to this attribute, as shown in the following screenshot:

8. Now, we double-click on the eALLallowedHost attribute, as shown in the following screenshot, and fill the value-entry field with the name of the GNU/Linux machine's host to which we want this user to be able to log in, and click on OK.

9. So, after we execute the same procedure for our second user (for example, joliu), we can close the ADSI Edit tool and go back to our Samba 4 Active Directory command-line prompt. Now, we will execute a simple search on the Active Directory to look for our brand new attribute and confirm that the changes and configurations we made on the schema are all working as expected, as shown in the following commands:

10.root@addc:~# ldbsearch -H /usr/local/samba/private/sam.ldb \

11.'(eALLallowedHost=*)' username eALLallowedHost

12.# record 1

13.dn: CN=djfox,CN=Users,DC=poa,DC=msdcbrz,DC=eall,DC=com,DC=br

14.eALLallowedHost: lnx341srv

15.eALLallowedHost: lnx511srv

16.

17.# record 2

18.dn: CN=joliu,CN=Users,DC=poa,DC=msdcbrz,DC=eall,DC=com,DC=br

19.eALLallowedHost: lnx341srv

20.eALLallowedHost: lnx511srv

21.…

22.root@addc:~#

So, we ran a quick search using the ldbsearch utility from the Samba project, and basically searched for any object on the directory that had the attribute eALLallowedHost configured on it; for those objects, we asked to be shown the username and eALLallowedHostattributes. As expected, the two users that configured the eALLallowedhost attribute were returned in the preceding query, and now the system administrator can configure the users with the hostname of the hosts or groups of hosts to which the users need access. Thus, the pam_hostscheck module can be configured to use the eALLallowedHost attribute to execute a similar search in Active Directory Domain Services, and allow or deny the user authentication process. Using pam_hostscheck as a requisite module can be a powerful security barrier, as users that do not have access to that machine will not even be provided a username/password challenge.

Tip

I had written the pam_hostscheck module many years ago, and today, we have other new and more efficient means to accomplish what I had implemented in that module. However, it was a very effective tool and a good opportunity to learn about PAM, LDAP, and schema extensions.

As the ADSI Edit tool is powerful and not intended for use in day-to-day procedures to manage users, and as we can have operators or even people who are not from the IT staff managing EALL's company users, we need to have this attribute handled in an easier manner. One option is to enable the advanced features in the Active Directory Users and Computers snap-in (ADUC).

Just take a look at the default properties window from an ADUC snap-in without the advanced features enabled, as shown in the following screenshot:

Now, let's go back to the main window of the ADUC snap-in. Just click on the item View on the top menu and check Advanced Features, as shown in the following screenshot:

After this procedure, we can just double-click on one of our users and see that the Properties screen has changed a bit, as shown in the following screenshot:

Now if we look closely, we will not only see that we have many more tabs, but also that we have one named Attribute Editor. If we select that tab and the first attribute, and start to type the name of our brand new attribute eALLallowedHost, we'll find it and be able to edit it in the same way we did using the ADSI Edit tool, as shown in the following screenshot:

But, wait! We can use the ADSI Edit tool just one more time to add the column Host Access is Allowed for our new attribute in the ADUC snap-in! Just execute the adsiedit.msc command, but this time, we will connect in a different way.

Because we used ADSI Edit the last time, it will be already connected in the same context as we need it to be in the next execution. So, we need to choose the Action item in the top menu and select Remove (you can click on Yes as it will not remove anything from your AD DS; it will just remove the currently active connection).

Now with a cleaner screen, we can select the Action | Connect to menu option, but this time, we will choose Configuration in the Select a well known Naming Context combobox, as shown in the following screenshot:

Tip

Active Directory has some extension attributes for use by companies to create custom applications, without them needing to extend the AD DS schema; these are available at http://msdn.microsoft.com/en-us/library/ms873846%28v=exchg.65%29.aspx.

The attributes in the specific Exchange Active Directory documentation seem to be for general utilization and are worth looking at before extending the schema if your application can be configured to use generic attribute names.

After the connection is established, expand the CN=Configuration and the CN=DisplaySpecifiers folders, as shown in the following screenshot:

According to the Microsoft documentation [35], the displaySpecifier objects are localized user-interface data, and so we should configure them in a locale-specific base. In our case, we will just show an example for the US-English (409) locale container.

Selecting the CN=409 folder, we can find CN=default-display in the right-hand panel (we can click on the Name column to order the entries, and so it should be the fourth line). Just double-click on it and select the first attribute in the following window, and then start typing extraColumns. You should then see the following screen:

Just double-click on the extraColumns attribute, and in the Value to add: field, we need to enter the information for our new attribute in the <ldapdisplayname>,<column header>,<default visibility>,<width>,<unused> format [36].

The first value ldapdisplayname we have specified on our LDIF file as the name of our attribute is eALLallowedHost; the column header is the name that will appear in the header of the column and so can be more descriptive; the default visibility is a Boolean value that specifies whether the attribute is by default hidden (0) or visible (1); the width is the column's width in pixels and can be a positive integer or -1, which, in turn, sets the column to the same size as the header; and the last one is unused [36], as shown in the following screenshot:

For the default visibility, we have entered 1, so we will not need to add it later (as the column default will be visible). When you click on Add, the string you have entered should be listed with the other values, as shown in the following screenshot:

Now, we can click on OK twice and close the ADSI Edit tool (we can remove this connection before we close the tool in case we want a clean start the next time). The next step is to open the ADUC snap-in, right-click on Saved Queries, and choose New | Query. The screen shown in the following screenshot will be presented where we'll name the query Host Access is Allowed:

Once you have written the name of the new query, click on the button Define Query…, and in the Find Common Queries window, select the Custom Search option, as shown in the following screenshot:

Now, we need to select the Advanced tab and run the following simple search to filter all objects (for example, users) that have the eALLallowedHost attribute configured, as shown in the following screenshot:

Just click on OK twice, and we should see the result of our search on the main screen along with our Host Access is Allowed column, as shown in the following screenshot:

Very handy!

Testing and validating the Samba 4 Active Directory schema extension

When we execute an Active Directory schema extension procedure, my experience in different environments (for example, lab setups for testing) is very similar for Samba 4 and Microsoft Windows servers running Active Directory. In case of failures, they can have different impacts on the services, as follows:

· AD DS doesn't even start

· Some misbehavior while running normal operations (for example, searching or replicating)

For the first case, some start/stop command executions after the AD DS schema extension, followed by server restarts is a good starting point to validate our system and make sure we do not have very bad issues with our Active Directory schema.

For the issues in the second category, we will see some commands that can be used to try to find any inconsistencies as soon as possible, so that they can be fixed and the schema extension can be rolled out onto production. Speaking specifically about the Samba 4 Active Directory implementation, the official page of the project at the time of this writing informed that it sometimes does not generate essential attributes, leading to problems in Samba 4 provisions [33]. There are some issues that can arise after some time when the new schema is running, and that is why extensions need to be extensively tested before being applied in production. All the procedures presented here are intended to be validated in a lab and test environment before the reader analyzes its suitability for production.

We will use the dcdiag utility [38] to execute specific tests one-by-one to look at some specific points of the Active Directory services and try to make a good assessment of the environment. We will focus on some specific tests, but feel free to validate as much as you feel is needed for your actual Active Directory deployment. The only attention point I would recommend is to make sure you understand that some limitations do exist when using this tool in a Samba 4 installation (for example, FRS or DFSR), and they are not implemented on this software at the time of this writing [39], so if not supported tests are performed, the results will be misleading.

Using one of the Member Servers of the domain (for example, Microsoft Windows Server 2008 R2), log on as the domain admin and execute the following command and press Enter:

C:\Users\Administrator.POA> dcdiag /s:addc /test:advertising /v

Now we should get a response like the following:

<OUTPUT SKIPPED some errors about FRS and DFSR <OUTPUT SKIPPED>

Doing initial required tests

Testing server: Default-First-Site-Name\ADDC

Starting test: Connectivity

................... ADDC passed test Connectivity

Doing primary tests

Testing server: Default-First-Site-Name\ADDC

Starting test: Advertising

The DC ADDC is advertising itself as a DC and having a DS.

The DC ADDC is advertising as an LDAP server

The DC ADDC is advertising as having a writeable directory

The DC ADDC is advertising as a Key Distribution Center

The DC ADDC is advertising as a time server

The DC ADDC is advertising as a GC.

................... ADDC passed test Advertising

<OUTPUT SKIPPED tests omitted by user request OUTPUT SKIPPED>

C:\Users\Administrator.POA> dcdiag

We use the /v option in our command to see all the tests that have performed. We have used this option so that we know how to look more deeply into each test and find specific issues on the global test commands. For now, we will omit this option and just look at the global test result. The following is the replication test code:

C:\Users\Administrator.POA> dcdiag /s:addc /test:replications

<OUTPUT SKIPPED some errors about FRS and DFSR <OUTPUT SKIPPED>

Doing initial required tests

Testing server: Default-First-Site-Name\ADDC

Starting test: Connectivity

................... ADDC passed test Connectivity

Doing primary tests

Testing server: Default-First-Site-Name\ADDC

Starting test: Replications

................... ADDC passed test Replications

…

C:\Users\Administrator.POA>

Tip

It's important to remember to create a lab environment based on a sane and fully working environment to make sure that every point of our configuration was working just fine before starting our procedure. So, when we perform the tests, we can be sure that if any error occurs after our tests, we can fix or roll back the changes. One tip is to execute all the tests described in this section before and after the AD DS schema extension to have a baseline.

As we discussed earlier, replication can be a problem, but we have seen that we did not have any. But replication can be a broader issue, and even if the result of this command is not OK, we need to look to see if it is a transient failure or actually a problem root on our Active Directory schema extension procedure. Another quick but valuable test is to check if the required logon privileges exist to permit proper replication, as shown in the following commands:

C:\Users\Administrator.POA> dcdiag /s:addc /test:netlogons

<OUTPUT SKIPPED some errors about FRS and DFSR <OUTPUT SKIPPED>

Doing initial required tests

Testing server: Default-First-Site-Name\ADDC

Starting test: Connectivity

................... ADDC passed test Connectivity

Doing primary tests

Testing server: Default-First-Site-Name\ADDC

Starting test: NetLogons

................... ADDC passed test NetLogons

…

C:\Users\Administrator.POA>

The test of KnowsOfRoleHolders is an essential one; sometimes we have a misbehaving AD DS and the problem is as basic as the lack of consistency on the Flexible Single Master Operations (FSMO) roles:

C:\Users\Administrator.POA> dcdiag /s:addc /test:knowsofroleholders

<OUTPUT SKIPPED some errors about FRS and DFSR <OUTPUT SKIPPED>

Doing initial required tests

Testing server: Default-First-Site-Name\ADDC

Starting test: Connectivity

................... ADDC passed test Connectivity

Doing primary tests

Testing server: Default-First-Site-Name\ADDC

Starting test: KnowsOfRoleHolders

................... ADDC passed test KnowsOfRoleHolders

C:\Users\Administrator.POA>

We can issue many tests at once, and the following is an example of how to do it:

C:\Users\Administrator.POA> dcdiag /s:addc /test:fsmocheck /test:ridmanager /test:machineaccount /test:kccevent /test:systemlog /test:topology /test:ncsecdesc

<OUTPUT SKIPPED some errors about FRS and DFSR <OUTPUT SKIPPED>

Doing initial required tests

Testing server: Default-First-Site-Name\ADDC

Starting test: Connectivity

................... ADDC passed test Connectivity

Doing primary tests

Testing server: Default-First-Site-Name\ADDC

Starting test: KccEvent

................... ADDC passed test KccEvent

Starting test: MachineAccount

................... ADDC passed test MachineAccount

Starting test: NCSecDesc

................... ADDC passed test NCSecDesc

Starting test: RidManager

................... ADDC passed test RidManager

Starting test: SystemLog

................... ADDC passed test SystemLog

Starting test: Topology

................... ADDC passed test Topology

Running enterprise tests on : poa.msdcbrz.eall.com.br

Starting test: FsmoCheck

................... poa.msdcbrz.eall.com.br passed test FsmoCheck

C:\Users\Administrator.POA>

The tests we executed until now are important general validation routines we need to have in the bag to evaluate the health of any Active Directory deployment. Any errors on these tests are the first indication that something went wrong, and we then need to review our configuration and evaluate our AD DS schema extension.

Before we started our AD DS schema extension, we have created a LDIF file with the content of our current schema configuration, and we have installed the components to use the AD DS/LDS Schema Analyzer tool. Now, we need a new LDIF file with the state of the AD DS with our changes already in place. Let's open a new command-line prompt window and execute the following script inside the directory where we have the other LDIF file:

C:\Users\Administrator.POA> cd Desktop

C:\Users\Administrator.POA\Desktop>ldifde –f new-adds-schema.ldif \

–d CN=Schema,CN=Configuration,DC=poa,DC=msdcbrz,DC=eall,DC=com,DC=br

Connecting to "adds.poa.msdcbrz.eall.com.br"

Logging in as current user using SSPI

Exporting directory to file new-adds-schema.ldif

Searching for entries…

Writing out entries .................................................

.....................................................................

.........................

1552 entries exported

The command has completed successfully

C:\Users\Administrator.POA\Desktop>

If we look closely at the preceding output, we can already see that we have a good starting point for our comparison. If we recall our first execution before the AD DS schema extension, we had 1550 entries, and now we have 1552 (we have added one class and one attribute to the schema).

That seems like a good sign, but as we will see next, it does not actually relate to attributes and classes, as we thought at first. In any case, let's not take anything for granted and not jump to any conclusions yet, as we have a proper tool to help us analyze and give us a better and proper view of the AD DS state.

Now we can execute the following by navigating to Start | Run:

We should get the default AD DS/LDS Schema Analyzer tool screen, with three top menu options. Just go to File | Load target schema… as shown in the following screenshot:

In the screen that will now appear (as shown in the following screenshot), we can click on the Load LDIF… button to load the LDIF file from before the AD DS schema extension:

Select the old-adds-schema.ldif file and press Enter. At the bottom of the AD DS/LDS Schema Analyzer tool, we will see some progress as the tool loads the entries, and at the end we will see a summary of the loaded schema as shown in the following screenshot:

Ok, now we need to load the base schema so we can use the tool for the comparison. We can do this in the following two ways:

· Connecting directly to the live AD DS

· Using the LDIF file we generated based on the AD DS schema after the extension

We will use the latter. Thus, we just need to click on the top menu and go to File | Load base schema…, and in the next screen click on the button Load LDIF… as we did for the target schema in the previous step.

Again, a summary of the new loaded schema will appear at the bottom of the tool. Now we can actually see that we have one more class and one more attribute on our Active Directory. After the load, the tool will automatically execute a comparison between the schemas, as we can see in the following screenshot:

Now, to be absolutely certain that all attributes and classes are present on the actual schema, we go to Schema | Hide present elements, as shown in the following screenshot:

After that, we will see that all the items in the upper panel on the AD DS/LDS Schema Analyzer tool are empty. This means that every element is present, as shown in the following screenshot:

This is one way we can use this handy tool to perform comparisons when we change the AD DS default schema. Now, if we exit the tool and start it again, we can actually perform a similar comparison, but this time loading the target schema as our new-adds-schema.ldif file and the base schema as the old-adds-schema.ldif file. So, if we click on the top menu and go to Schema | Hide present elements, we will see that our items will not be empty anymore, as shown in the following screenshot:

So we know that we have new elements on our new AD DS schema. Expanding all the items in that upper panel, we will have a hierarchy similar to the following screenshot:

Excellent! We can see exactly which new classes and attributes we have and the relationships between them. This is a very useful tool to analyze changes on the Active Directory schema, and it is a must-have application for system administrators who plan to execute an AD DS schema extension.

Summary

In this chapter, we learned the key consideration points when planning an Active Directory schema extension, how to prepare the tests and validations for the AD DS schema extension procedure, and learned how to export the current AD DS schema configuration.

We could also execute a practical AD DS schema extension procedure using a proper registered OID on top of a real application use case based on a PAM module implemented to solve a real use-case scenario.

At the end of the chapter, we learned how to execute general tests and validations of the health of Active Directory and learned a step-by-step procedure to perform a full comparison between the old AD DS schema and the new extended schema configuration to fully validate the whole process.

In the next chapter, we will learn how to implement a highly available distributed file server using the Samba 4 Server and some auxiliary software such as the GlusterFS distributed filesystem and the Cluster Trivial Database (CTDB).