Component Tales: Active Directory Scripting Interface - ADSI
[The following article is authored by one of the Windows Embedded MVPs (Most Valuable Professionals). Our MVPs have a heavy background in Embedded systems and are a great repository of information on Windows Embedded products. We’re providing this space on our team blog as a service to our readers by allowing MVPs to share some of their knowledge with the rest of the community.]
There are projects where the purpose of a tiny embedded device is to work robustly as a standalone unit and there are times when embedded devices are required to participate in sophisticated enterprise scenarios. Examples that fall into the latter category could be automation controllers or thin clients. Naturally, these types of devices have very different specifications for both their hardware and software. It is quite surprising that, despite this, a single embedded operating system such as Windows Embedded Standard is able to be a good fit for both use cases, as opposite as they are.
There have been a lot of posts on how to build smaller devices and now it is time to shed some light on the enterprise features of Embedded Standard.
Directory Services – the very core of an enterprise network
Directory Services are found at the heart of every company’s network, because they provide the management system where all user, computer and other system credentials and rights are stored, as well as managed. In a Windows network this directory service is called Active Directory and requires special servers, called Domain Controllers, which are solely dedicated for this purpose. A new developer API to interact with and maintain these services was created at the time Active Directory replaced the older NT Domain model: ADSI.As the name says, it was created as a scripting interface based on COM technology to give administrators fast and easy access to the directory infrastructure. The ADSI syntax can be compared to WMI scripting, because the two technologies were created roughly in parallel.
Here is a simple code snippet that shows how to move the ATL-Users group from the HR organizational unit into the Users container of the same domain:
The first line of code binds the action to the Users container of the Fabrikam domain, which acts as the target. Careful, this approach needs some acclimatization when you start writing scripts!
The second line then moves the ATL-Users group into the target container.
TechNet and MSDN are your friends
There are a lot of valuable script samples on the Microsoft TechNet site on how to accomplish day to day scripting tasks using ADSI. I explicitly state Technet, because developers normally turn to MSDN for coding information. Of course, there is a lot of additional information on MSDN, too, about the programmatic use of this API. Be aware that, due to the nature of the underlying COM technology, the effort required to use ADSI with native code (C++) is much higher than the effort required for scripting languages such as VBScript or Jscript.
There is a managed wrapper for this API, as well. One needs to set a reference to the System.DirectoryServices.dll in the managed project and add this namespace to the code:
After including this, AD is accessible from a managed embedded maintenance application or a custom shell running on e.g. a thin client device.
Including ADSI in an embedded image
There is one important thing necessary to make these code samples work. The ADSI components need to be added to the image configuration from the infrastructure node, as shown below. As one can see, there are additional providers for other non-Microsoft directory services, as well.
This is great, because it enables embedded devices to integrate into 3rd party environments as first class citizens. The footprint impact of ADSI on an embedded image is relatively modest - around 20 MB. The impact of a .NET Framework component is much higher. One should also not forget to include this infrastructure for managed code or the Windows Scripting Technologies in an image.
ADSI Tools
There are some helpful tools available to make a developer or administrator’s life easier.
The ADSI scriptomatic, including some entertainment, comes from the TechNet scripting guys.
Really funny folks over there….
ADSIEDIT is part of the Windows support tools.
It is a lightweight LDAP editor to manage objects and attributes in a directory.
Not only AD!
ADSI provides a valuable way to access and maintain the functionality of Internet Information Server (IIS) or Exchange Server, too. While having IIS on an embedded box is not too unrealistic, running Exchange Server certainly will present at least a licensing problem.
Alexander Wechsler
Wechsler Consulting