Tài liệu Module 6: Integrating with Active Directory doc

Contents Overview 1 Using ADSI to Access Active Directory 19 Using ADO to Query Active Directory Data 35 Review 49 Module 6: Integrating with Active Directory... Overview of Director

Contents

Overview 1

Using ADSI to Access Active Directory 19

Using ADO to Query Active Directory Data 35

Review 49

Module 6: Integrating with Active Directory

products, people, characters, and/or data mentioned herein are fictitious and are in no way intended

to represent any real individual, company, product, or event, unless otherwise noted Complying with all applicable copyright laws is the responsibility of the user No part of this document may

be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Microsoft Corporation If, however, your only means of access is electronic, permission to print one copy is hereby granted

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property

 2000 Microsoft Corporation All rights reserved

Microsoft, BackOffice, MS-DOS, Windows, Windows NT, Active Directory, ActiveX, Microsoft SQL Server, MSDN, PowerPoint, Visual Basic, Visual C++, Visual InterDev, and Visual J++ are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A and/or other countries

The names of companies, products, people, characters, and/or data mentioned herein are fictitious and are in no way intended to represent any real individual, company, product, or event, unless otherwise noted

Other product and company names mentioned herein may be the trademarks of their respective owners

Instructor Notes

This module provides students with an overview of Microsoft® Active Directory®, including its features, benefits, terminology, and concepts Students will learn how to integrate Active Directory with their applications They will also learn how to retrieve data and properties from Active Directory by using ADSI and ActiveX® Data Objects (ADO)

After completing this module, students will be able to:

! Describe directory services

! Describe the benefits of integrating with Active Directory

! Describe the Active Directory programming model

! Access Active Directory data by using ADSI

! Query for Active Directory objects by using ADO

In the first practice, students will learn how to browse Active Directory data by using the ADSIEDIT tool This tool can be used to view, change, and delete the attributes of any object in Active Directory In the next two practices, students will learn how to access Active Directory data by using ADSI and ADO In the first lab, students will use ADSI to retrieve data from Active Directory In the second lab, they will use ADO in conjunction with the OLE DB provider, ADsDSObject, to query Active Directory

Materials and Preparation

This section provides you with the required materials and preparation tasks that are needed to teach this module

Required Materials

To teach this module, you need the following materials:

! Microsoft PowerPoint® file 1907A_06.ppt

! Module 6: Integrating with Active Directory

! Lab 6.1: Using ADSI

! Lab 6.2: Using ADO

Preparation Tasks

To prepare for this module, you should:

! Read all of the materials for this module

! Complete the practice and the lab

! Read the instructor notes and the margin notes for the module

Presentation:

90 Minutes

Lab:

60 Minutes

Module Strategy

Use the following strategy to present this module:

! Overview of Directory Services Describe the features available in the Active Directory service and explain the benefits that these features bring to solution developers

Explain the key concepts required to understand Active Directory from a developer’s perspective Describe what types of data are suitable for Active Directory and the benefits of storing application data in Active Directory Discuss the Lightweight Directory Access Protocol (LDAP) syntax for accessing directory data

! Using ADSI to Access Active Directory Explain that ADSI provides a set of functions and interfaces that developers can use to access and manipulate data in a directory service Describe how

to use the Active Directory Services Interfaces (ADSI) to access Active Directory data

! Using ADO to Query Active Directory Explain that because Active Directory is basically a store of information, an OLE DB provider is supplied for it As a result, either ADO or OLE DB can

be used to query the contents of the directory service For developers already familiar with ADO, it provides a simple and powerful way to query Active Directory data Explain how to use ADO to query Active Directory for data

! Best Practices Summarize the best practices that should be followed when integrating distributed solutions with Active Directory

# Overview

! Overview of Directory Services

! Using ADSI to Access Active Directory

! Lab 6.1: Using ADSI

! Using ADO to Query Active Directory Data

! Lab 6.2: Using ADO

! Best Practices

! Review

Developers may face many challenges in building distributed applications When an application spans multiple computers, issues such as security, configuration, data access, and service discovery all become more complex In such an environment, a directory service acts as a central repository of

information about the network of servers and resources and the organization they serve

To work seamlessly and robustly in a distributed environment, an application must take advantage of a directory service as a common store of application data A directory service allows people and resources to move as appropriate, instead of being fixed to one location In Microsoft Windows 2000, Active Directory provides such a service Distributed applications written for Windows

2000 should take full advantage of the features of Active Directory

In this module, you will learn about the benefits of integrating distributed applications with Active Directory You will learn the structure of Active Directory and the syntax for accessing objects within it You will also learn how to access Active Directory data by using both Active Directory Service Interfaces (ADSI) and Microsoft ActiveX Data Objects (ADO)

Objectives

After completing this module, you will be able to:

! Describe directory services

! Describe the benefits of integrating with Active Directory

! Access Active Directory data by using ADSI

! Query for Active Directory objects by using ADO

In this module, you will learn

how to integrate distributed

applications with Active

Directory

# Overview of Directory Services

! What is a Directory Service?

! What is Active Directory?

! Active Directory Concepts

! Benefits of Integrating with Active Directory

! Active Directory Data

! Practice: Browsing Active Directory

This section introduces you to Active Directory It describes the features available in the Active Directory service and explains the benefits that these features bring to solution developers

In this section, you will learn the key concepts required to understand Active Directory from a developer’s perspective You will learn what types of data are suitable for Active Directory and the benefits of storing your application’s data

in Active Directory You will also learn the Lightweight Directory Access Protocol (LDAP) syntax for accessing directory data

This section includes the following topics:

! What Is a Directory Service?

! What Is Active Directory?

! Active Directory Concepts

! Benefits of Integrating with Active Directory

! Active Directory Data

! Practice: Browsing Active Directory

What Is a Directory Service?

! Repository of information about objects in the enterprise

A directory service comprises both a repository of information and the software component that makes the information available and useable globally Directory services are most commonly used for storing and retrieving information about people and companies, just as you might use the white or yellow pages in a telephone directory

Rich directory services, such as Active Directory, provide a scalable, secure, extensible, and consistent management infrastructure and are ideal for storing many types of information Such information could range from application-specific information, such as the quality of service for a router, to an expense report approver for each employee in an organization Applications that integrate with a rich directory service such as Active Directory will be more robust and manageable than those that do not

How Data Is Represented in a Directory Service

In a directory service, each piece of information is represented by an object that

is defined by its attributes By using the value of an attribute — a name, for example — you can find a particular object in the directory service After the object is found, it is possible to find additional attributes of that object This process is similar to the way in which you can use a telephone directory to find

a telephone number or address by searching for a person's name

There are many interesting objects in a networked computer system, including printers, servers, routers, applications, databases, and actual human users Users need to determine the objects that they want to use, such as applications, printers, and servers Administrators need to manage and monitor access to these resources and control the rights granted to users

For a distributed computer system, a directory service is essential to simplifying both the use and management of the system A directory service allows users to query for objects by using their attributes You may query for a printer, for

example, by using the attributes can print double-sided and can be found on the Sixth Floor of Building 41 The directory service can then return the name

of the printer, its exact location, and its network address so that you can connect

to it and print

What Is Active Directory?

! Distributed Database of objects in a Windows 2000 domain-based enterprise

Active Directory is the extensible and scalable directory service for Windows

2000 It stores information about objects in the enterprise and makes this information easy for administrators and users to find and use

Windows 2000 enterprises are comprised of domains A domain contains related user accounts, computers, and other objects This information is stored

on one or more Windows 2000 servers configured as a domain controller Windows 2000 domains are named by using Domain Name System (DNS) names such as microsoft.com A large domain can be divided into subdomains For example, the microsoft.com domain could have a subdomain named sales The DNS name for the sales subdomain would be sales.microsoft.com This hierarchical arrangement is called a domain tree and is shown in the above illustration

In extremely large enterprises, domain trees can be related to one another to form a domain forest Administrators can configure "trust relationships"

