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

Contents
Overview 1
Overview of Directory Services 2
Using ADSI to Access Active Directory 19
Lab 6.1: Using ADSI 31
Using ADO to Query Active Directory Data 35
Lab 6.2: Using ADO 45
Best Practices 48
Review 49

Module 6: Integrating
with Active Directory


Information in this document is subject to change without notice. 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. 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.


Module 6: Integrating with Active Directory iii


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
iv Module 6: Integrating with Active Directory


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.

Module 6: Integrating with Active Directory 1


#

##
#

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.


Slide Objective
To introduce the module
and objectives.
Lead-in
In this module, you will learn
how to integrate distributed
applications with Active
Directory.
2 Module 6: Integrating 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


Module 6: Integrating with Active Directory 3


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.
4 Module 6: Integrating with Active Directory



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.
Module 6: Integrating with Active Directory 5


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.
6 Module 6: Integrating with Active Directory



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.
Module 6: Integrating with Active Directory 7


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).

8 Module 6: Integrating with Active Directory



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.

Module 6: Integrating with Active Directory 9

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
Microsoft Corporation. (MSFT).
C Country.

The following directory object names are examples that use the LDAP syntax:
LDAP://CN=Juan,OU=PO System Users, DC=contentm,DC=com

LDAP://CN=TopHat,DC=DEV,DC=MSFT,DC=com
LDAP://cn=MyName,o=msft,c=us

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.

10 Module 6: Integrating with Active Directory



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
Module 6: Integrating with Active Directory 11


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.
12 Module 6: Integrating with Active 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.


Module 6: Integrating with Active Directory 13


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.
14 Module 6: Integrating with Active Directory



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.
Module 6: Integrating with Active Directory 15


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.
16 Module 6: Integrating with Active Directory



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.

Module 6: Integrating with Active Directory 17

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 top-
level containers relate to system and domain administration. Others are
created and used by applications. The user information for the practical
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.
18 Module 6: Integrating with Active Directory



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.


Module 6: Integrating with Active Directory 19


#

##
#

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


20 Module 6: Integrating with Active Directory


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.

Module 6: Integrating with Active Directory 21



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.

You need to choose the type of interface best suited to your application. This
section focuses primarily on using generic interfaces.
For more information about ADSI, see "Active Directory Service Interfaces"
under "Active Directory, ADSI and Directory Services" in the Windows 2000
Platform SDK.
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