Chapter 3: Using Networking Directory Services


Enterprise applications expecting to be installed in top- tier corporations, such as Cisco Systems, IBM, and Hewlett-Packard, can expect integration with directory services to be a requirement. This chapter introduces directory services and how Active Directory manages information about networked objects. This chapter also demonstrates how you use .NET Framework objects to integrate an enterprise application with Active Directory. Finally, this chapter provides a close look at how to interact with directory services and expand the IssueTracker application to retrieve user information.

Exploring Directory Services

In a networked environment, applications should be able to store and retrieve information about users, other machines, other applications, and networked services. Applications should also be able to interact with users differently based on the role of the user. Finally, enterprise applications should be able to find networked resources, such as printers and files.

Directory services are central locations for storing information about networked objects. You can make this information available to users, administrators, and other networked applications based on security permissions. Directory services bundle access to network resources into a single network login and provide a single point of administration for network administrators. Administrators can create one user account in one place, allowing users to access different network resources. Directory services also serve as an organized naming service for looking up resources within the network. Enabling support for directory services within enterprise applications increases the sales potential for the enterprise application developer.

Furthermore, applications supporting directory services are often more aware of their deployment environment, and they are capable of adapting to changes and sharing information about themselves with other applications.

Enterprise applications can also take advantage of information already stored within directory services by other applications. Many corporate enterprises deploy an Enterprise Resource Planner (ERP) to manage human resources information. An ERP application stores a lot of business data, including employee names and organizational relationships. Such user attributes may be accessible to other enterprise applications capable of retrieving values from Active Directory.

Examining the Lightweight Directory Access Protocol Specification

The Lightweight Directory Access Protocol (LDAP) specification is the dominant directory service protocol based on the X.500 specification. It specifies how to organize attribute-based data into a hierarchical tree structure. It is also based upon the belief that directory service data is generally read from more than written to and is therefore designed for fast data retrieval at the cost of slow data storage. There is no specification for transactional processing or rollback handling. It simply defines a central repository for hierarchically storing data and a structured syntax for searching and retrieving entries.

Understanding the Directory Information Tree

The hierarchical representation of data in LDAP is a Directory Information Tree (DIT). It specifies the packaging of information in the form of objects that represent networked resources such as individual users, groups, and computers. These objects comprise customizable attributes that describe an object, such as a first name, last name , or password. Objects can be grouped into containers that represent collections of related objects just as a file server groups related files into subdirectories. Figure 3-1 illustrates the hierarchical relationships between networked objects in a DIT.

click to expand
Figure 3-1: A sample DIT describing networked objects

A namespace, or path , is a named reference to a specific object in the hierarchy. The path refers to an object's location relative to the top of the tree. It is used to traverse, search, and modify the object tree as well as read and write an object's properties. All tree nodes also have a Globally Unique Identifier (GUID) that uniquely identifies each node in the hierarchy throughout the domain. A node's GUID remains constant, even if a node moves from one location to another.

Understanding the LDAP Schema

A schema is an object map that describes all objects, object classes, and their attributes. This object map makes up the directory service repository and defines the rules for describing how data must be stored. The schema helps to maintain the consistency and quality of the data while minimizing data duplication. Schema rules are defined by object class attributes, and they specify how the rules must be applied. A complete schema contains required attributes, custom attributes, rules for comparing attributes, and limits on what the attributes can store. It is always important to fully understand the underlying schema of a directory service before planning an integration project.

Understanding the LDAP Search Filter

Search filters specify what data should be returned from a directory service to the calling client. You create search filters using logical expressions that combine attributes, operators, and criteria values. Attributes and values combine with operators to complete the syntax for a search filter. Any number of expressions can join together to narrow down a search to a single object:

 (&(objectClass=User)(cn="Bill Bruchs")) 

The most significant part of any directory service integration is identifying a search filter that returns the desired information with the least performance impact. Often, a number of different search filters need to be written and performance tested to find the one that provides the best results. The LDAP specification is flexible and is a time- tested standard for many directory service solutions. Microsoft's Active Directory solution also implements the LDAP specification, bringing the power and flexibility of directory services to Windows users and .NET applications.

