What is the focus of this article?

Specifically this article will examine the interaction of PowerShell and Active Directory Domain Services when utilising a proxy solution to manage the object lifecycle within the directory.

I would like to thank Richard Siddaway for his input into this article

What is a proxy solution for Domain Services?

In a traditional implementation of Active Directory all change requests are made directly to a Domain Controller which evaluates the effective permission granted to the requester based on the Access Control Lists applicable and for certain attributes checks the validity of the data to be written based on constraints within the schema.

A proxy solution implements an intermediate server or service between the requester and the Domain Controller which in most implementations performs additional validation, automation or custom ‘views’ of the directory. Figure 1 Update Request Comparison shows the effect of utilisation of a proxy server managing update requests to the directory.

Figure 1

What have been the drivers to use a proxy solution?

The key drivers for organisations to adopt a proxy solution have been:

What would be a typical proxy solution?

Like Domain Services implementations proxy implementations vary based on the organisations requirements and underlying Domain Services design but certain tenets are commonly observed:

The key factor is that all data administration of directory objects is handled via the proxy solution either using a web interface or a client tool specifically written to connect to the proxy. Microsoft supplied tools such as Active Directory Users and Computers, Sites and Services etc. are solely for use by service administrators when performing service administration tasks.

As the proxy solutions have evolved in the market a number of companies have integrated their tools with one or more of the proxy solutions and the suppliers of the proxy solutions have expanded their solutions to include support for Microsoft applications such as Exchange.

Why does the emergence of PowerShell cause concern?

PowerShell may be one of the most important ‘small’ technologies Microsoft will provide to enhance the Windows platform because:

But as noted elsewhere PowerShell is a .NET based technology that when accessing the directory does so mainly via the namespaces System.DirectoryServices and System.DirectoryServices.ActiveDirectory within version 2.0 of the framework.

These classes are designed to interact directly with Domain Controllers when accessing Domain Services and have no provision for redirection to a proxy server or service. This functionality would require either implicit support in the classes for a specific proxy or for the proxy to completely implement the behaviour of a Domain Controller which none currently do.

While it is technically possible for Microsoft or a third party to derive classes from those in the System.DirectoryServices and System.DirectoryServices.ActiveDirectory namespaces to implicitly call a proxy this would not alter the behaviour of existing solutions using the current classes and apart from being bound to a specific proxy could be prone to considerable compatibility issues.

Exchange 2007

A key factor in adoption of Exchange 2007 is predicted to be the significantly enhanced management capabilities provided via PowerShell and the fact that all administrative tasks can be done using PowerShell command applets often shortening previous scripted solutions from tens of lines to one or two!

Microsoft has also radically simplified the delegation of permissions for Exchange tasks with Exchange 2007 by assigning messaging related attributes to a series of Property Sets and assigning appropriate default permissions to predefined groups or the user itself.

To date the suppliers of proxy solutions have also provided Exchange administration in addition to domain administration and no doubt will continue to do so for Exchange 2007 perhaps even gaining increased support from Microsoft for their efforts if the proxy itself utilises Microsoft’s Exchange command applets. Data administrators performing Exchange tasks using a GUI interface are unlikely to be effected to any significant degree. Those who will be significantly impacted if access to Exchange, for data as apposed to service administration, is maintained to be exclusively via a proxy will be administrators seeking to utilise PowerShell scripts.

Potentially the proxy suppliers could provide capabilities to execute these scripts either utilising the proxy service account or the users own security context but likely limitations for access to read and write to files, spawn additional processes etc. will impact some proportion of scripts most especially those likely to provide the best return on investment for the Exchange 2007 implementation.

Scripting

Most of the current proxy solutions implement a replacement interface to the Active Directory Service Interface (ADSI) libraries that ship as part of the Windows system allowing most VBScripts to operate via the proxy without major alteration. VBScripts etc. accessing the directory by ADSI would of course bypass the proxy and such access would be dependent on the permissions in the native directory.

Due to the nature of PowerShell scripts and their interaction with command applets, either supplied by Microsoft or third parties, and the underlying use of the .NET classes which in turn use not just the ADSI libraries but a number of others and direct LDAP connection in certain cases to Domain Services simple changes as can be done with VBScripts using ADSI is unlikely to be feasible.

Altering PowerShell scripts downloaded for example from Microsoft’s Script Centre to work via a proxy solution will in many cases be non trivial and when they have been supplied as part of a product may not be a supported option.

New command applets

Although PowerShell is currently in the late beta stages of development a considerable number of additional command applets are being developed to address areas requiring scripting such as Active Directory. Some are free software available as source code others are not, especially those which will be commercial products limiting the scope of users to make changes required to integrate them with a proxy solution. 

As Microsoft utilise PowerShell in further products such as the System Centre range and in all likelihood Windows ‘Longhorn’ for Domain Services tasks they are, based on previous practice, very unlikely to make the source for such tools freely available. This is significant as current generations of most applications other than Exchange make very limited use of the directory and when they do it is usually information managed by service administrators. Integration, for instance Live Communication Server, with user information within the directory is becoming much more common and likely to increase in particular within Microsoft products.

Conclusion

Before PowerShell organisations utilising a proxy solution to validate and control changes to the directory could either permission the directory to only allow Service Administrators rights make changes or prohibit technically or by policy the use of tools such as Active Directory Users and Computers, DSADD etc.

As a general rule prohibition of tools other than those compatible with the proxy solution has not been seen as a significant issue as most proxy solutions have provided a means to utilise VBScripts written to use the ADSI interface and included an implementation of the required functionality for Exchange server.

This will not be the case for PowerShell as redirection of its access to the directory on a client machine will be complex in comparison to VBScripts use the ADSI interface and the likely ubiquitous use of PowerShell and command applets within the medium term as the common base level automation of the directory and associated systems such as Exchange.

Organisations that have historically chosen a proxy model for data administration of the directory will be unlikely to revert to allowing direct access to alter the directory without either the changed behaviour of the 'Longhorn' security reference monitor or the an implementation that has improved capabilities for validation of requests and trigger additional events pre or post such alterations. For these organisations PowerShell has the possibility to be a significant ‘pain point’ in the evolution of the Windows platform.

Possible future directions include: