The other option is giving yourself rights to the HKLM\SOFTWARE\Novell\PwFilter\Data keys (and subordinates) on all DC's, then you'll see the independent user change keys (data encrypted, so will look like not much - including timestamp which I personally find a pain)....but if they get deleted prior to driver grabbing them, then it'll not sync....

The RL server stores the changes in HKLM\SOFTWARE\Novell\PassSync\Data for the driver to consume.

Also allows for you to monitor p/w sync from AD to eDir....

>>> ambradley<> 8/02/2014 11:54 AM >>>


Thanks for the replies. I was afraid that would be the answer - that I

can't get the password from AD as easily as I can from eDir.

These password changes were cached on the DCs for days, weeks, months -

as long as 18 months. From what I've read, prior to a fairly recent

version of the MAD driver, there was no timeout built into password

sync; those cached passwords stuck around forever.

The users changed their password in AD; when it didn't sync to

eDirectory they called the help desk, who changed it in eDirectory for

them, which synchronized to AD. All was good - except that original

password change was still stuck on the DC. When communication with the

RL finally worked (yesterday), they all came flooding in.

I understand what happened; unfortunately the damage was done very

quickly and all I could do was stop the driver as quickly as possible,

disable password sync from AD to eDir, and then let them process. About

400 didn't get through, so there's that...

Hindsight being 20/20 and all, if I had disabled password sync from AD

to eDir prior to my troubleshooting, none of those cached passwords

would have made it to eDirectory. Also, if I had used psexec to view the

registry of each DC as SYSTEM (there are less than a dozen DCs), I could

have seen which had cached passwords, and even removed them.

If it happens again, I'm prepared. :-)




ambradley's Profile:

View this thread: