Introduction
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 :
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 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.
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.
var
Container : IADsContainer;
NewObject : IADs;
User : IADsUser;
hr : HREsult;
begin
// COM must be initialized
CoInitialize(nil);
// Bind to the container.
hr := ADsGetObject('WinNT://YOURDOMAIN',IADsContainer,Container);
if Failed(hr) then exit;
// Create the new Active Directory Service Interfaces User object.
NewObject := Container.Create('User','ActiveDirectoryUser') as IADs;
// Get the IADsUser interface from the user object.
NewObject.QueryInterface(IID_IADsUser, User);
// Set the password.
User.SetPassword('Borland');
// Complete the operation to create the object.
User.SetInfo;
// Cleanup.
Container._Release;
NewObject._Release;
User._Release;
CoUninitialize;
end;
|
Note: The ADsGetObject function is declared in AdsHlp.pas that is included with this article. The interface definitions are imported from ActiveDS.tlb in the WinNT/System32 folder. You will need to install ADSI 2.5 from http://www.microsoft.com/ntserver/nts/downloads/other/ADSI25/default.asp.
I will explain the architecture in more detail in the Architecture section. Active Directory Service Interfaces can be used easily in Delphi, though all the examples and support in the http://www.microsoft.com/adsi are in Visual Basic or C++ code. With this paper, you will find all the translations of the header files, some samples and some new Delphi translations. (A copy will be maintained at http://www.agnisoft.com/adsi)
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.
Take a look at the next section for more benefits.
Why should you use ADSI?
|
Feature |
Benefit |
|
Open |
Any directory provider can implement an Active Directory Service Interfaces provider; users can easily move to a different provider of the same service with a minimum rewrite. |
|
Security |
ADSI supports both Authentication and Authorization programming model - You can give even role based security for your applications. |
|
Simple Programming Model |
As you will see, the COM model is very easy to understand. The model remains standard for all providers: there's no need to understand vendor specific APIs. |
|
Automation Server |
Any Automation Controller (for example, Delphi, Visual Basic, C/C++ and others) can be used to develop directory service applications. Administrators and developers can use the tools they already know. |
|
Functionally Rich |
ISVs and sophisticated end users can develop serious applications using the same Active Directory Service Interfaces models that are used for simple scripted administrative applications. |
|
Extensible |
Directory providers, ISVs, and end users can extend Active Directory Service Interfaces with new objects and functions to add value or meet unique needs. |