between domains in the forest to allow resources to be accessed from anywhere

in the enterprise The following illustration shows a domain forest containing domain trees that are related by trust relationships

Active Directory is the directory service used to store and locate information about objects in a Windows 2000 enterprise It is scalable from single domain networks to extremely large domain forests Active Directory uses a structured data store as the basis for a logical, hierarchical organization of directory information This information is replicated between domain controllers to provide an enterprise-wide, distributed directory

Security is integrated with Active Directory through logon authentication and access control to objects in the directory With a single network log on, Active Directory administrators can manage and organize directory data throughout their network, and authorized network users can access resources anywhere on the network Policy-based administration simplifies the management of even the most complex network

Many Microsoft applications, such as Microsoft Exchange Server 2000, will integrate with Active Directory by storing configuration and policy information

in Active Directory objects or by using the security data available in Active Directory As a result, Active Directory is well positioned to provide a platform for enterprise applications

Active Directory Concepts

LDAP://CN=Juan,OU=PO System Users,DC=contentm,DC=com

To use Active Directory correctly, it is important to have a broad understanding

of how it works This section describes the key aspects of Active Directory that concern developers

Containers and Objects

Active Directory stores information about objects in the enterprise To be useful, this information must be structured Under Active Directory, this structure takes the form of a hierarchy of containers and objects An Active Directory hierarchy can be compared to a file system Just as a file system consists of a hierarchy of files and folders, an Active Directory hierarchy consists of objects and containers Endpoints on the hierarchy are usually objects Nodes or branches are containers

You can write code to traverse containers and access objects in an Active Directory hierarchy in the same way that you can write code that traverses folders and accesses files in a file system To access data in Active Directory, you must know something about the object with which you want to interact, typically the name of the object, and have some idea of where it is stored in the hierarchy

Names and Namespaces

Active Directory provides namespaces through which you can access directory objects Again, this arrangement can be compared to the naming scheme in a file system The full name of a file in a file system consists of:

! The name of the logical drive on which the files resides (for example, C:)

! The path to the file from the root of the logical drive on which the files resides (for example, \temp) The name of the file (for example, myfile.txt)

In a similar way, to access an object in an Active Directory tree, you will need

to specify:

! The ADSI provider that can provide access to the required directory

! The path to the object from the root of the hierarchy in which the object resides

! The common name (CN) attribute of the object

Lightweight Directory Access Protocol Names

The protocol most commonly used to access objects in Active Directory is the Lightweight Directory Access Protocol (LDAP) LDAP is a standard protocol for accessing directory services To use the LDAP provider, prefix the path to the object with the "LDAP" string Using this prefix indicates that the name that follows conforms to the rules defined for the LDAP namespace Different namespaces will have different rules about what is (and is not) a valid name The path to the object is conceptually similar to the path to a file in a file system However, the way that the different levels of hierarchy are specified may differ In a file system, a path is specified as a list of directory names separated by backslashes (for example, C:\Documents\notes.doc) with the hierarchical location described from the root (C:) to the file (notes.doc) With LDAP, a path is specified as a series of comma-separated tokens and the hierarchy is described in reverse from the object to the root Each token consists

of a name-value pair with the name indicating the type of object or container and the value indicating the name of that container The following example illustrates an LDAP name:

LDAP://CN=Juan,OU=PO System Users,DC=contentm,DC=com

This LDAP name identifies the object representing the user Juan in the PO System Users organizational unit of the domain contentm.com The following illustration represents this hierarchy graphically

Common Attributes in LDAP Names

Because the LDAP protocol is a standard for directory service access, most of the names you will encounter in directory-enabled applications will use LDAP syntax The syntax of an LDAP name (sometimes called an attributed name) contains similar path information to that of a file name This information allows the identification of an object in a directory service An LDAP name that uniquely identifies an object in a directory service is referred to as a distinguished name (DN) A DN consists of a list of name/value tokens separated by commas Some common attributes found in LDAP names are described in the following table

Attribute Meaning

OU Organizational Unit This attribute is used to logically divide a

namespace based on organizational structure rather than by physical location An OU usually corresponds to an Active Directory container/folder For example, a corporate domain could be logically divided by using OUs for each department in the company

CN Common Name This attribute denotes the object itself within the

directory service You can think of it as a "leaf node" in the directory

DC Domain Component Domain components are analogous to the

dot-separated parts of an Internet domain name A DN that uses DC attributes will have one DC for every domain level below the naming root The DNS name microsoft.com, for example, would become the LDAP name DC=MSFT, DC=COM

O Organization This attribute identifies a specific organization such as

For more information about LDAP naming syntax, see the Internet Standard RFC 1779

Schemas

The schema of an Active Directory defines the types of object that can be stored

in it This schema is analogous in some ways to the schema of a table in a database and in other ways to the definition of classes in object-oriented programming The Active Directory schema defines:

! The attributes that each different type of object possesses

! A list of the possible types of attributes

! The types of objects that each different type of container can contain

When Active Directory is installed, it comes complete with a varied set of object and container types These types are sufficient for many purposes Although it is possible to extend the schema and add your own types, this task

is nontrivial and is currently irreversible For this reason, you should consider whether customization of the schema is necessary, and if so, it should be planned carefully

For more information about schemas, see "Extending the Schema" under Active Directory in the Windows 2000 Platform SDK

Note

Benefits of Integrating with Active Directory

! Multimaster Replication

! Integrated Granular Access Control

! Efficient Query Across Partitions

! Extensible Schema

! Serverless Binding

! Microsoft Management Console (MMC)

The following table describes some of the features of Active Directory and the benefits that those features provide

Feature Benefits

Multimaster replication Enables both distributed and centralized management of

information stored in the directory, depending on the needs of the organization Multimaster replication coordinates changes between domain controllers made anywhere in the enterprise

Local replicas can increase the speed of searching the directory

Ensures that the failure of a single directory server does not disable the querying facility of the entire network Integrated granular access

control

Enables administrators to control who has what rights on

a piece of information in Active Directory

Keeps directory information safe from unauthorized users These users may be maliciously trying to break into the network or simply attempting to alter attributes

of resources that they mistakenly believe they control, such as a printer or application Access can be restricted

to the attribute level

Enables delegating the administration of information stored in Active Directory

Efficient query across the enterprise

Enables locating information regardless of the enterprise

in which it is located As a result, a user in one part of a domain forest can access objects in all other parts of the forest

Enables locating resources by function without prior knowledge of their location in the directory

Feature Benefits

Extensible schema Enables developers to modify and extend the schema

Enables storage of application-specific information in Active Directory

Serverless binding Enables applications to bind to the closest domain

controller without prior knowledge of its name

Provides built-in resilience so that the server used by an application can be transparently altered with no extra work required by the application

Microsoft Management Console (MMC)

Enables applications to be managed through a consistent user interface

Active Directory Data

! Active Directory Object Attributes

$ A unique name

$ The data type for the value of the attribute

$ Range limits for those values (optional)

$ An indication of whether attributes may have more than one value

$ An indication of whether the attribute is indexed

! Data that Does Not Belong in Active Directory

$ Data that is only required locally

$ Data that changes often

$ Data that is very large

Every data entry in Active Directory represents a concrete object and may be described by one or more attributes In this section, you will learn how attributes are used to define Active Directory objects and what types of data are suited for Active Directory

Active Directory Object Attributes

An Active Directory object is based on an Active Directory class defined in the schema Each class is comprised of a set of attributes Multiple classes may use

the same attribute after it has been defined For example, both the User class and the Group class use the mail attribute

The Active Directory schema defines attributes only once The definition includes the following:

! A unique name

! The data type for the value of the attribute

! Range limits for those values (optional)

! An indication of whether attributes may have more than one value

! An indication of whether the attribute is indexed

Multivalued attributes are unordered, meaning that the order of the multiple values cannot be specified There is no guarantee about the order in which they are returned when requested or the order in which they are stored within the directory When an attribute value is updated, the entire attribute is

