Last year Microsoft released another great tool for Plumbers to keep in their toolbox: Active Directory Application Mode (ADAM).
The "sweet spot" for ADAM is as LDAP-based storage for your custom applications -- applications that would otherwise request schema extensions to AD. There will be times when ADAM is the perfect tool for the job. (For more information on ADAM, you can read the introductory white paper.)
However, if you find yourself saying, "This is great! I'm going to use this because setting up a domain controller is just too hard," then I'd like to challenge your thinking. If your job is primarily authentication, your tool should be Active Directory domain controllers.
Support for the extranet authentication scenario (mentioned in ADAM white paper) is nice. But only if you are really committed to using LDAP simple binds for authentication and don't need any of the other authentication features built into Active Directory. This is often the case if you're using a web-sso product like those from OpenNetwork, Oblix, or Netegrity.
Some of the authentication features that you'll be missing are:
Also, you may find that AD as a solution is better supported...
When using Active Directory, developers will have the choice of which authentication scheme is most appropriate for their application. Most (all?) of Microsoft's own server applications will continue to be written to use Windows principals (AD users) and rely on a richer authentication method than an LDAP simple bind.
So, if you were building an authentication service, why wouldn't you want to use the option that is the most full-featured and best supported?
In the future, I'll address some of the objections to using Active Directory for the extranet access management scenario and try to debunk the myth that managing ADAM for that role would be easier.