Last time I talked briefly about IDirectoryObject and IDirectorySearch, let’s go into a little more detail today.

IDirectoryObject is an Interface that we can use to query anything in Active Directory, users, groups, organizational units, containers and so on.

I thought the best explanation would be to build a very small sample project, so let’s do that!

First we need some units, so please add the following units to your uses clause:

• ComObj (for EOleException and it calls CoInitialize for us)
• JwaWindows for the proper Adsi declarations

Next declare the following types:

(more…)

If you have ever used Adsi you have probably used the IADs interface or derived interfaces such as IADsUser or IADsGroup (maybe even without realising this).

What you need to know is that these interfaces were created to support scripting languages such as VBScript. The reason is that these scripting language have no support at all for structures such as ADSVALUE and don’t work with Pointers.

A typical use of IADs interface would look like this (in Delphi and using Jwa):

The IADs interfaces are fine when you are working with a single object but they are very, very slow, when working with many objects. I also find them a pain to work with as only a few AD attributes are present as properties. For other attributes you need to call the Get method which doesn’t always work, in which case you probably need to call the GetEx method. Even the GetEx method doesn’t always return the desired result as the property might not be in the Cache in which case we need to call the GetInfoEx method first and then Get or GetEx.

Active Directory has the nasty habit of failing when a an attribute is not set, so if you are reading a eg string attribute you probably expect an empty string but Active Directory returns a failure in such a case. And since Delphi declares Get(Ex) as SafeCall it will raise an Exception so you need to wrap it in try..except.

If we have obtained a value it will always be a variant that we probably need to convert to another type such as a string, datetime or an integer.

My results with implementing IADs interfaces in my Active Directory unit were bad: I wrote a test program that mimics Active Directory Users & Computer and enumerating a Container or OU with about 70 users takes 2-3 seconds. If you need to wait that long when expaning a Tree Node this in simply not acceptable. So I decided to completely drop the IADs interfaces and used the interfaces that are meant for higher level languages such as IDirectoryObject and IDirectorySearch. And guess what? Now my Delphi program, even when running in the debugger, is actually much faster than Active Directory Users & Computers!

To be fair to Microsoft, in the documentation of IDirectoryObject is the following note: The IDirectorySearch interface is a pure COM interface that provides a low overhead method that non-Automation clients can use to perform queries in the underlying directory.

In the next posts I will talk about IDirectoryObject and IDirectorySearch.

I am working on an Customer Management Console that will present all adminstrative tasks that customers will need in their environment in a single console.

It will handle Active Directory, Terminal Server and Citrix, Printers and will offer specific Views and Reporting. For the Active Directory stuff I decided to create some classes that enabled me to work with AD in a more Delphi OOP way.

In a series of Blog Posts I will write about interesting things or just random notes that I made while creating this stuff. The intention is to publish the whole unit in the Jedi Security Library when it’s finished.

Well I hope you that you’ll find some things of interest 😉

Part 1 is here .

If you are going to use the Active Directory Service Interface (ADSI) in Delphi, the first thing you will need is the typelibrary (TLB). This TLB is in the windows\system32 folder and has the name activeds.tlb.

We can import this tlb in Delphi (the procedure differs somewhat, depending on the Delphi version), but there are quite some problems with the resulting pas file of this import:

• Ugly and non meaningfull names such as __MIDL___MIDL_itf_ads_0000_0000_001.
• Record sizes are sometimes (read: usually) wrong due to alignment errors.
• Some Interfaces have wrong declarations resulting in Access Violations or just hard to use (eg using var for input parameters).
• Delphi works with Typed Pointer but since it has no clue on the proper name it uses PUserTypexx (eg PUserType1 = ^_ADS_CASEIGNORE_LIST). It’s hard to recognise later on what the real type is.

A version of the imported tlb is also in the Jedi Apilib (JwaAdsTLB) and basically it had the same errors. Because I was wondering how this would work in c++ I checked the SDK and found the header file Iads.h.

(more…)

I am writing a class that wraps Active Directory into Objects that live in an Objectlist, much like my Terminal Server class in the Jedi Windows Security Library.

One of the classes is TJwADUser that represents an Active Directory user with all kinds of properties. So while I was implementing them I stumbled upon the accountExpires attribute which is implemented as an 8 byte integer so I figured I could read it as Int64, cast this to TFileTime (FILETIME) and convert to TDateTime.

This raised an error however (EVariantTypeCastError with message ‘Could not convert variant of type (Dispatch) into type (Double)’.).

So I checked what kind of variant Active Directory returns and it is not the expected varInt64 but varDispatch.
It turns out that we need the IADsLargeInteger interface to obtain the correct values. The code below works for me:

Notes: The Get function is a wrapper for IADs(User).Get(Ex) so you can ignore that and my function returns 0 when the value is empty or on read failure.

Most administrator will want to prevent normal users from opening Regedit and a command prompt. Usually this is done by activating the “Prevent access to registry editing tools” and “Prevent access to the command prompt” policy settings. They are located under User Configuration | Administrative Templates | System:

Activating the policies will set the matching keys in the registry:

If we try to open regedit we are denied access:

So how does this work? (more…)

Microsoft has releaseed the Remote Server Administration Tools (RSAT) for Vista SP1. RSAT enables IT administrators to remotely manage roles and features in Windows Server 2008 from a computer running Windows Vista with SP1. It includes support for remote management of computers running either a Server Core installation or the full installation option of Windows Server 2008. It provides similar functionality to Windows Server 2003 Administration Tools Pack.

You can find RSAT here.

I had to lookup some users in Active Directory today which I received by mail. Offcourse I got full users name while I needed either samAccountName or full adsPath. Usually I write a small VBS script to do the lookup and paste this in Excel for further processing. But today I decided that an Excel function to do the lookup would be nice. So I wrote it.

The function is called GetAdsProp and allows you to search on a specific AD field in the whole AD tree and return the value of another field.

(more…)