resynchronized among all of the replicas, not just the value that was changed Attributes may have constraints, such as length or range limits For numeric values, you may specify an upper and lower value limit For string values, you may specify a minimum and maximum string length If one constraint is specified while the other is not, the missing constraint is said to be unbounded, meaning that there is no limit on the value

To improve query performance against an attribute, it may be indexed To optimize index creation, attribute properties should be single valued with unique values that are evenly distributed across the set of instances The poorer the uniqueness, the less efficient the index

Multivalued properties can also be indexed, and like single-valued properties, the uniqueness and value distribution of multivalued properties influences their efficiency Indexing multivalued properties, however, is more expensive than indexing single-valued properties The more indexed attributes a class possesses, the longer it takes to create new objects of that class

Data that Does Not Belong in Active Directory

Active Directory is a distributed, replicated data store Even though the Active Directory schema is fully extensible, not all types of data should be stored in Active Directory

! Data that is only required locally There is no reason to store data in Active Directory that is only required on

a specific server For example, you would not store the names of personal files in Active Directory

! Data that changes often Because Active Directory is replicated, it is important not to store data that changes frequently Data that consistently changes (for example, more often than once a day) should not be stored in Active Directory For example, you should not store the time of day to the closest hour in Active Directory

! Data that is large Data that is larger than one megabyte should not be stored in Active Directory You should consider the bandwidth requirement for replication based on how large the data is before deciding to store it in Active Directory

With the exception of data required locally, if you have large or frequently changing data that is associated with an object in Active Directory, you can store that data in a database such as Microsoft SQL Server™ or on the file system and keep a reference to it in the directory For example, a voice mail system that is integrated with Active Directory can store data for each user (such as an extension, numeric password, and a reference to a file share containing user messages) By integrating with Active Directory, the voice mail system can authenticate the user and get access to the voice messages

associated with that user

Practice: Browsing Active Directory

In this practice, you will use the Active Directory Editor (ADSIEDIT), a Microsoft Management Console (MMC) snap-in that allows you to browse Active Directory You can use ADSIEDIT to view, change, and delete the attributes of any object in Active Directory

! Use the Active Directory browser

1 Log on as Administrator (if not already)

2 On the Start menu, select Run

3 In the Open field, type mmc and then click OK

4 When the MMC appears, select Add/Remove Snap-in on the Console

menu

5 Click the Add button

6 From the displayed snap-in list, select the ADSI Edit snap-in, click Add, and then click Close

7 Click OK to close the Add/Remove Snap-in dialog box

8 Right-click the ADSI Edit node beneath Console Root and select the Connect to option

9 In the Connection dialog box, verify that the Name field contains Domain

NC and then click OK The following illustration shows an example of the Connection dialog box

10 To view the top-level containers in your domain, expand the Domain NC

node and then expand the entry for your specific domain Some of the level containers relate to system and domain administration Others are created and used by applications The user information for the practical

top-exercises is stored under the PO System Users container You will see the

PO System Users container as a top-level container

The following illustration shows an example of a list of top-level containers

11 Expand the PO System Users container and examine the list of users and

groups that appears in the right pane

12 View the attributes associated with a user or group

Right-click the desired user or group and select Properties The following illustration shows an example of the Properties dialog box

13 Choose which types of properties you want to display in the property list From the Select a property to view drop-down list, select a variety of attributes and view the information about each one

14 Browse some of the other users and groups that interest you When you have finished browsing Active Directory, close the Active Directory Editor

# Using ADSI to Access Active Directory

! Active Directory Service Interfaces

! Binding to Active Directory Objects

! Manipulating Active Directory Objects

ADSI provides a set of functions and interfaces that you can use to access and manipulate data in a directory service In this section, you will learn how to use ADSI to access Active Directory data

This section contains the following topics:

! Active Directory Service Interfaces

! Binding to Active Directory Objects

! Manipulating Active Directory Objects

Active Directory Service Interfaces

! The ADSI Programming Model

$ Obtain a reference to an object

$ Access or modify attributes

