17.3 Integrating Applications and Services

Many applications rely on a directory to access user information and store application data. Since Active Directory was Microsoft's first true directory offering, many application vendors attempted to integrate their products into it, only to find there were a lot of issues from both technology and political perspectives. We'll now discuss some of these challenges.

17.3.1 The Application Integration Challenge

While trying to use Active Directory as both a NOS and application directory can initially reap significant rewards from reduced total cost of ownership, it also presents several challenges as well. In fact, many of the features that make Active Directory a great NOS directory (a repository of user, group, and computer accounts) also make integrating applications much more difficult.

17.3.1.1 Challenges for application vendors

Many of the challenges for application vendors are related more to incompatibilities with integrating with the NOS than directly to insufficiencies with Active Directory. In fact, Active Directory could be used as a pure application directory with few differences from what you would see using a SunONE or OpenLDAP directory server. But that is not how Active Directory is typically being used in the enterprise. In fact, most organizations are still trying to balance the effects of maintaining a stable NOS environment that has consistent reliability and response times with an application directory that could impact the end-user experience with increased server load and directory bloat.

We have seen numerous vendors struggle with trying to integrate products with Active Directory, especially on their first attempt. Most companies do not have a lot of Active Directory or even LDAP expertise, so they make do with what they have, which often results in poorly integrated applications. In fact, it is not sufficient for vendors to have just LDAP expertise, because Active Directory has many features, such as the Global Catalog, never seen in any other directory server product. Often vendors gain the expertise they need only after they have struggled through the painful experiences of several customers that have deployed their product. Some of the major issues application vendors face are described in the following list.

Hierarchical structure

One of the biggest roadblocks for applications using Active Directory is accessing data in a multidomain model. Most medium- to largescale Active Directory implementations use multiple domains to segregate data, regulate administrative access, limit exposure during disaster recovery situations, and reduce the amount of data that replicates between domain controllers. Typically, the domains are spread across geographic and sometimes organizational boundaries. Figure 17-1 illustrates an example of a simple geographic domain structure that is commonly used.

Figure 17-1. Typical geographic domain model

Before Active Directory, most directory-enabled applications could rely on a flat namespace. A single query could search against all objects in the directory. In a multidomain model, it is not that easy. To help combat this problem, Microsoft introduced the Global Catalog. In a lot of situations, the data available in the Global Catalog may be sufficient for applications, but often it is not. If more data is needed for an object than what is provided by the Global Catalog, a second search must be done against a domain controller that is authoritative for the domain the object is in. This can result in many more queries than are needed when searching a flat namespace.

Multimaster replication

A common problem faced by nearly all distributed applications using Active Directory is how to handle multimaster replication. Active Directory is loosely consistent, which means that at no point can you assume that all updates have replicated to all domain controllers. As a rule of thumb, the best thing a directory-enabled application can do is to not assume that updates made to the directory are immediately available unless the same server being queried was used for the updates. In some environments it can take several hours or even days for updates to replicate to all domain controllers.

Schema extensions

Applications that want to publish data in Active Directory generally need to make schema extensions. The base schema provided by Active Directory contains a lot of classes and attributes, but for anything other than the most trivial application, customized extensions will need to be developed. Updating the Active Directory schema is a very sensitive operation, and Microsoft has done a good job of communicating the need to have a strict schema update policy. In some cases, we've even heard of administrators refusing to extend the schema because of fear of directory corruption. While it is a good idea to be cautious, extending the schema is a very necessary task. On the other hand, application vendors will not be able to get away with very frequent updates of their extensions. Thus, any schema extensions must be thought out extremely well beforehand and should be flexible so that only minor changes might be required in the future. Anyone familiar with writing largescale applications understands how difficult this can be.

inetOrgPerson support

When Active Directory was first released, many people complained that the inetOrgPerson objectclass was not supported for user objects. Microsoft instead decided to use their own user objectclass to represent user objects. inetOrgPerson is the closest thing to a standard representation of what a user object should look like in an LDAP directory. It was defined in RFC 2798 and is supported by other LDAP directories, including SunOne and OpenLDAP. While Microsoft's user objectclass has many of the same attributes as inetOrgPerson, there are numerous differences.

