AD or ADAM?
A common question among AzMan deployments is how to pick the domain to store the AzMan policy in or whether or not to use ADAM. This comes down to factors that are unique to the network topology and applications but here are some initial suggestions to help decide (note that in Vista you'll have the additional option of using SQL.)
If your questioning whether or not you should put something in Active Directory use the best practice of putting data into the directory if it's globally interesting and relatively static. In most scenarios authorization policy is relatively static so the question becomes how globally interesting is it. If your authorization policy is used by many applications (or application instances) in a particular forest or domain then the directory is the ideal place to put it. The benefit of using Active Directory is that you leverage the infrastructure investment that you have already made for reliability and availability. So generally, when deciding which AD domain to use to store AzMan policy or whether to use AD or ADAM you should first look to leverage AD, look for a domain that's a good fit for the applications using the policy and then to ADAM if AD doesn't fit. There are several reasons it may not fit for a particular deployment.
In picking the domain, ideally you want the AzMan applications that need the authorization policy to be able to quickly get it from nearby DCs. Meanwhile, those DCs not near AzMan applications should avoid replication of the AzMan store. Since the AzMan policy will be replicated to each DC in the domain in which it is stored it's possible that if you select a broad domain that the AzMan policy would be replicated to DCs where no applications are using that policy. The ideal scenario for using the AD policy store is when the authorization policy is being used by apps nearby the DCs in a domain. When a domain has a high number of DCs that would not be used by AzMan apps or administrators to access the AzMan policy then it's worth it to try and optimize the deployment by using an existing convenient child domain, creating a child domain, or use an ADAM store.
When there are multiple domains then it is often the case that an existing domain has its DCs already positioned near the set of apps using the same AzMan policy store (related apps are often in the same domain.) When this is the case such a domain is a good place to store the AzMan policy. If the applications are in different domains and the applications are unrelated in terms of administration then you may be better off with separate stores. In this case the stores may be AD, ADAM or XML depending on the needs of the app and administrators.
An ADAM store is ideal if there is IT resistance to adding an AzMan policy store to a domain or resistance to creating a domain for the sole purpose of storing Authorization Manager policy. When this happens ADAM is ideal to store the policy for one or more AzMan applications. Additionally, if the application already uses ADAM for some purpose then using ADAM to store the policy may make the overall setup and administration simpler.
The other (more obvious) scenario where ADAM is used is for situations where you can't know for sure if a domain will be available (from the ISV perspective) or when your organization doesn’t have a domain. In these situations it pretty easy set up an ADAM instance with or near your app and store policy there.
This always leads to the question of application partitions. We are investigating the possibility of supporting AzMan deployments in application partitions.
-Dave