I'm migrating to Universal Password here, with IDM35 doing password sync
between two eDir trees (hierarchical, vault). Overall, it's going pretty
well, but not perfectly. I'm getting sporadic errors showing up [0] here
in the trace that look like:

DirXML Log Event -------------------
Driver: \NIU-FLAT\NIU\DirXML\DS1\eDirDriver-StudentNode5
Channel: Publisher
Object: \NIU\NIU\Students\5\Z134225 (NIU\Users\Z134225)
Status: Warning
Message: Code(-8021) Unable to set NMAS password, -1416 UNKNOWN
ERROR.

The trace ahead of this looks ok, I see the <modify-password> event come
in, get converted to a <modify> of nspmDistributionPassword, and etc..
It gets all the way down to the point of actually setting the password
via NMAS, and it gets this error. The error propogates back, then IDM
goes in to a spin loop doing this change over and over and over again,
really quickly.

So, doing some research first, -1614 is a NICI error. The TID on SDI
says that this is likely to be a key problem. But the output from
SDIDIAG doesn't seeem to support that conclusion:

Server : .NIUSYNC-NDS.NIU.NIU-FLAT.
SDKey : 1
Object Class : Secret Key
Key Size : 168 bits
Key Usage : 0x4400C0
Key Format : DES-EDE3-CBC-IV8
Key Id : BC 67 18 7A 4E DD 13 D4 F9 47 E7 CD 72 6E 2D 80
Validity : Sun Sep 30 15:20:10 2006 - Sun Feb 03 23:59:00 2036
Server : .SYNC1.NIU.NIU-FLAT.
SDKey : 1
Object Class : Secret Key
Key Size : 168 bits
Key Usage : 0x4400C0
Key Format : DES-EDE3-CBC-IV8
Key Id : BC 67 18 7A 4E DD 13 D4 F9 47 E7 CD 72 6E 2D 80
Validity : Sun Sep 30 15:20:10 2006 - Sun Feb 03 23:59:00 2036

The keys look ok to me. Using SDIDIAG/CHECK doesn't seem to show any
problems either.

This is a two server tree. Both are eDir 8.7.3.9, with SS204. One server
is SLES9, the other is Win32. IDM35(FTF) is the engine version. That's
pretty much the latest and greatest of everything.

And it's not happening on all, just a relative handful of users. So far,
the only way I've been able to get the spin loop to stop is to use
RMUPWD to nuke the UP for the user, but that's kind of ugly and I'd
rather not be having to do that.

So far, I haven't turned up any reasons for this to be happening, at
least not any that seem to match what I have here, nor any ways to make
it stop happening.


[0] Two or three a day, not a lot, but enough that I can see it
happening if I'm watching for it. Watching, in this case, means that I
have all of my drivers running with trace level = 3 and trace to file,
and when this starts, I can see the file start jumping by 100s of KB per
second.


---------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu

I'm tired of receiving rubbish in my mailbox, so the E-mail address is
munged to foil the junkmail bots. Humans will figure it out on their own.