To work with Active Directory, a lot of preexisting directory-enabled applications that were programmed to use inetOrgPerson had to be rewritten to support Microsoft's user objectclass as well. Microsoft came out with an add-on for Windows 2000 to support inetOrgPerson, and it is natively supported in Windows 2003 Active Directory. Unfortunately, many applications have already had to be reworked to use Microsoft's user class, and it is unlikely that most administrators will want to switch to inetOrgPerson.

Service location

Typically, directory-enabled applications are developed to work against multiple directories, such as Active Directory, OpenLDAP, iPlanet, Novell, etc. For these types of applications, there is generally a configuration process to hardcode the directory server(s) to query. In an Active Directory environment that may be distributed to several locations globally, the application should use the closest server possible. It is possible to use Microsoft APIs to locate domain controllers dynamically, but this may not be acceptable if you are trying to write directory-neutral applications.

17.3.1.2 Challenges for Active Directory administrators

While application vendors have many challenges in writing well-behaved Active Directory-enabled products, administrators have a different set of challenges facing them. Most of the issues administrators face can be addressed by developing well-defined and documented processes for how applications will be used in Active Directory. Many of the problems become increasingly difficult as the number of applications being supported grows. Some of the major issues administrators face are described in the following list:

Application engagement and testing

All enterprise Active Directory environments should use a development or test forest for testing applications before moving them into production. As stated earlier, many of the Active Directory-enabled products on the market have serious flaws with how they are integrated with Active Directory. It is extremely important to put an application through its paces in a development forest not only to identify issues that may cause problems in your production environment, but also to understand how the application uses Active Directory.

The other important aspect of testing is having a well-defined application engagement process. Groups that want to integrate their applications with Active Directory need a starting place for engaging your Active Directory team. However you choose for users to start the engagement process, you should document information about each application, including name, contacts, description, directory usage, etc. It is also beneficial to publish guidelines for how to request application account(s), perform load testing, and request consulting services if needed.

If not already apparent, having an application engagement process requires significant resources to support. Someone has to interact with the application groups and support them as they move their application from the test forest to production. The support burden is even more significant for applications that write data to Active Directory since the schema will need to be extended. Those types of applications typically are more complex and thus require a greater understanding of the interaction with Active Directory.

Application accounts

Most Active Directory implementations will not have anonymous access enabled. It is generally not a good idea to allow anonymous access, especially when Active Directory is assuming both the NOS and application directory roles. That means applications need to bind or authenticate to access directory data. Each application needs to have a user account in which to bind. Using a separate account perapplication is typically a good idea because it is much easier to track down problems if only a single application is using an account. Some of these problems may include account lockout because of failed bind attempts or directory spamming due to unoptimized or buggy LDAP queries.

Another issue that must be stressed regarding application accounts is password expiration. Requiring passwords to be changed on a periodic basis is a good practice for user accounts, but it can be difficult to implement for application accounts. This is a significant issue when dealing with accounts that run as a service, which are constantly logged on. It can be extremely difficult to ensure that each logged-on instance of the account is using the correct password when the password has been changed.

One possible workaround to this problem is to use dual accounts. Instead of using one account per application, you could use two. When a password needs to be rotated, instead of changing the account password and making sure all instances of the application are using the new password, you instead change the application to use a different account. At that point, the original account's password can be changed and used during the next iteration. As long as the second account has all the same privileges as the first, using dual accounts can be much easier to implement and lacks the synchronization problem with changing passwords of a single account.

Directory bloat

Any application that needs the schema extended will be storing data in Active Directory. Over time, as more and more applications store data in Active Directory, the AD DIT (Directory Information Tree) file will grow. Although Active Directory is orders of magnitude more scalable than Windows NT when it comes to the amount of data that can be stored, it is crucial to put processes in place to clean out unused data from existing and decommissioned applications. If provisions are not put in place to do this, you may run into issues with storage on your domain controllers or even performance degradation in queries to the directory.

Application conflicts

As you support more applications in Active Directory, the chance for applications to conflict with one another increases. In some cases, applications have had conflicting schema extensions, which could result in serious incompatibilities. It could also be a problem if a particular application is not well behaved and overloads a domain controller, effectively causing a denial of service for other applications that are trying to use it as well.

17.3.1.3 AD/AM to the rescue

