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.



Comments (4)

  1. yazanR says:

    I was facing a problem deciding this, What if we have two domains (A and B) domain A has all the users information, machines, logins.. etc and Domain B is a secure domain for the servers. if we are to deploy an application that uses Azman to domain B, and that application will be used by users registered in domain A, will it work? any suggestions?

  2. Hugo.Vallejo says:

    Hi everyone. I’m having troubles using the Microsoft.Interop.Security.AzRoles v1.0. (this version because of compatibility with an old application).  So, here’s the scenario:

    Client computer with Windows XP SP2. NET Framework 2.0, PIA 2.0 installed in the Global Assembly Cache. Of a group of computers only ONE presents the problem: the validation results on acces denied for a user but in other computer the authorization is granted. We’re using a XML file for the authorizartion store which is saherd for all the computer on a public folder on a server). As i said, only one computer presents the problem, but I need to make it clear that no exception is generated, in fact, the application access the file, creates the context for the user and performs the verification, the problem is that it results on access denied.

    The same problem occured in antoher computer, but after formatting the maching everythings worked fine. We don’t want to format every computer when this happens.

    Does any one know how to solve this problem?

    Thanks to all of you.

  3. davemm says:

    Regarding yazanR’s question about whether it will work to put an AzMan App in domain B and populate roles with users or groups from domain A – yes that is a key scenario that should work fine. There was an early bug that prevent one aspect of this but that should be fixed and should not cause a problem for you today.

    As for Hugo’s question, that is an unusual problem. One thing that comes to mind is that the user’s local group membership (or the local group membership of some domain group the user is a member of) may be different on that machine than on other machines (and maybe in rebuilding the machine the local group membership gets worked out.)