Active Directory to the limit

The mention of Active Directory, Microsoft's tool for centralized authentication, most likely conjures thoughts of the nearly ubiquitous Windows log-in screen. But with the move to next-generation, Web-based architectures and the advent of advanced, integrated security infrastructures, agencies are extending Microsoft's directory service in ways they hadn't thought of before.

In the past, agency information technology departments usually extended AD to simplify user authentication when Windows and open systems were being used simultaneously. Maintaining separate log-ins for AD and other open-directory services had not proven cost-effective, so additional integration was required.

Now, Web architectures taking hold inside and outside the agency gates ' seemingly simple when viewed through the lens of a Web browser ' are requiring new levels of integration across AD and the myriad other directories and data sources that make up agency infrastructures. Portal technologies and Web-based single sign-on systems, in particular, are increasingly becoming the norm.

Agency security solutions also are moving beyond a simple Windows log-in. More federated, distributed identity-management solutions are becoming standard as more agencies routinely leverage multiple technologies and platforms. These dispersed products and services may include technologies ' such as biometric readers, bar code scanners, and photograph and fingerprint data ' housed across many directories and data sources.

Given both Web and security trends, extending AD is becoming mandatory. The good news is that agency IT administrators and executives have plenty of technical approaches to choose from when extending AD.

It might seem as though the easiest route to extending AD would be to simply expand the AD schema to include other data elements. Agency technologists could certainly do this, but it is not the recommended approach. Performance is the primary reason Microsoft and other directory service providers recommend a more distributed approach.

For example, suppose you expand your AD implementation to support a range of customer-service applications within the agency. The tightly integrated data elements would certainly be a boon for your customer service representatives. However, employees logging in from other departments would experience slower performance, given all the added customer service data elements.

A better approach would be an added solution from Microsoft or other provider that would externally segment the customer-service data elements but still support AD integration. The additional solution could be implemented in the directory services layer or the application layer itself.

Two such Microsoft solutions are Microsoft Identity Integration Server (MIIS) and Active Directory Application Mode (ADAM).

MIIS is an identity data management tool that centrally stores and integrates information from multiple sources. Its architecture uses connectors to receive identity information and stores the information in the connector space. MIIS supports connectors to e-mail systems, such as Lotus Notes; directory servers, such as IBM's Directory Server; enterprise resource planning systems, such as PeopleSoft; and database management systems, such as Oracle's.

School project

The Anoka-Hennepin School District in Minnesota uses MIIS to support a user population of 41,000 students and their families across 41 institutions. Patrick Plant, director of technology and information services at the school district, faced the challenge of integrating application data from state testing facilities, curriculum plans, student schedules and parent outreach sources.

MIIS 'integrates identity information from sources throughout our different systems with minimum system interface,' Plant said. The district uses MIIS to link information across all of its critical enterprise applications and directories.
Rather than centralizing information from multiple sources, ADAM is a lightweight version of Active Directory that agencies can use to power multiple, separate directory instances. The idea is to distribute but link identity- and application-specific information enterprisewide.

Children's Hospital in Boston implemented ADAM and MIIS to extend AD. User accounts are more easily managed across Unix and Windows platforms, and application-specific data elements have been segmented and linked through several ADAM instances. 'We have reduced the time previously required to manage users in the directory by 75 percent and redeployed administrative staff to more value-added activities,' said Scott Ogawa, chief technology officer at the hospital.

In a typical agency setting, users might authenticate using AD and then link to ADAM for additional identity and application-specific data elements. This infrastructure footprint boosts the performance of AD log-ins while also enabling enterprisewide single sign-on.

ADAM also is useful in other types of implementations. For example, developers might need a test bed with which to validate directory-related applications. Rather than modifying AD or maintaining a second AD infrastructure for testing purposes, an agency administrator might make ADAM available.

Software developers can install ADAM on a Windows-based desktop or within a virtual machine running Windows if they are running Unix or Linux as their primary operating system. Testing then could be executed with authentication and application data existing only in ADAM or, alternatively, AD might be used to authenticate with the application-specific data coming from ADAM.

One of the advantages of ADAM is the ability to run multiple instances. Using its multi-instance support, you might enable a number of agency developers and software testers to complete the development life cycle without adversely affecting day-to-day infrastructure operations.

Other providers are also making it easier for AD to participate in heterogeneous environments. As we move toward more pure play, Web-as-platform architectures, it becomes critical for agency infrastructures to be as tightly integrated as possible.

For example, IBM offers Tivoli Access Manager (TAM) in two forms ' one to enable single sign-on for Web infrastructures and the other for more traditional, legacy enterprise settings.

Active Directory manages authentication while additional TAM connectors integrate other sources of identity and application-specific data and power up presence-awareness. This level of integration provides a productivity payback when users can log in once in a Web browser and have immediate access to all their applications and e-mail and see which of their colleagues are online so they can collaborate in real time.

Drawing lines

Just as solutions such as ADAM and TAM can be used to provide a highly integrated user experience that extends AD, these same tools can be used to segment user populations. For example, your agency may want to implement an internal portal in addition to a separate, external portal for contractors.

You might consider creating a separate AD subdomain for external users with links to separate ADAM or TAM instances, connectors and services to deliver a single sign-on solution for external users. In this way, you could provide a rich user experience while maintaining security policies and ensuring maximum performance for your AD infrastructure.

Aside from extending AD for application integration or user population segmentation, you may want to expand AD's reach to enable a more federated approach to agency security. Distributed but federated security strategies may include leveraging AD with disparate sources of security data such as photographs, fingerprints, eye scans and bar codes.

One such solution is DigitalPersona Pro, which integrates with and extends AD by replacing the familiar Windows log-in with an interface where a fingerprint scan is requested before users can gain access. San Bernardino County, Calif., has implemented the DigitalPersona Pro solution. County IT executive Patrick Honny said, 'it's not intuitive to improve security with greater simplicity, but that's what we've done.'

The DigitalPersona Pro solution does not do away with AD or user passwords. Rather, when a user fingerprint is scanned, the software accesses a password vault to compare the input fingerprint with the one on file.

Once compared and verified, the AD password is processed and the user is logged on. 'Behind the fingerprint, we can put the most complex password we want to,' Honny said. In this way, security is increased and the user experience is simplified.

The National Institutes of Health chose to extend AD and its other directories to address another security concern that plagues nearly every IT organization ' the dreaded password reset. Using Avatier's Password Station, NIH set up a series of questions for each user, such as city of birth or favorite pet's name.

'We were never keen on password changes because of [all] the headaches,' said Tom Carrington, senior network engineer at NIH service provider Terrapin.

Password Station does not store user passwords or the answers to the security questions. Rather, passwords remain in AD. A one-way hash algorithm secures the answers to security questions so this information cannot easily be compromised. With typical help desks reporting a 50 percent to 75 percent reduction in calls after implementing self-service password resets, this extension to AD is highly worthwhile.

Whether your objective is to free help-desk employees to address more value-added tasks, increase security measures, provide a more highly integrated, feature rich single sign-on Web interface, or help developers more easily test directory-based applications, it is clear that agencies can and will benefit from expanding AD's role in the enterprise.

Maggie Biggs, a senior engineer and freelance writer, is based in northern California.