So, it’s pretty well understood what Active Directory (AD) is. Since we shipped Windows 2000 several years ago, we’ve been putting information out there on what AD is, how you use it, how it benefits you, and why you should use it for as much integration as you can. I think AD sells itself to a large degree.
More recently, we released a product called Active Directory Application Mode (ADAM). While we have several good “what is ADAM” docs out there, I wanted to take a swing at it and ensure we’re all level-set on what this new directory technology really is. This one is sure to come up again.
I am a huge ADAM fan. I enjoy working with it, talking about it, thinking about it, and just generally evangelizing it.
I felt I had to say this now as the future of this blog will be tainted with my bias. You should know it’s there. 🙂
So, you might be wondering why I’m so pro-ADAM. What do I think it can do that’s so cool? My reason is actually quite silly, and has little to do with using ADAM in the real world.
You see, I enjoy working with the innards of AD. That is, the core directory itself. Sure I enjoy working with all of the stuff on top of it….authentication/authorization, policy, DNS (or is DNS below it? A debate for another day….), and countless other technologies….but in reality, it is the core directory I enjoy working with most.
So where does ADAM fit in? Well, think of ADAM as the core directory of AD, stripped out, and called its own service. It has many of the LDAP and RPC interfaces we use in AD, but without the deep OS integration we’ve come to expect. One can run ADAM on any member server, domain controller or workstation in your environment (in any domain or workgroup). While we encourage it to be used on Server 2003 when in production, ADAM will also run on Windows XP (with some minor functionality not available).
Of course, my personal interest is probably not enough to inspire many organizations to deploy this product (although perhaps it should be! ;)). The following scenarios tend to be where we see ADAM used most:
- Application development scenarios – We were told that people wanted what AD had to offer but wanted an independent schema, configuration, administrative model, etc. They wanted to use it as a light-weight application data store that they use in-conjunction with their existing infrastructure.
- Extranet scenarios – ADAM can be used as a nice user-store for users whom need only be authenticated via LDAP binds. These users don’t need to be full-fledged Windows security principals. Rather, they really just need a user for a custom application.
- Migration scenarios – People told us they wanted to get on the path to AD, but it’s a long one as they have many applications which are designed around a legacy directory. They can now use ADAM as an interim step (custom schema, X.500 naming, etc.) and move to AD fully when their application is ready.
These are just a few scenarios of course; we have more outlined in the documents available from the ADAM home page. And others would come up with scenarios of their own too not listed in our documentation.
While we’re on documentation, I’d like to suggest going to the homepage I linked to above, and checking out the Active Directory Application Mode Technical Reference. In terms of depth, that has the most information out there.
I’d be remiss if I didn’t mention the FAQ. In addition to those questions a few more that I have been asked recently:
Q: How does <insert AD component here> work in ADAM? I don’t see any documentation on it.
A: When it comes to inside the directory type concepts, ADAM maps to AD in Server 2003 when you have the forest functional level set to the max (2003 forest functional, aka ==2). So all of the fun things like enhanced schema defunct, linked value replication, increased multivalue limit, etc.
Q: I’ve read quite a bit about the user proxy functionality that is in ADAM. How do I know if that’s for me?
A: I’d like you to indulge me, and let me skip this for now. I have a future post just dedicated to this one functionality. The FAQ on the ADAM homepage mentioned this a bit, but we’re going to dedicate some more time to it.
Q: What does the ADAM schema look like compared to the AD schema?
A: During ADAM setup we give you the option of importing several elements that help close the gap between the two schema’s (specifically for InetOrgPerson and User). That said, they are still not identical. There are some items in the AD schema that you will not find in ADAM, but you are more than welcome to migrate them yourself. And I’m happy to help if you’d like it. 🙂
Q: How well will <insert your application name here> integrate with ADAM?
A: That’s a tough question to answer in the aggregate. Most applications which are pure LDAP-consumers will integrate nicely with minimal work. Some other applications (for example, those that use integrated Windows authentication) may require more work. Still others might not port well at all due to the lack of Windows security infrastructure integration or other AD-specific functionality. As we go through more ADAM-related posts, I think this question will answer itself to a large degree.
Q: I didn’t see mention of pricing. What does ADAM cost?
A: ADAM is licensed just like AD. That is, so long as you have your Windows CALs set up (or however you license Windows server and client today), ADAM is licensed too.
I have quite a few upcoming posts on ADAM in my head, including: high availability deployments, user authentication, schema migration, and performance tuning. These topics make the best ADAM posts (I think) because they are where we differ the most from AD (schema migration perhaps the delta is small, but we do get the question often). Most other topics we’ll cover by virtue of talking about them in AD, and ADAM differences will be noted as such. Please do holler if there are other ADAM-specific things that you think need attention which I didn’t mention.