Fortunately, there is a solution to most of these issues. AD/AM allows you to segregate your NOS and application directory needs across different servers. We'll quickly review each of the challenges discussed previously to see whether AD/AM will help:

Hierarchal structure

AD/AM does not have the concept of a domain, so this isn't inherently a problem. You can set up a hierarchal structure across several AD/AM servers, but it is not required.

Multimaster replication

AD/AM supports multimaster replication, so this will continue to be an issue that application vendors will need to be cognizant of.

Schema extensions

Since AD/AM has its own schema, you can make extensions without impacting Active Directory.

inetOrgPerson support

AD/AM fully supports the inetOrgPerson class.

Service location

This continues to be an issue, and, due to the fact that AD/AM doesn't support SRV records, administrators will have to use other means for distributing load across servers.

Application engagement and testing

If you are using AD/AM, you do not have to be as concerned about the impact it will have on Active Directory, and you will not require testing to be as strenuous.

Application accounts

If you have a business need to allow anonymous access to your directory, you can set that up with AD/AM and have much less risk than you would with Active Directory.

Directory bloat

By using AD/AM, you can reduce the amount of data stored in Active Directory and the eventual bloat that results.

Application conflicts

With AD/AM, application conflicts occur only if you are allowing multiple applications to use the same instance. While an errant application can affect the availability of an AD/AM instance, it will not necessarily hurt your NOS performance.

While AD/AM may not solve all the problems, it does provide a lot more flexibility and options for setting up a Microsoft-based directory environment.

17.3.2 Integrating Unix

Most people consider integrating a directory service with applications that need to query employee or customer data to be a no-brainer, but what about your Unix infrastructure? The term "single sign-on" has been buzzing around the industry for many years, but few have to come to realize it. Most have not been able to achieve even reduced sign-on. If reduced sign-on is your goal, and your Active Directory contains a username and password for everyone in your organization, it makes sense to collapse as many authentication repositories as possible. This may include attempting to eliminate the authentication services provided by your Unix infrastructure, such as NIS. There are several aspects of integrating Unix with Active Directory, and we'll review them now.

17.3.2.1 Kerberos and LDAP support

Long before Active Directory supported Kerberos, it was a mainstay in the Unix environment. While many were initially perturbed by Microsoft's extension of Kerberos, primarily because of the lack of documentation, you can use a standard MIT Kerberos client to get a ticket from an Active Directory KDC.

Another benefit of Active Directory supporting standards such as LDAP is that you can use the traditional LDAP tools, such as ldapsearch, to query and update Active Directory from a Unix platform. You can also use LDIF for query and update purposes along with any LDAPv3-compliant API, such as the C-style API or Java Naming and Directory Interface (JNDI).

17.3.2.2 Migrating from NIS

You have a couple of options for migrating away from Sun's Network Information System (NIS). First, there are two NIS gateways available that can act as NIS servers that backend to Active Directory. Microsoft Services For Unix 3.0 includes a NIS Server that can do just that and runs on a Windows server. PADL Software (http://www.padl.com) also has a NIS/LDAP gateway that can work with different directories, including Active Directory. The PADL gateway can run on a variety of Unix platforms.

Another option is to switch your Unix-based clients to support LDAP natively instead of continuing to use NIS. Luckily, most of the major Unix and Linux vendors provide support for LDAP, although each varies slightly. For more information on how to make Unix clients work with LDAP, check out LDAP System Administration by Gerald Carter (O'Reilly).

17.3.2.3 Integrating with NFS

With the NFS Server provided in Services for Unix 3.0, you can have a Windows server act as an NFS server. This means you can consolidate file servers in your environment by allowing both Unix and PC-based clients to use the same file server.

17.3.2.4 Synchronizing passwords

Microsoft's Services For Unix 3.0 provides password synchronization that allows you to sync passwords from Unix to Active Directory and viceversa. This means that if all you to do is ensure that your Unix users are using the same password as that in Active Directory, you can sync from AD to your Unix hosts. And if you use a Unix-based LDAP directory, such as SunONE, you can use Microsoft Metadirectory (MMS) to synchronize accounts and passwords.

Admittedly, we just barely touched on the subject of integrating Unix. It is a very broad topic and would take several chapters to adequately cover everything. Again, we highly recommend the LDAP System Administration book for more information on the topic.