As part of a large Identity & Access Management project we’ve beenmigrating a number of LDAP dependent systems from running under ASP.NET 1.1 to the 2.0 framework. The upgrade process has been remarkably painless, with the notable exception of a small but significant “breaking” change to authentication with System.DirectoryServices. In .NET 1.1 it is perfectly acceptable to issue an LDAP simple bind with code like this:

DirectoryEntry entry = new DirectoryEntry("LDAP://ldap.somecompany.com:389/");
entry.Username = "cn=Directory Manager";
entry.Password = "bigsecret";
/*...use entry for searching, etc, here...*/

However, execution of this code will fail under the .NET 2.0 framework unless it is modified to explicitly set the DirectoryEntry’s AuthenticationType property, because the class constructor no longer defaults the propertyto None. Here is what new 2.0 code should look like:

DirectoryEntry entry = new DirectoryEntry("LDAP://ldap.somecompany.com:389/");
entry.Username = "cn=Directory Manager";
entry.Password = "bigsecret";
<strong>entry.AuthenticationType = AuthenticationTypes.None;</strong>
/*...use entry for searching, etc, here...*/

Overall, its an easy fix, but finding every use of an authenticated DirectoryEntry in code can be tricky…

Nothing beats reading positive coverage of your company’s product. That’s why it’s so exciting to see that Dave Kearns, one of the most respected authors and columnists in the Identity Management space, has mentioned simAXS in his most recent NetworkWorld Identity Management Newsletter. From the article, Dave says that simAXS is “very useful” and that:

Anyone who has ever tried to develop a product that needs to be able to integrate with one (or more) of a number of different [Access Management] products will understand the problem this solves

It’s great to see that the pain-point simAXS is designed to address really does create a value proposition that’s recognized by the experts.

Microsoft ADAM provides a nice LDIF export tool, roughly equivalent to ldapsearch, called ldifde. However, the ADAM directory itself tracks a number of internal attributes that will cause a subsequent import of a generated LDIF to fail. In order to get a “clean” export, you need to selectively omit, via the -o command line flag, those operational attributes that you’re not interested in exporting (line breaks inserted for readability):

ldifde -f c:\people.ldif 
  -d "ou=people,dc=xyz,dc=com" 
  -s localhost 
  -t 389 
  -r "(objectclass=*)" 
  -o   "whenCreated,whenChanged,uSNCreated,
          uSNChanged,name,objectGUID,badPwdCount,
          badPasswordTime,pwdLastSet,objectSid,objectCategory,
          dSCorePropagationData,lastLogonTimestamp,
          distinguishedName,instanceType,lockoutTime"

The output generated by the command can now be cleanly imported into another ldap directory, or into a separate ADAM instance using a simple import:

ldifde -i -f c:\people.ldif -s localhost -t 389

Yesterday Identicentric released simAXS, a developer tool that makes it easy to simulate access management integrations in a development environment. Additional information including a product overview, guided tour, demo screencast, and free trial are available. Some background and history follows.

At the Burton Group Catalyst conference this year Jamie Lewis spoke at length during his keynote about the challenges facing Identity and Access Management products and deployments. Of special interest was the fact that he identified a lack of easy to use developer tools as a major road-block to the widespread adoption of I&AM technology.

Walking away from the keynote I recognized that he was, as is usually the case, spot-on. In fact the subject of the keynote coincided with the idea behind a small utility, inspired by a need for improved development process, that we’d started to write. The premise was simple – provide a small standalone and configurable component that would pass Header variables directly to applications. Many Access management, Single Sign-on, and federation products, including Oracle COREid Access Manager, CA eTrust Siteminder, and Sun Access Manager, use HTTP headers to pass information about the logged in user to a protected application. In some cases the information is as simple as a login ID, but many advanced deployments pass roles, group lists, profile data, and identity information using the same mechanism, like so:


Most access management products do this by installing a small piece of code (WebGate, Policy Agent, etc) into the webserver that can manipulate the HTTP request directly at the server level. In IIS this usually takes the form of an ISAPI filter.

This approach provides interoperability and flexibility between implementations, but has some serious drawbacks – mainly that it is difficult or impossible for developers to insert HTTP Headers programmatically because HTTP servers are opaque. Developers are usually faced with some very undesirable choices:

1. Run a complex Single Sign-on / Access Management / Federation stack in their development environment.
2. Work while continually tethered to a shared server on the corporate network.
3. Fake integrations using hard-coded variables and form based stubs (and hope things work when they are deployed to the integration test area)

Over the course of 10+ access management projects it had become apparent that these challenges often resulted in days or weeks of wasted time. Problems with shared data and access control would often complicate the lives of developers even further. Likewise coordinating integration with development teams increased the workload of the shared services groups responsible for the I&AM infrastructure.

Enter simAXS: developers use it to simulate the same HTTP header and cookie base integration provided by large-scale commercial access management products.

The difference is that each developer manages their local environment and configurations through the simAXS tools – there are no external dependencies on access servers, LDAP directories, SSL connections, or authorization databases.  Instead of depending on a shared system or hard-coded “stub code” the tool puts each developer in control, using a simple management tool, of the data passed into their standalone development environment.


SimAXS works by installing a small ISAPI filter into IIS that gains full control of the web server, just like the popular access management systems. Once installed, a developer can select the desired profile using a web based utility that “injects” the appropriate header and cookie data into their session.


Applications that have been developed using simAXS can be deployed to a full-scale access management protected integration test or production environment with no code changes. Simply configure the access management agents to pass HTTP headers or cookies of the same name, and the fact that the data is coming from an LDAP directory, access server, or database is irrelevant to the application. From the application’s view there is no difference between running with simAXS or an access management enforcement point- the interface is identical.

The simAXS application itself takes less than 5 minutes to install, but can save hours or days of time from a typical development cycle. It also includes sample code, debugging utilities, and other features to make a developers life easier. Feel free to check it out.

Matt Flynn, in a post about AD password sync, asks:

What if a Virtual Directory could pass authentication requests to Active Directory the way that ADAM does? … Would this be useful functionality in a virtual directory? Is it technically feasible?

+1 for virtual directory pass-through authentication.

It’s definitely technically feasible and works very well to drive consolidation of authentication services. From past experience it’s one of the most powerful benefits of virtual directory technology. In fact, this feature was key to the value proposition and purchasing decision for several of the prominent deployments I’ve worked on. It was also one of the key topics we discussed at the DIDW 2005 Virtual directory panel.