Placement of External Users in IDM
Novell Cool Solutions: Feature
Digg This -
Posted: 22 Nov 2006
A Forum reader recently asked:
"We have two eDirectory trees. One is a production (File/Print/ZEN/Gwise) tree that is currently the authoratative source for our users. This tree syncs bidrectionally to an Identity Vault, which in turn syncs to AD and another LDAP server.
Now, let's say that we want to have a lot of "external" users (ie, people that do NOT work for us and aren't exactly a trusted partner). Should we create a new spot in the Production tree (which is hierearchical) and plop the users in there, so we have one place we can manage the accounts? Or should we plop them into a brand new O=BLAH in the Identity Vault, and then have two places to do administration - a "production" tree for regular users and Vault for "special" users?
And here are a few responses ...
It is more a design issue than an implementation issue. We are running into the same issues here. This is what we did:
Regular users are created in the Production tree. External users are created in the LDAP tree. I set an aux attribute on the User that basically says whether the account is Internal or External. If the account is Internal (created in the Production tree), I allow the account to go to the Vault and the LDAP tree. If the account is External (created in the LDAP tree), I allow the account to go to the Vault, but it gets vetoed by the Creation Policy on the Production tree.
It does required multiple administration points, but it keeps your "untrusted users" from gaining access to your Production tree.
In my opinion, the correct direction is to establish (as you have) an Identity Vault separate from your F&P tree.
Then, migrate your administration of IDENTITY to that vault. You may still have to deliver services directly out of the F&P tree - you may still have to allocate file rights, etc. - but the "best practice" is an evolution toward an IDENTITY vault that supports service-delivering connected systems.
It is my experience that getting people to make the leap from the "old" model (in which identity and services are co-mingled out of historical fact, tech-evolution, and political decisions) to the "new" model (Identity Management as core infrastructure underlying the delivery of services) is a very difficult change of mindset. For those familiar with Netware, it's the same "mind-shift" admins were forced to undergo moving from Bindery services to Directory Services - "No, really, you DON'T need to maintain an account on every server!" The parallel now is, "No, really, you DON'T need to do all administration out of AD just because that's where you build home directories."
With that said, my recommended approach to your situation would be to manage external users in the Identity vault. A separate structure for external users like an "O" makes sense, as might extending schema to put a flag on "external" users, allowing you to leave all User ID's in a single container. Propagate their ID's as needed into other connected systems, depending on the service they require.
How? This gets into the arena of role-based administration. At the root of this proposition is the assumption that you can take the time, on paper, to thoroughly define data categories, user types, services delivered, etc. That way, you can build the necessary entitlements, custom schema, groups, or whatever other mechanisms you use to allow your drivers to do role- based management of access to systems and services being delivered from the connected systems.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com