Examining Active Directory

Active Directory is a directory service solution deployed with Microsoft .NET Server and Windows 2000 Server. It provides a secure repository of information relating to networked objects within the enterprise, including users, computers, and services. Active Directory provides access to multiple resources through a single login and provides network administrators with an intuitive view of the entire network.

In addition to being secure, Active Directory is also distributed and replicated to ensure data integrity and reliability. Furthermore, it is scalable to support any size of deployment ”from a single server with hundreds of objects to hundreds of servers with thousands of objects. Although Active Directory is deployed with .NET Server and Windows 2000, client-side platforms can include Windows NT 4.0, Windows 9 x , Windows XP, and Unix. Depending upon permissions, clients can have full access to networked resources within the domain. Figure 3-2 shows the Active Directory manager on the Windows Server 2003.

click to expand
Figure 3-2: Active Directory manager in .NET Server

Understanding Active Directory Services

Active Directory offers three primary functions: network administration, search, and developer support. The administrative functions of Active Directory enable a network administrator to manage multiple user accounts, groups, and access permissions from a single application. You can enable or disable access to different applications, files, and printers without requiring client-side configuration. As a result, the directory service becomes the hub around which a large enterprise grows.

The search functions of Active Directory enable administrators, users, and applications to track down networked resources when they do not know the exact name or path of the objects in which they are interested. If you know one or more object attributes, you can search the directory service to return a list of possible matches.

The developer functions of Active Directory are exposed through the Active Directory Services Interfaces (ADSI), a set of open interfaces that abstract the directory services. Applications can use ADSI to manage resources in a directory service, regardless of which network environment manages the resource. ADSI addresses the issue of enabling a single login for desktop clients and interacts with multiple directory service providers for searching. ADSI enables applications to interact with different directory service implementations through a single interface layer. You can create applications to perform common tasks , such as backing up databases, accessing printers, and administering user accounts. Figure 3-3 illustrates how a .NET enterprise application integrates with the underlying directory service platforms.

click to expand
Figure 3-3: Directory service layers

Because Active Directory implements the LDAP specification, it is also capable of performing integrated searches against other directory service servers that also implement the LDAP 2 specification. These additional servers include the following:

  • Microsoft Windows Server 2003 Active Directory

  • Microsoft Windows 2000 Server Active Directory

  • Netscape Directory Server 1.0

  • Microsoft Exchange Server 5.0

  • Novell LDAP-enabled NetWare Directory Service (NDS)

Understanding Active Directory Object Attributes

The Active Directory object schema is flexible and can change to accommodate application-specific needs. As Figure 3-1 illustrated , the directory service tree comprises multiple objects. Each object has multiple attributes that are either required or optional. The object definitions are maintained by object class definitions within the directory schema. The schema already defines objects, such as User, with multiple properties, such as first name, last name, and e-mail address. If an additional attribute is necessary, the schema will need to be changed.

Changes to the Active Directory schema are irreversible and must be carefully planned. In Windows Server 2003, you can modify the schema definition with the Active Directory Schema Editor snap-in component for the Microsoft Management Console (MMC). For security reasons, the Active Directory Schema Editor is not initially installed. To activate it, select Start ˜ Run and enter regsvr32.exe schmmgmt.dll . Next, start the MMC by selecting Start ˜ Run and enter mmc /a . From the empty MMC view, select Console ˜ Add/Remove Snapin to display the snap-in manager. Next, click the Add button and select the Active Directory Schema snap-in, as shown in Figure 3-4.


Figure 3-4: Adding the Active Directory Schema snap-in for the MMC

Now the MMC is capable of displaying the Active Directory object schema and accepting changes to objects and attributes. You will use the Active Directory Schema Editor later to add a custom attribute to the default user definition.




Developing. NET Enterprise Applications
Developing .NET Enterprise Applications
ISBN: 1590590465
EAN: 2147483647
Year: 2005
Pages: 119

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net