IDM Best Practices: The Tree Structure of an Identity Vault



By: dvandermaas

November 21, 2008 4:48 pm

Reads: 354

Comments:5

Rating:0

Being consultants, normally, when we start to design an IDM solution, we advise our customers on tree structures, naming conventions, object placements etc.

But we only advise them! We do not tell them how to do it. If a customer wants to have a different setup or naming convention, fine with us. We do not want to be mixed up in the big discussion that might arise. Let the customer decide!

From an IDM perspective this attitude will only result in more or less work in building transitions. And that should be the main focus as an consultant. Let the customer know how many extra transitions will need to be programmed and tell them the impact on the maintenance.

There are however a few design issues in every design that you do want to discuss. These are the issues that will make live as a programmer more easy and from which the customer will benefit a lot.

One of them is the global structure of an Identity Vault tree.

Another is the use of “support” drivers with added functionality, I’ll cover that in another article.

When I teach the IDM ATT’s I’ll always start a discussion on this, it ends up with a lot of ideas. My idea was to write an article on this because everybody deals with this.

Let’s look at the basics, What are the goals for the identity Vault tree:

  1. It should be fast.
  2. It should contain any information on entities as is needed.
  3. It should be scalable.

And of course many more!

For 99% the Identity Vault is a flat tree, there are containers for all active users, devices, groups organizational objects etc, and last but not least inactive objects. (we want to maintain them for a short or longer period)

These objects will be spread over different containers for performance reasons in most enterprise environments.

The discussion I want to start in this article handles the placement of active and inactive objects because we see some customers getting into problems with this.

Again: For a number of reasons most companies leave their inactive users within the IV and delete them only after a certain amount of time.

But, at the same time there are two important features for this inactive users.

  1. They are not supposed to show up in address books etc.
  2. They must not be able to login.

So, the following picture (remember DS Designer) is from a typical Identity Vault tree structure (even in the IDM ATT’s)
setup1.jpg

The client for a Identity Vault systems are mostly LDAP clients, so think LDAP for a minute!

Let’s review this from an LDAP perspective, because we use this perspective a lot in authentication, authorization and directory searches etc, and even part of the User Application

A nice issue arises when using this design:

  1. What would the baseDN be when selecting active users? Normally you would say cn=Active,ou=Users,o=Vault.

    But… Most LDAP clients use one baseDN for all queries, so with this baseDN we miss out on the active groups and others. Even if you’re not using these info right now, it might be used in the future for authorization purpose.

    So let’s change the baseDN to o=Vault.

    But… In this case I would also see the inactive users in a yellow page application!!

Another issue:

If you set the baseDN to o=Vault the inactive users might even be able to login. Of course we can set Login disabled, but that is an extra action to take.
And there are more.

Conclusion:

With a design like this you might end up doing a lot of coding to make sure that the system will act as desired.

So using a different approach on the tree structure might prevent a lot of work.

First a important note! We have a saying in the Netherlands: “There are several roads leading to Rome” (which is in Italy ;-) ). So what I propose is only one way to do it, it is not the law and there are several pro’s and con’s.

This is the structure most commonly used by our consultants.

The design is based on some important principles:

  1. A logical separation between fields of functionality.
  2. An active link between user objects and his/her relation to the company (One User = One Entity with One or more roles in One or more departments.)

This participles will result in a tree design with one container with all active items (Users, Groups, devices, SAP object (if any)).

Another container as a placeholder for objects that regard IDM issues (inactive users, workorders if any)

And one or more container for Servers, services (Driver-set) and tree administration.

Note! For all kinds of reasons, it is mostly not a wise idea to use several Organizations.

So these principles could result in a tree design like the following :
setup2.jpg

Again, there are several way to reach your goals.

There are some other big advantages with parts of this design.

  1. The only rules that need to be build is something like : Delete, disable or veto account when moved to inactive.
  2. The baseDN can be set on ou=resources,o=corp and only active entities will be found for authentication, authorization or directory queries.

    Main focus is that you got a better separation on different types of object to prevent interference

