(I've spend some time in this forum and elsewhere looking for some
answers and haven't found them yet. Please point me to them if I
missed them.)

I have two test trees, Tree1 and Tree2, in vmware on separate PCs.
Using the sample eDir driver, goal #1 is to sync OU, Group and User
objects one-way from Tree1 to Tree2. Goal #2, in concert with goal #1,
is to sync (distribution) passwords in both directions. Goal #3,
outside the scope of IDM is to copy user data volumes from Tree1 to
Tree2 and have users access those volumes as they did under Tree1.

Goal #1 achieved. Goal #2 only 50% - passwords sync from Tree1 to
Tree2 when adding users or when user changes password, but same actions
on Tree2 do not cause sync back from Tree2 to Tree1. No dstrace entries
appear on either tree for these non-events in Tree2.

Why will password sync go in one direction but not the other? I've
found tidbits in this forum that I've tried to implement but still
can't get it to work. My config is below and four questions.


Both trees are configured the same way...
- single server Netware 6.5 SP6
- eDir 8.7.3.9
- Security Services 2.0.5 installed
- IDM 3.5.1 with plug-ins for iManager 2.6
- password policy in place
- enable Universal Password = true
- sync NDS to UP = true
- sync Distribution to UP = true
- sync Simple to UP = true
- allow user to retrieve = true
- allow admin to retrieve = true
- allow user to initiate change = true
- no limiting settings on password content
- policy directly assigned to OUs containing users and groups
(no sub-OUs in those)
- SSL certs created/signed with Tree2
- Tree1 trusts Tree2's CA

Using Designer 2.1...
- created a vault, driver-set on each tree
- ran "configuration wizard" when creating each eDir driver with
sample driver
- Tree1 = authoritative
- Tree2 = subordinate

Both eDir drivers have...
- placement = mirrored
- same base container in each tree, as they have exactly the same
structure
- password sync version = 2.0
- all default policies that came with sample driver, unmodified
- modified filter (following changes are the same in each driver)
- removed class "Country"
- removed class "Organization"
- added Group attribute "member"
- added user attribute "private key", pub = ignore, sub =
ignore
- added user attribute "public key", pub = ignore, sub =
ignore
- password synchronization
- IDM accepts passwords (pub) = true
- use Distribution Password for sync = true
- always accept the password = true
- application accepts passwords (sub) = true
- notify user of password sync failure via e-mail = false
- logging = use settings in driver set
- driver set: log specific events = all checked
- trace level = use settings in driver set
- driver set: trace level = 5

Unique settings in filter...
- Tree1 (supposed to be authoritative)
- each class and all attributes (exceptions following)
including "GUID"
- pub = ignore
- sub = sync
- merge authority = IDV
- exception: attribute "nspmDistributionPassword"
- pub = ignore
- sub = notify
- merge authority = IDV
- exception: attribute "Private Key"
- pub = ignore
- sub = ignore
- merge authority = default
- exception: attribute "Public Key"
- pub = ignore
- sub = ignore
- merge authority = default
- Tree2 (supposed to be subordinate)
- each class and all attributes (exceptions following)
including "GUID"
- pub = sync
- sub = ignore
- merge authority = Application
- exception: attribute "nspmDistributionPassword"
- pub = ignore
- sub = notify
- merge authority = IDV
- exception: attribute "Private Key"
- pub = ignore
- sub = ignore
- merge authority = default
- exception: attribute "Public Key"
- pub = ignore
- sub = ignore
- merge authority = default

Testing with...
- Novell Client 4.91 sp4 in Windows host for each vm
- test user login
- test user change password
- DSTRACE on each server = only +auth, +dxml, +dvrs


Phew... now for my questions if you’ve made it this far:

1. You may be wondering why am I syncing the GUID?
Everybody here says never sync the GUID. I think I understand.
However, my intent is to move a single business unit from a large tree
into its own tree without modifying the original large tree. (I found
a CoolSolution on cutting a branch off a tree but it looked invasive to
the original tree with no go-back). This will be a one time cut over
then this IDM implementation will be shut down.

My current belief is that NSS volume ACLs reference trustees via their
GUID. So I'm syncing the GUIDs from Tree1 to Tree2 to ensure all
trustee assignments remain in place after users and data are moved to
the new tree.

Any problem with this?


2. What settings go directly on each User class (not it's attributes)
for bi-directional password sync to work?
TID 3650562 (2007-05-30), point #12 seems to say "sub = notify" on
attribute "nspmDistributionPassword" won't work unless you also put
"sub = sync" on User class itself.

When I do this on Tree1 (authoritative), the driver starts successfully
and objects and passwords sync across to Tree1 as happened without this
setting.

When I do this on both Tree1 and Tree2, the driver on Tree2 fails to
start with an error which I can't find anyone talking about: "All
classes in the filter must include the 'GUID' attribute". As decribed
abive in my config, the GUID has been included for the three classes
I’m syncing. I can post trace segment if needed.

If I leave Tree1 with the above setting but change "sub = sync" on User
class itself for Tree2 back to "sub = ignore" the driver on Tree2 starts
fine again.


3. Settings for attribute "nspmDistributionPassword"?
Please confirm that for BOTH trees: pub must = ignore, sub must =
notify, even though all other attributes on Tree2 are: pub = sync, sub
= ignore.

I've read several posts from Father Ramon that seem to say password
attributes are not actually handled via the filter (like all other
attributes) and setting "nspmDistributionPassword" sub = notify
triggers the actual password sync machinery. He says Subscriber
Command Transformation Policies do the real work for password sync.

Also, several helpers have posted that sub = sync can work. But FR
says it must be "notify" not "sync" to ensure that after the filter,
the right data is in the right place (or will be removed?) during rules
processing in the "Subscriber Command Transformation Policies".


4. What is the most (reasonable) detailed trace level / DSTRACE config
for IDM troubleshooting?
All posts I've come across say to set trace = 3 but IDM 351 admin guide
says to use trace = 5 and DSTRACE +auth +dxml +dvrs for
troubleshooting.


Thanks in advance.


--
daryle
------------------------------------------------------------------------
daryle's Profile: http://forums.novell.com/member.php?userid=1202
View this thread: http://forums.novell.com/showthread.php?t=301825