1. Purpose Built for Active Directory -Unlike other solutions, ActiveRoles was purpose built for Active Directory while other solutions were built to manage the Windows NT account database.  Because solutions originally built for Windows NT could only be retrofitted to perform AD management they are not able to take advantage of core AD features many of which are discussed in this brief.
    
2. Integrated and timely support for key Microsoft platforms -Active Directory, Exchange, ADLDS SharePoint, ADSI and PowerShell are critical platform components that must be supported. While other products may take years to support the latest versions of these products, ActiveRoles typically supports them on the day they are released or at a maximum of 60 days post release.
    
3. Compatibility with Active Directory’s Security Model – The Active Directory permission model is based on a set of Access Control Lists that link directory rights to delegate trustees allowing the delegated admin to exercise those rights to perform some task in AD. Unlike ActiveRoles Server, most solutions require the use of a proprietary permission that have little or no understandable correlation to AD rights they grant. When the ActiveRoles service starts, the service creates a virtualized version of the AD rights used in the ACLs and then extends the list with several virtual permissions. To the person administrating security in ActiveRoles they seen an almost identically list of rights with the same look and feel of the native AD rights. ActiveRoles Server also has the added advantage of combining these rights into Roles for clarity and accuracy of security assignment and easy delegation of administration. A side benefit of compatibility with the Active Directory Security Model is the vast knowledge available on how AD permissions work and which permissions are required to perform specific tasks.
    
4. Compatibility with Active Directory Service Connection Points – A standard Active Directory service known as Service Connection Points (SCPs) allow applications to inform Active Directory of the applications presence in the enterprise. It is important to note that SCPs require no agents, customer configuration or changes to Active Directory. When the ActiveRoles Service executes it registers an SCP so that any console or web UI can locate the service instantly.
    
5. Compatibility with Active Directory’s DirSync service – A standard Active Directory services known as DirSync allow applications to instantly see what changes are happening within AD. This is the same service Domain Controllers use to exchange change information to determine what items need to be replicated. . It is important to note that the DirSync service requires no agents, customer configuration or changes to Active Directory. The ActiveRoles service listens to the DirSync service for changes made directly to Active Directory that may require ActiveRoles to perform some action such as enforce a group’s membership or send a change notification.
    
6. Virtual Unified Schema – Unlike other solutions that use a fixed schema and won’t recognize schema extensions, ActiveRoles uses a virtual unified schema built from the schemas of the domains being managed. When the ActiveRoles service starts it reads the schema of each domain being managed and adds that schema the ActiveRoles unified virtual schema. This unified virtual schema also includes any schema extensions that may be present in a particular domain so that applications that require data be populated during user provisioning or cleared during user deprovisoning can be supported. ActiveRoles also adds a set of virtual attributes to allow for more granular delegation over attributes or to allow other data not stored in AD to be associated with an object.
    
7. Real-time vs. Cached Data -To avoid the chance that two administrators open an AD object and view different information the retrieval of AD data must be done without caching of the data. Unlike many solutions that either load object data into a cache or into a separate database before an administrator accesses the object,  the ActiveRoles service retrieves the data in real-time.
    
8. Security Integrated Workflow -The role based delegation of administration provided by ActiveRoles Server not only allows the customer to control what AD operations each administrator, help desk admin or end user can perform it also provides the security context for change approval and workflow. By integrating a workflow engine and workflow editor directly into ActiveRoles, the customer avoids the need to configure and maintain multiple products and maintain multiple delegation models.
    
9. Unified Storage -Unlike other solutions that may require both Microsoft SQL and Microsoft AD LDS or Microsoft Access, ActiveRoles requires only Microsoft SQL Server for operation. Both ActiveRoles Configuration and reporting utilize Microsoft SQL Server. Less moving parts make ActiveRoles is simpler to deploy and maintain.
    
10. Embedded Extensibility - Because no off the shelf product will meet every need a customer may have the ability for the solution to be extended easily and in a maintainable way. In addition to both an external ADSI and PowerShell interface, ActiveRoles provides an embedded script editor, script library directly in the product so that the system can run a script in response to some event such as when a user performs an operation in Active Directory.

Virtual Directories do have their place and can help sometimes, but they also have their own set of challenges. One challenge is that since a virtual directory must connect to multiple data sources (yes some can go beyond directories and connect to databases, applications etc…) deployments can be complex. This complexity also may exclude the use of a virtual directory if the system must provide fault tolerance or failover capabilities. When data is written to or read from the Virtual Directory, not only must the Virtual Directory service be ready but so must all of the connected systems as well. If one connected system is off-line (or slow to respond) things can break pretty quickly. You may think caching may be an option here, but from experience the chances of viewing stale data become a strong possibility that no one will tolerate. I have seen only one Virtual Directory solution provide an answer around fault tolerance but even in that case the solution only worked multiple instances of a single vendor’s directory.

Another challenge is application compatibility. If you want your fax software or asset management software to be able to be able to make a call or make an update data through a virtual directory – you better make sure that application will work with the Virtual Directory you are considering.  The three Virtual Directory products I’m familiar with all support LDAP and some have web-service extensions as well. But neither of those interfaces matter if your critical applications have not been tested and declared supported by the vendor. If the vendor doesn’t support the use of a Virtual Directory you may be better off using something more old fashion like directory synchronization.

My conclusion here is that if you looking for Directory Management solution a pure Virtual Directory probably isn’t going to be worth the trouble; especially if your central directory is Microsoft’s Active Directory. If you are a developer, however, and you need to the ability to read or update multiple data sources a virtual directory may give you the great plumbing you need.

1. Separation of Operations – this is the most popular reason and is easily attributed to security or most companies deal with. The most typical reason I see is when a customer has an internal and external.
2. Internal Politics – Politics that drive more complex deployments can be caused by internal organization politics or external global or national politics. My opinion is that there is a better chance that internal politics that at first seem to demand additional directories will fad overtime.
3. External Politics – Some countries demand security separation for specific industries such as defense or finance and in most cases this is mandatory and probably won’t change soon. Unfortunately, this situation is pretty close to #1 Separation of Operations and so using
4. “A vendor requires it” – this is the least popular because people want fewer directories and so they avoid vendors who demand such things!  This is really the very-very worst reason to deploy new infrastructure I suggest anyone being asked to do this – think twice.

Even though customer directory deployments comes in all shapes and sizes there are a few common threads that I see and how those correlate to some new technologies that are starting to be adopted.  (More on this in a couple of days)

In part 3 I will go through why I see Virtual Directories being ignored.

I am always trying to better understand these environments so I started to think about why I don’t see virtual directories – When I ask customers and parts the answer is almost always the simple “it just doesn’t fit our needs.” This answer didn’t shed much light on what was going on and I decided to try and understand why they had multiple directories in the first place. I have found for main reasons for multi-directory deployments. I am sure there are more reasons out there, but these are the most common I run accross…

Stop back tomorrow for part 2.