Most important, of course, is to think ahead. What will the future be for our Identity Management system. If you thought that over in the design, you’re half way there.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Tags: ,
Categories: Identity Manager, Technical Solutions

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

5 Comments

  1. By:Anonymous

    I have mixed feelings about having a separate context for inactive users in the IDV. Sometimes a user changes status rather than becomes genuinely inactive (pending deletion)

    Consider an FE student. When students graduate, they become Alumni. It may be applicable to disable their account in the campus directory but you may want them to be able to authenticate to a college ‘portal’ with alumni content such as post graduate courses, events and so on. Perhaps a status attribute is more applicable.

    Also if you are checking for uniqueness in vault when creating new accounts, it is going to be better to have all the user objects in a single context perhaps.

    • By:dvandermaas

      Good thinking!
      First, i would definitely include the inactive user in search for a unique cn. Users might become active after a while.
      Secondly, The idea behind this setup is to exclude users from a baseDN without having to put a lot of policies or checking attributes. That’s why the separate container.

      As i described this is just a way to do it, there are more…
      In the case you describe you will need to reconsider the setup because you have several stages of employee status. So active, alumni and inactive (pending deletion) should be handled differently. This can be the starting point and you should adjust is to your specific environment.

      Grtz

  2. By:byelaw

    I too have an issue with different OU’s for the state of a user (e.g. Disabled or not). In fact, I try to avoid the situation where I would need to move the user object at all, for performance reasons etc.

    I would suggest an attribute instead that had the status of the object and filtered on that if need be. From a driver perspective, checking the Source DN is actually a little more combersome than checking an attribute value (although, I grant you not much more combersome).

    I try not to connect any LDAP clients to the vault, I recommend against that and if they need the User App installing into the IDV it can be easily configured to filter users on their attributes.

  3. By:dvandermaas

    First of all, the proposed structure is just a proposal, it will definitely not fit all IDM projects.

    About connecting with LDAP to the IDV.
    Limiting access to the IDV is generally a good idea, sometimes you will need it. We use this setup in enterprise environments and mostly LDAP is used in some form of authentication (SAP, web pages, portal, Radius, VPN, wlan etc) It is common in these environment. We normally don’t use the IDV but we mirror this to an Security Tree or authentication tree or whatever name is used. Within this tree there is only a limited amount of attributes available.

    About performance and moves
    This should not be an issue. If the performance drops down … add hardware. You will want to keep a stable so if moves are degrading a setup you are already pushing the limits. Most of our IDM projects start from a business level so we just budget in enough hardware, IDM is important to the business so they will to support this.
    From a technical point of view : make sure moves are handled correctly, build a check in the driver that handles the move. A nice example on how to do this is within the resource kit.

    Attributes
    A lot of “original” IDM solutions work like that. And the attributes used is “Login Disabled, employeeStatus etc” No problem with that. However you will still need to find a solution for external authentication.
    Two examples : 1) A lot of companies use a LDAP tree for internal yellow pages or app authentication (SAP Portals SugarCRM etc), . You will need to tell the web developers when to check where, which can be a burden. Sometimes this is not even possible.

    Think about Access Manager. In this way you will need one role (active users) when using an attrib you will need to have to (user AND a attrubute)

    2) If the IV or SV are used for authentication. you will miss out rule , the dn of the user, so if they want to do unautherised stuff they only need to reset an attribute.
    Lately we also found out that monitoring with Sentinel is much easier this way.

    Again the structure i propose is just one way to do it as long as you think your own solution thru.
    We have one customer with a millon user tree (a city) and we use this structure in their solution on the right hardware. And they are very happy with it

  4. By:byelaw

    I did realise it was a proposal, so sorry if my comments appeared a little blunt.

    Thanks for your answers, I will certainly look at the resource kit for the move handling.

Comment