Provisioning Active Directory - Best Practices

by Martin Sandren on April 27th, 2009

After the very popular Suncle series covering the Sun/Oracle identity and access portfolios, the blog went on a brief hiatus but we're baaaaaaack. Instead of giving y'all yet another dose of Identigral, we've got Martin Sandren as our guest blogger today.

Martin is a security architect at Genzyme in Boston. Prior to joining Genzyme he spent four years implementing Oracle Identity Manager for Sena Systems in both US and Europe. Martin is originally from Sweden where he received his Masters degree in computer science from Chalmers University of Technology. He also lived in Germany and the UK. You can reach Martin via LinkedIn or Xing.

---

A recent entry on Identigral blog talked about about managing entitlements instead of just managing the relationship between the entitlements and the users/roles. This sounds great, but how does this actually work in practice?

For our example, we will use Oracle Identity Manager (OIM), Active Directory (AD) and the OIM connector for Active Directory. In the series of articles on the subject I will illustrate an approach to extending the connector and using OIM framework such that it will go from managing the AD user account with base-level set of attributes to managing the relationship between entitlements and users to finally managing the entitlements themselves. As the first step in this process is to manage the base AD user account, I will start with that.

Since Active Directory represents a central nervous system for most Microsoft infrastructure deployments and just about every organization out there has deployed Microsoft apps and services regardless of whether they like it or not, Active Directory is one of the most common target systems in OIM implementations. Implementing support for provisioning of base AD accounts usually yields a quick win in the form of improved operational efficiency and greater compliance, especially in regulated environments.

The out-of-the-box Active Directory connector does a good job of creating base AD accounts as long as you don't have any specific requirements that deviate from the lowest common denominator. Unfortunately, the lowest common denominator is very low. Frequently encountered challenges such as the desire to generate a login (and/or email address) or being able to support a directory structure with multiple organizational units require customization of the connector.

Usually, it's the advent of the process automation via an identity manager tool such as OIM that forces the organization to articulate the rules for generating email addresses and logins for the first time. Inevitably, the newly-written requirements for the generation algorithm cover three pages and include a small mountain of special cases and advanced collision logic.

Warning #1: If you receive a simple, sensible set of written rules in the first place, the odds are good that the true (and extremely complex) requirements won't show up until the system is in production, which is not a fun experience.

One of the most complex issues in Active Directory implementations is figuring out where in the directory tree the user account should be placed. Typically, there's a series of organizational units (OUs) in AD that represent someone's idea of org hierarchy and one of these OUs should act as the bottom-level container for the user account. Occasionally, the AD org unit structure actually makes sense and the placement of the AD user object can be determined via a simple lookup algorithm that utilizes a single attribute from the core OIM user object, e.g.
the user's geographic location. A table in OIM database stores the mapping from the user's location to the org unit. However, this ideal state is rare and most of the time you'll find AD implementations with large numbers of org units arranged idiosyncratically (random walk anybody?)

Thus, the "simple lookup" table often grows to include hundreds or sometimes thousands of rows. In many cases you will also need more than one variable to determine the exact org unit. Enter multiple nested lookup tables or utilization of the rule and group engine of OIM. Now
you can configure OIM to locate users who work for the truck division, are located in the Raleigh office (location code) and work in Sales. You do this by going into the “truck division" branch of the org unit structure, then navigating to the bottom of US -> North Carolina -> Raleigh -> Sales org unit tree. Problem solved!

Unfortunately the problem is not solved. As it turns out, the company has two offices in Raleigh with the corresponding two org units that share the same office location code. It is also critical that the user gets put in the “right" org unit or he will have to drive 90 miles to another office to get his free company lunch. At the end of the day you will often discover that no matter how complex or sophisticated your rules (and their implementation in OIM) become for determining where the account will go in AD, they will not be able to solve this problem with 100% accuracy. In most cases, you'll need to accept that you'll be able to automatically place only 95-99% of the users. The rest will have to be done manually.

Regardless of which strategy you pick to deal with this issue, it is important to realize that the org unit structure won't stay static so your placement algorithm will also need to be flexible as the directory structure will change and change frequently. Sometimes the new structure will look nothing like the old structure (think mergers and acquisitions or a re-org, the latter being a way of life in some large companies). One way to make life less painful is to give each configuration entry a validFrom and a validTo value. This will make it possible to stage configuration changes ahead of time. Once you have dealt with the basic provisioning requirements you need to consider creation of email accounts and home directories. Each of these areas deserves an article of its own.

Now that you have a shiny new AD user provisioning system the next step is to handle all of the supporting use cases. First, you will need to disable user accounts to support cases such as employee termination. The AD connector makes the disable transaction very straightforward; the compensating enable (or re-enable) transaction is also easy.

Warning #2: Try very hard to convince your customer to implement the termination process by disabling the AD account rather than by deleting it permanently. As a best practice, you should always implement terminations as a reversible action. When someone or some process goes haywire and sends 5000 termination events to OIM by accident, you won't have to try to resurrect all those accounts from a backup and the IT managers won't use your name in one sentence together with many expletives. Instead, you will just have to re-enable the accounts and move them from the "disabled accounts" place in the directory to "live accounts" place. The move is still painful, but much less so than the alternative.

The best way to implement this is via a “disable and move to disabled org unit for a period of time" rule. The only downside of this rule is that the users who leave the company and later return may want their old accounts back. As the account still exists it is hard to refuse this
request (at least once the user figures out that their account still exists). At this point you'll have to create a process for re-enabling accounts which sounds straightforward but often turns out to be quite complex.

Users also have an unfortunate tendency to change their profile attributes by getting married or divorced. Alternatively the client rolls out the system where people tend to use a “preferred first name" rather than their legal name in email addresses and other identifiers. For example, let's say your Asia Pacific marketing director's legal name is “Chen Ai-li". This name flows from the HR system to OIM. But the director goes by “Holly Chen", so she wants “holly.chen@acme.com" as her email address is not the OIM-generated Ai-li.Chen@acme.com. You might think that you could just establish a “no email address changes allowed" policy, but that will only work until someone important wants to change his name.

Another approach is to allow the change to occur outside of OIM (e.g. in Active Directory) and reconcile the change into OIM but this only works if you allow the reconciliation process to update the profile in OIM. A third and best approach is to let the change flow down from the trusted source, such as your HR system. If you want to avoid having to argue the importance of using legal names in the HR system with the HR admins you can include "preferred firstname" and "preferred lastname" fields in the OIM user data model so that you can handle this without
having to change the legal names in HR.

Updating key AD attributes such as samaccountname so that it becomes based on the new name can be dangerous, because some of your downstream applications might depend on the samaccountname staying constant. The usual compromise is to change the
email address and the displayname while keeping the samaccountname unchanged.

If you cover all of these use cases, you'll be able to get accounts provisioned to AD at the snap of your fingers. At this point you certainly deserve a break. You might think that you are finally done but this is just the beginning. Tune in next time for a discussion of how to deal with reconciliation and basic provisioning of AD groups, including their membership.


Posted in Identity Management, Oracle Identity Manager    Tagged with active directory, provisioning, guests


1 Comments

Amit - May 20th, 2009 at 11:27 PM
A good post with clear understanding and helps us , atleast me , really a lot in understanding the organization behaviour :)

Leave a Comment
Search

Subscribe

follow on

2012 (1)
2011 (2)
2010 (2)
2009 (64)
March (11)
April (18)
May (18)
June (4)
July (1)
August (1)
September (5)
October (5)
December (1)