Microsoft has released Active Directory Service Interfaces (ADSI) for Windows 9x, NT and Windows 2000, and now it's inbuilt in Windows 2000. The Windows 2000 application specification states that you must use Active Directory when you can, so now you're thinking: How are YOUR applications going to adapt? What changes do you need to make? How are you going to use Delphi effectively to make these changes? This is what I intend to address in this presentation.

Let me first introduce a “directory service”. A directory service is like a telephone directory: if you have a person’s name, you can find his/her phone number. A directory service keeps track of “resources”, which could be anything – a file system is a directory that keeps track of files and folders, an email server is a directory service that indexes users, user groups etc. There are many directory services already in place: we already have file systems and email servers. What’s so different? Traditionally, you’d have to use different API’s (Application Programming Interfaces) to access different directory services – which :

Limit you to the vendor’s directory service. For example, if you wrote an application that extracted email information from Microsoft Mail and used the Mail Application Programmers Interface (MAPI), you would find it difficult to move to a different vendor.
Increase development time for your applications because you need to learn more API’s to get your application working.

There is a need to have a common model that every directory service would support – similar to the ODBC programming model that all (or most) database vendors now support. A model that will support a hierarchy of resources, like folders and files, and be simple to use. Active Directory provides this model. To access an Active Directory, you will use Active Directory Service Interfaces(ADSI).

Where is Active Directory used?
"Active Directory" encapsulates all directory services - a list of printers on a network, a set of services on an NT server etc. Directory services are very useful in an enterprise where one might know what he wants, may not know what that resource is named. (like, "give me a list of printers in the 2nd floor").
Any directory service can choose to publish itself as an Active Directory, so that a common querying mechanism can be used. At this point the following products support Active Directory:

Microsoft Exchange Server: Allows queries for email ids, names and a number of other attributes of people or groups across an enterprise.
Microsoft Site Server: Stores the list of users as an Active Directory.
Microsoft Windows NT: This gives you uniform access to users (earlier through User Manager for Domains), services (earlier through service manager) and network resources (computers, printers etc.)
Active Directory also provides bridges to access other similar directory services, like LDAP, NDS (Novell Directory Services) etc.

Active Directory is also an integral part of Windows 2000. In a large organization, Windows NT server has been used as a Primary or Backup Domain Controller, but it was difficult to integrate many such controllers to be able to provide security and privileges across the organization. Active Directory makes it simpler by allowing you to structure your organization into units which seamlessly (or so they say) integrate with each other. Which also means lesser problems when you expand, add more servers, more users etc.

To know more about how you can use Active Directory effectively in your organization, please visit: http://www.microsoft.com/windows2000/library/technologies/activedirectory/default.asp

Here's a list of places ADSI would be best used in:

User/Groups:Adding/Deleting users , Finding out if a user is a member of a group.
Changing a user's password
Starting and stopping services.
Getting printer information (jobs in print queue etc.)
Adding/Deleting web or FTP sites from Microsoft Internet Information server.
Getting user attributes from Microsoft Exchange Server, like email ids, Addresses, web directories etc.
These are just a few applications, and I'm sure there will be more as time goes on.


Prerequisites – What do you need to know?

This presentation assumes readers know COM (Component Object Model) and a working knowledge of using COM in Delphi.

What is ADSI?

Directory Services and Namespaces
There could be many objects within a namespace (users in an email server, files in a file system) which need to be uniquely identifiable by name. But you might have a user in the email server with the same name as a file in the file system:and they have no idea about each others existance. To maintain uniqueness, object names are prefixed with the name of the Directory Service they belong to. This name identifies a "namespace", with a namespace identifier like "WinNT:", "LDAP:" etc. (The ":" means that it's a namespace, and therefore, a directory service)

Object names are prefixed by the namespace identifier, and "//".
Note:This has analogies in the Internet, where you'd have Web pages identified by "http://..." and files on FTP servers by "ftp://..." etc.

ADSI in a nutshell
As Microsoft puts it, “ADSI is a set of COM programming interfaces that will make it easy for customers and Independent Software Vendors (ISVs) to build applications that register with, access, and manage multiple directory services with a single set of well-defined interfaces” (Ref.1) Active Directory Service Interfaces abstract the capabilities of individual directory services: which means you, as a developer, could access a file system the same way you access an email server or any other service that supports ADSI.

ADSI objects are Component Object Model (COM) Objects. You needn’t learn a new API for ADSI programming. You can develop for ADSI using simple Automation concepts. All ADSI objects support (and must support) IDispatch, so you can choose to use Late Binding or Early Binding. (Delphi supports both, quite magnificently) Here’s a small example of how to create a user on Windows NT 4.0 using Early Binding.

A Directory Service Provider is a module that gives a user access to a certain directory service. For instance, we were able to add a user to the Windows NT user manager because Microsoft has written an ADSI provider for the user manager.

This doesn't sound very great, you might say. What's the difference between doing this and using native Windows NT calls to add users? First, this is COM based so if Microsoft decides to change the entire implementation of the user architecture, your applications are safe, because there will still be an ADSI provider supporting the same interfaces. (Note: this kind of thing might not be about to happen.)
Second, consider your gains in extensibility. You can now add a user on a Netware Server using very similar code, except you'd have to use the ADSI provider for Netware. As we will see later, the code will follow a similar pattern for doing different activities: creating a web site, adding an email user etc.

Only for V.I.P