Active Directory Service Interfaces (ADSI) evaluation criteria

Exchange

Find evaluation criteria information for Active Directory Service Interface (ADSI).

Last modified: November 05, 2013

Applies to: Exchange Server 2003 | Exchange Server 2007

In this article
Functional criteria for ADSI
Development criteria for ADSI
Security criteria for ADSI
Deployment criteria for ADSI
Additional resources

Active Directory Service Interfaces (ADSI) is a set of open interfaces that abstract the capabilities of directory services from different network providers to present a single view that you can use to access and managed network resources. You can use ADSI to enumerate and manage resources in a directory service, regardless of whether the network environment that contains the resources is LDAP-based, NDS-based, or NTDS-based.

The following table lists and describes the functional criteria for ADSI. For descriptions of the functional criteria, see Functional criteria in the Exchange development technology evaluation criteria descriptions article.

Table 1:  ADSI functional criteria

Criterion

Description

Application function

You can create many different types of applications by using ADSI to access resources that are stored in the Active Directory directory service or Active Directory Domain Services (AD DS).

Availability

Active Directory is available in versions of the Windows Server operating system starting with Windows Server 2003.

Application architectures

ADSI client applications are typically Windows forms–based applications.

Remote usage

You can create client applications that use ADSI to access Active Directory or AD DS remotely.

Major objects

ADSI objects abstract computers, users, user groups, printers, sessions, services, other network resources, and the Active Directory schema.

Data access model

ADSI represents users and other resources in an object hierarchy.

Threading models

ADSI can use any threading model that is appropriate.

Transactions

ADSI applications use transactions.

Management capabilities

You can use standard Windows technologies to manage ADSI and Active Directory.

The following table lists and describes the development criteria for ADSI. For descriptions of the development criteria, see Development criteria in the Exchange development technology evaluation criteria descriptions article.

Table 2:  ADSI development criteria

Criterion

Description

Languages and tools

You can use ADSI with any COM/automation-compatible languages, as well as with non-COM languages such as C/C++.

Managed implementation

The System.Directory.Services namespace allows for managed implementations of ADSI applications.

Scriptable

For most administrative tasks, ADSI defines interfaces and objects that are accessible from automation-compliant languages like Visual Basic Scripting Edition (VBScript).

Test/debug tools

You can use all standard test and debugging tools to test and debug ADSI applications.

Expert availability

ADSI is a reasonably well-known technology. To find developers who are familiar with ADSI, see the Exchange Previous Versions – Development forum.

Available information

You can find third-party websites and books about ADSI. For information about ADSI on MSDN, see Active Directory Service Interfaces.

Developer/deployment licensing

No special licensing is required to use ADSI to develop applications. The libraries and COM objects are installed with Windows.

The following table lists and describes the security criteria for ADSI. . For descriptions of the security criteria, see Security criteria in the Exchange development technology evaluation criteria descriptions article.

Table 3:  ADSI security criteria

Criterion

Description

Design-time permissions

The account under which the client application runs must have permission to access the directory service information. The permissions required will vary based on the type of operation the application performs. We recommend that you avoid granting Schema Administrator rights to service accounts.

Setup permissions

You do not need specific permissions to install applications that use ADSI. If the setup application has to make schema changes to Active Directory, the user running Setup must be a schema administrator in the domain. If the setup application must change data inside Active Directory, the user running Setup must have appropriate permissions to make those changes.

Run-time permissions

You should deploy applications that use ADSI only on those systems and for those users who have sufficient permissions to access the information that the application uses.

Built-in security features

ADSI and Active Directory fully support all Windows authentication and authorization features, including item-level permissions within Active Directory.

Security monitoring features

None.

The following table lists and describes the deployment criteria for ADSI. For descriptions of the deployment criteria, see Deployment criteria in the Exchange development technology evaluation criteria descriptions article.

Table 4:  ADSI deployment criteria

Criterion

Description

Server platform requirements

No specific requirements.

Client platform requirements

No specific requirements to access Active Directory information within the user's domain. Active Directory security policies may limit cross-domain, or cross-forest, access.

Deployment methods

No specific deployment methods are required.

Deployment notes

None.

Show:
© 2014 Microsoft