Tag Archives: AD

Did you get DC source code for Christmas?

Just in time for Christmas Samba 4.0 was released. This big news here is Samba 4.0 adds Active Directory Domain Controller emulation, including Kerberos, LDAP, DNS, and a bunch of other services.

While this is an impressive technical achievement, I don’t really see many enterprises adopting it. Samba 4 is fighting against one of the biggest IT pressures, headcount reduction. Most enterprises are now willing to pay more for the license cost of the software if it saves them administrative man hour costs.

So unless Samba 4 is going to be easier to install and maintain than Windows servers, it’s not really going to have an impact. Who knows, maybe it will be that easy. If you have Samba 4 in production drop me a comment and let me know what you think.

Meanwhile, Jackson Shaw is … unimpressed.

Enter the Migrator

One common business case we get is to migrate from various directory servers to AD. This is usually an issue of per user license cost but lower maintenance is also a factor. Companies are realizing that since they are maintaining AD anyway, why pay for and maintain other multiple directory servers as well? For employee accounts it usually doesn’t make sense to have the same account in two places and need additional processes just to keep them in sync.

There are several ways you can migrate directories. You could use a one-time import/export, a Metadirectory, or a provisioning system, but these approaches have several key drawbacks. One issue is that in most cases you can’t migrate the user passwords. Another issue that the migration may require custom attributes to be added to AD (try getting your AD team to agree to that).

But the biggest issue is that these directories exist for a reason. There are client apps, sometimes tens or hundreds, which rely on the information in the old directories. Most home grown apps written for one directory won’t be able to switch over to AD without extensive rewriting. Even commercial apps that support AD may require significant and disruptive configuration changes.

Enter the Migrator (obscure Disney reference intended)

A virtual directory can be your Migrator. The solution is to standup a virtual directory that merges your AD with the old directory into a single view that emulates the old directory. Run both directories side by side while migrating the accounts. When a password change is made the virtual directory can update both AD and the old directory with the new value, so after running side-by-side long enough, most of the passwords will have been migrated. Eventually the old directory can be retired.

This approach has two main advantages:

  • no changes need to be made to the client applications
  • no schema changes need to be made to AD.

There is a good white paper that covers this in detail on the OptimalIdM web site (no registration required).

Open source C# SPMl v2 implementation

Softerra has released an open source C# implementation of SPML V2 (DSML profile). I haven’t had time to play around with it yet, but it looks interesting.

Now what would be really great would be some developers to take this and create some implementations that do useful stuff. For instance write a service provider for provisioning and reconciling AD accounts. Or perhaps integrate it with Microsoft FIM.

OptimalIdM and WIF

OptimalIdM has announce support for Microsoft WIF (you can get more info here). What they have done is pretty interesting. The have created an STS that front ends their Virtual Directory. This allows a single STS to be used to issue claims against multiple identity stores.

Of course the main use case here is the multiple AD forest scenario, but it could also support disparate identity stores such as other LDAP directories, databases, etc.

[Full disclosure: I have done consulting work for OptimalIdm in the past.]

Two for the show

Ian Yip has more yet another humorous summary of the virtual-meta-active-directory-identity-bus-hub-proxie debate. You can catch Part II here and Part I here.

I almost want to keep this debate going just so I can read Part III.

Accounts and Identities

Nishant Kaushik makes a very good point in his latest post on the Virtual Directory vs AD debate:

Here is my point. Martin says “AD is the directory…”. I say that “AD is a directory…”, and that too because Windows forced it on those enterprises, not because of their Identity Management needs. Yes, almost all the Fortune 500 have AD, but are they using it as an Identity Store, or as a Windows Account Store (which is very different)?

To answer the rhetorical question, the vast majority of AD deployments are not intended as identity stores (at least from my experience). In most enterprises AD is used to manage and control user access to Windows workstations, the intranet, email, and enterprise web applications. AD is not usually intended as a central repository of identity, although it often becomes that with varying degrees of success.

And here is the real crux of the matter: most enterprises don’t really want an identity solution. What they want is a “spend less money, get everyone access to what they need when they need it, keep the bad guys out, keep us out of the headlines, and the CEO would  really, really, like not to go to jail” solution.

They have been, in many cases, sold on the idea that identity management is the solution that they want. And indeed it can be part of the solution.

But here is the brutal truth, and the reason that enterprise identity management is so messy. Almost all enterprise applications are account-based not identity based. Very few products support externalizing the identity concept in their products. They most you will usually see is supporting AD or another LDAP for authentication. Less often you might see simple group membership for authorization. A few commendable vendors such as SAP support SAML, but it’s a very small list. Support for external identity services or other identity standards such as SPML and XACML is nearly  non-existent.

Which ties in with the question Nishant closes with:

By the way, why is it that architectural purists don’t ask when Microsoft will make it possible for Windows environments to work against any directory and not just AD, but Oracle Applications must support directories other than OID? In the end, both Microsoft and Oracle are wrong to push proprietary stores into deployments, contributing to the mess we have.

Authentication Lock-in

Jackson Shaw adds some interesting thoughts to the Virtual-Directory vs Directory debate here. He points out that the real lock-in comes with authentication:

And, finally, what’s the big deal about being “locked into AD”? Have people forgotten that AD *is* an LDAP directory? You get “locked into AD” when you use it for desktop authentication otherwise it’s just an LDAP directory with its own set of idiosyncrasies just like any other LDAP directory.

I would also add IIS Windows Integrated Authentication to that as well.

And this is a very interesting point. If you are using Windows Authentication for either the desktop or web login, the need to support multiple types of directories is greatly diminished.