Identity Manager Questions

Wed Nov 5 20:13:33 GMT 2008

Does anyone know if you can build a policy to replicate based upon group-membership? I could create a group called AD-Replicate (or whatever), and assign users to that group?

Thank you,

Scott Etienne
Network Engineer
Enesco, LLC
setienne at enesco.com 

>>> "Randy Grein" <RGrein at tpchd.org> 11/5/2008 2:09 PM >>>
Yup. Funny how hard it is to describe a description field. (grin)

Randy Grein
Sr. Network Engineer

>>> "Scott Etienne" <setienne at enesco.com> 11/5/2008 12:01 PM >>>
When you say description label, are you talking about the description field inside the group objects?

>>> "Randy Grein" <RGrein at tpchd.org> 11/5/2008 1:57 PM >>>
A couple of issues come up:

Extraneous users that have to be locked down (disabled in AD), a security issue
Extra objects that get in the way on a daily basis
'messy', relevant mostly if you're a neat freak

We went through this last spring, and the selected solution was to select user folders for replication, move service accounts that should not be replicated and mark groups to import with a description  label - so any groups we wanted were given a description of IDMSYNC. Not my idea, but it seems to work well enough.

Randy Grein
Sr. Network Engineer

>>> "Scott Etienne" <setienne at enesco.com> 11/5/2008 11:45 AM >>>
I just created a driver to replicate nearly our entire tree, and it wants me to pick exclusions. Thinking about it, it seems like I have a lot to exclude. There are service accounts and some admin equivalents. 

Should I create seperate drivers that point to just targeted containers for replication? 

If I should do this, then I still have a problem with a major container that has many regular user accounts, service accounts and Admin accounts. I am not sure I would want to change my edirectory structure to segregate objects. 

What are the ramifications of having admin/service account objects replicated? Sounds like it replicates admin rights with the admin user accounts over to AD, so that the Admin objects from eDir now have some or all admin rights in AD?

>>> "Bill Brush" <bbrush at gmail.com> 11/5/2008 12:11 PM >>>
IDM just happens to be something I have worked with quite a bit.

On Wed, Nov 5, 2008 at 11:55 AM, Scott Etienne <setienne at enesco.com> wrote:
> We want to setup IDM3.5.1 to sync passwords between eDir and AD, and maybe automate account creation from eDir to AD. I have created a CN in AD named after our tree, and have constructed a duplicate structure of the first ou we want to synch. I have a simple goal in mind, but when I try to understand the parts of what's going on, I come out with more questions.
>

Manually creating the mirrored tree really isn't necessary, the driver
can do it.

> The planning guide is recommending a separate instance of eDirectory for identity vault, a test instance to better get acquainted with the way things work, etc. My boss just wants be to just get it done--with a very specific requirement here. Is IDM so complex and nebulas that I have to immerse myself in it first, before I can engage a limited deployment?
>

Ok, the meta-directory recommendation stems from the expectation that
you'll want to be able to control where and how the data is propagated
by the drivers.  In a small, simple installation it is an unnecessary
added complexity.  I have been running IDM for years with just my
single eDir as the identity vault.

> Specific questions I have include, if I need to later, can't I create a separate instance of eDir for a "vault," if it is found that I really need to do that, and if not, then why?

Re-doing to the drivers to point to a separate meta-Directory is
possible, and I've considered doing it in my case since I'm getting a
lot of AD's, but it will be labor intensive.  Still for a "Get me up
and running" situation I wouldn't bother trying to get a
meta-directory going as the eDir to eDir driver is about the most
annoying to get working.

>
> Another question I have is can I link accounts in multiple edirectory ou's with one policy, driver and driver set? And, if not, which piece of the puzzle handles separate containers?
>

For the AD driver you assign a root container in each directory and
the driver will handle the object matching in the container and
sub-containers.  If you want two OU's on the same level to be but not
other OU's on that level, you'd need a separate driver for each OU,
UNLESS you use entitlements to control who gets synced and who
doesn't.  I would encourage you to use them as they can help you
control the flow.  Entitlements in the docs are this amorphous concept
that's never really explained, but basically it's just a fancy way of
flagging an object as "ok to sync."  No entitlement, it doesn't go.
If it has the entitlement, it goes.  Off or on, simple enough.

I have something like 4 AD drivers running right now, and a single
eDir, not to mention having done dozens of test cases, so I'm fairly
familiar with the AD driver, feel free to ask questions.

Bill
_______________________________________________
Novell mailing list
Novell at netlab1.oucs.ox.ac.uk 
http://netlab1.usu.edu/mailman/listinfo/novell 
_______________________________________________
Novell mailing list
Novell at netlab1.oucs.ox.ac.uk 
http://netlab1.usu.edu/mailman/listinfo/novell 
*************************************************************************************
This e-mail and any attachments may contain confidential and privileged information. It has been scanned for viruses. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this e-mail and destroy any copies. Any dissemination, use, review, disclosure, or distribution of this information by a person other than the intended recipient is unauthorized and may be illegal.
**************************************************************************************

_______________________________________________
Novell mailing list
Novell at netlab1.oucs.ox.ac.uk 
http://netlab1.usu.edu/mailman/listinfo/novell 
_______________________________________________
Novell mailing list
Novell at netlab1.oucs.ox.ac.uk 
http://netlab1.usu.edu/mailman/listinfo/novell 
*************************************************************************************
This e-mail and any attachments may contain confidential and privileged information. It has been scanned for viruses. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this e-mail and destroy any copies. Any dissemination, use, review, disclosure, or distribution of this information by a person other than the intended recipient is unauthorized and may be illegal.
**************************************************************************************

_______________________________________________
Novell mailing list
Novell at netlab1.oucs.ox.ac.uk 
http://netlab1.usu.edu/mailman/listinfo/novell