Hash: SHA1

<quote commenter="wiseimpersonator">
If you trace it, solutions will come (TID# 100988620).

Good luck.

Will Schneider wrote:
>>> I know I have to figure out what to do with moveoperations.....currently thinking about just doing a remove
>>> associationon those and treating them as-if the user got deleted. As technically,they should be rare (as long as I'm
>>> in command of this network). Butthere's no telling what future sysadmins will do to it. Should Ifact-check for them?

> I maintain an attribute in the eDir that is the DN of the object in my AD. Can't remember why it is there and I don't really use it, but it could be a nice to have for reporting or roles. It could allow you to base AD group membership on containment to allow permissions based on OU like in eDir I suppose. If you have no need though, then I wouldn't bother.
> Remember that in AD, the driver doesn't know the difference between a move and a rename. So for each, both are generated and you have to figure out which one is actually happening. You should be able to set back the naming attributes just by writing them back. Watch out for single valued attributes though I think there are some there.
> I also suggest making CN = UID if you are not already doing that and using UID as your naming attribute in your eDirectory.
> If you can't force back the SN etc. then post a trace of that and we'll figure it out.
>>> My test case is pretty much synchronizing a single user object from atest OU in eDirectory to a test OU in AD, and >>
>>> then doing differentthings to that User object. If I did it right, I expected that achange to First or Last Name in
>>> AD would get replaced by originalvalues from eDirectory with ~30secs (which is what happens whensAMAccountName or
>>> userPrincipalName change), but so far, this hasn'tbeen the case.

> It will take as long as your remote loader is set to poll the AD Change log. Make sure you have these attributes set to at least notify on the filter for the publisher channel or you won't get them.
>>>> what other changes might one do to make eDirectory thesingle, unwavering, authoritative source for User objects in AD?

> Create all your users in an OU structure in AD that has a single parent OU under the directory root and remove admin access to that OU. Specify only the few people you trust. In order to accomplish this, you will need to provide an alternative to the way they are modifying now, but that is a political issue as opposed to a technical one (iManager comes to mind with RBAC)

Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org