! ADSI Interfaces

$ Class-Specific Interfaces (for example, IADsUser)

$ Generic Interfaces (for example, IADs)

! ADsPath

$ Specify hostname or use serverless binding

ADSI allows application developers to query and update the contents of a directory service such as Active Directory It also provides an abstraction of directory service contents that makes ADSI independent of the underlying directory service You can use ADSI to directory enable your applications.The APIs and interfaces in ADSI conform to the Component Object Model (COM) specification and support standard COM features, including Automation Consequently, you can access ADSI from a variety of Microsoft development platforms, including Microsoft Visual C++®, Microsoft Visual Basic®, Microsoft Visual Basic for Applications, Microsoft Visual J++®, Microsoft Visual InterDev®, Microsoft Visual Basic Scripting Edition, and other COM-enabled scripting environments

The ADSI Programming Model

Objects stored in Active Directory consist of a set of attributes Applications that use Active Directory data will follow two basic steps:

1 Obtain a reference to an object

The application retrieves a reference to the desired Active Directory object This process is also referred to as binding to the object

2 Access or modify attributes

The application reads or updates the object attributes

The specific attributes supported by an object stored in Active Directory depend

on the class to which it belongs ADSI provides two ways to access the attributes of an Active Directory object

Interface Description

Class-specific interfaces These interfaces include IADsUser and IADsPrintQueue

They provide specific COM properties relating to attributes defined for users and print queues For example, the

IADsUser’s Manager property is used to represent the

user’s manager The class-specific interfaces also contain methods that perform operations that are not attribute

related An example would be the IADsUser’s ChangePassword() method

Generic interfaces These interfaces include IADs and IADsContainer They

allow you to access any type of directory object For

example, the IADs interface allows you to read or update

the attributes of any object For more information about accessing and modifying Active Directory objects, see Manipulating Active Directory Objects in this module

Naming Syntax

To access an object in Active Directory, you must supply ADSI with information about the object, such as its LDAP DN You provide the object name and location in the form of an ADSI path, or ADsPath The ADSI path consists of the provider or namespace identifier followed by a colon (:) and the location information The exact format of the location information for objects in the Active Directory hierarchy depends on the provider Most directory access

is achieved by using the LDAP provider

An LDAP ADsPath takes the following form:

LDAP://hostname/ObjectName

The ObjectName parameter could be a specific name or an LDAP search filter

For simplicity, assume that it is the object’s DN The hostname defines an initial server to contact to request the object This hostname must be specified before the DN, as shown in the following example:

LDAP://POServer/CN=Juan,OU=PO System Users,DC=CONTENTM,DC=COM

If the server name is omitted, ADSI will perform serverless binding Serverless binding uses the locator service to find an appropriate server against which to issue the request for the specified object The following code shows an example

Binding to Active Directory Objects

! Using the GetObject Function

! Using the IADsOpenDSObject Interface

Dim user as IADs Path = “LDAP://CN=Juan,OU=PO System Users,DC=contentm,DC=com”

Set user = GetObject(Path)

Path = "LDAP://CN=Juan,OU=PO System Users,DC=contentm,DC=com"

Dim openDS As ActiveDS.IADsOpenDSObject Set openDS = GetObject("LDAP:") Set user = openDS.OpenDSObject(Path, "Administrator", "password",_

ADS_SECURE_AUTHENTICATION)

You can bind to Active Directory by using the GetObject function or by using the IADsOpenDSObject interface

Using the GetObject Function

The simplest way to bind to an Active Directory object is to use the GetObject

function You should supply an appropriate ADsPath to identify the object

required The following example shows how to use the GetObject function to

bind to an Active Directory object:

Dim user as IADs Path = "LDAP://CN=Juan,OU=PO System Users,DC=CONTENTM,DC=COM" Set user = GetObject(Path)

In this example, the variable user will be bound to the Active Directory object

representing the user Juan in the PO System Users container

To access an Active Directory object by using an interface other than IADs,

simply declare the reference as the appropriate interface type (for example,

IADsUser)