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.

How much for that LDAP server in the Window?

Jackson Shaw window shops the Red Hat Directory Server and doesn’t like what he sees:

Would I pay for an LDAP directory server today? No, I wouldn’t. I’d either go with OpenLDAP, ADAM or deploy an actual Active Directory domain controller (not free, but at ~$800 or less for unlimited users…) because I’ve talked to customers that have deployed >million user directories with each of those choices, they have vibrant user communities, are supported (vendor or community) and are technically sufficient for almost every purpose. I think if I was a small business with 500-2000 users I’d be looking at using a free solution, too – $10/user is just too much for a piece of history.

I agree with Jackson, but I can see one segment that would pay for this. If you had a Linux only infrastructure but wanted to have a vendor supported LDAP server then I suppose you would be willing to pay for it. But I really can’t see this as a robust market to build and maintain a product for.

I remember talking to an IT group that maintained a ~200K entry commercial LDAP server back ending a customer portal. They were going through a painful and time consuming data scrubbing exercise because they only had a 200K license and had been told they couldn’t buy more. I suggested moving to OpenLDAP or ADAM but they wouldn’t even consider it. Go figure.

Some advice about AD schema extensions

There was a little kerfuffle about AD schema extensions recently. Jackson Shaw smacked Mark Wilcox around about spreading FUD about Vintella and Mark walked it back a little later.

I thought I would offer some advice about AD schema extensions from the standpoint of having worked on a product that actually required AD schema extensions. The product that was originally OpenNetwork DirectorySmart and later became BMC WAM allowed you to write web access control policies based on the users and security groups in AD. But to do this you have to extend the AD schema. Of course the product also supported ADAM, iPlanet, and eDirectory so if AD schema extensions was an issue there was always an alternative. 

Now when Mark claimed that many companies have a policy against AD schema extensions he was quite correct. When Jackson stated that virtually every company’s AD schema has been extended he was also quite correct.

What gives?

It all depends on who is modifying the AD schema and why. Or put another way, just because a company is willing to modify their AD schema to deploy Exchange and Messenger, doesn’t mean they will modify their AD schema to support your product. Some companies will but some won’t.

At OpenNetwork we had many customers who would deploy a dedicated AD instance for their partners and customers identity (especially pre-ADAM). For these instances they didn’t really care if the schema was extended. Some customers chose the product for their corporate wide web access control and SSO and thus made the required schema extensions. But we did have a number lost opportunities where the potential customer wanted direct AD support, but wouldn’t make the required schema extensions.

The bottom line is if you are planning on developing a product based on AD, don’t require schema extensions if you can avoid it.

IGF and LDAP, again

Phil Hunt has some good thoughts here on my recent post about IGF and LDAP. Just to be clear I am not suggesting that IGF replaces enterprise AD. But as I understand the some of the IGF proposals around the Identity Bus concept, IGF APIs would replace LDAP APIs on the client side. At least for new applications. From Phil’s post:

The nice thing about CARML is that it is just a declaration. There is nothing saying a CARML declaration cannot be created by hand for an existing application. Though we are working on an open source implementation, it does not have to be used for applications and infrastructure managers to receive benefits from IGF. The new API is really about creating appeal for developers. Developers want something very different than enterprises. They want to be able to write flexible applications without having to spend 90% of their time writing code to support varied deployment scenarios and varied protocols.

For business, the benefits of IGF are going to be mainly around risk management and privacy as demand to use personal information increases beyond current traditional enterprise directory content. Enterprises wanting to use identity-related information from HR systems or CRM systems already have to worry about legislative and regulatory issues. While manageable today, the processes are largely manual and forensic in nature. It’s a situation that cries out for standardization.

As I said, I wasn’t suggesting that IGF replaces AD. But if you expect developers to migrate to a new way for developing client applications you need to give them a compelling business case.

Let take a concrete example. Suppose an IT shop wants to build a replacement time card application. If the requirements are that the web app looks the current user up in AD and routes the time card to the person in the manager field for approval, we know what the problems are. There could be data integrity issues where the manager field is not getting properly updated. There can also be compliance issues.

So IGF can tell the app developer what the data quality is for the manager field. But what is the business value? They still need the information regardless of the data quality. Yes there is a compliance issue. But again, what is the business value? The manually process of noting the field access by the compliance person only needs to happen once.

Switching to a new identity API is going to require tools and training. That is going to come out of the project budget and schedule. What are you going to tell the project manager to convince him to commit budget and schedule?

We all agree that for enterprise identity data AD is the clear incumbent and that isn’t going to change anytime soon. But on the application side LDAP is also very likely the incumbent. And you are trying to change that.

All I was trying to get across (not well I fear), if that displacing an incumbent technology is very difficult. I personally hope it happens on the client API side. But my past experience working on identity service standards tell me it’s a big hill to climb.