• State Verified Answer
  • Locked Locked
  • Replies 13 replies
  • Subscribers 92 subscribers
  • Views 14035 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Password Capture Agent 7.0 , windows 2012 domain , "the passed password is not a string"

CVU
over 7 years ago

Hi there, 

I have Password Capture Agent 7.0 installed on a 2012 2-controller windows domain. So far it's working flawlessly on one of the DC. The other, however, shows the following message when any logged user changes the password:

"PasswordChangeNotify()-Thread (1140): The Job for this Password-change Username="xxxx" UserRid="NNNNN" was ignored because the passed password is not a string."

Any ideas?

Parents
  • 0 over 7 years ago

    Solved. It's a two legged problem.

    1.- Google password sync service (GAPS) is used to sync windows passwords with Google Apps accounts. It does "touch" the password somehow, so if other password hooks are installed (such as Identity1's) they'll get a corrupted string and won't proceed. As a workaround, in "HKLM\System\CurrentControlSet\Control\LSA\Notification Packages", Google's dll must appear on top of the list.

    2.- 389ds (Redhat directory server) also installs and registers its own password hook in Notification Packages. But instead of adding itself , it overwrites everything in the registry entry. Same when it is uninstalled: It clears the registry value.

    All in all, be careful when installing Password Capture Agent if you have either of these too. Hopefully once I have my Identity1 background fully operative I'll be able to get rid of both Google's and Redhat's.

    Thanks, Markus, for pointing me out in the right direction.
    Regards!

Reply
  • 0 over 7 years ago

    Solved. It's a two legged problem.

    1.- Google password sync service (GAPS) is used to sync windows passwords with Google Apps accounts. It does "touch" the password somehow, so if other password hooks are installed (such as Identity1's) they'll get a corrupted string and won't proceed. As a workaround, in "HKLM\System\CurrentControlSet\Control\LSA\Notification Packages", Google's dll must appear on top of the list.

    2.- 389ds (Redhat directory server) also installs and registers its own password hook in Notification Packages. But instead of adding itself , it overwrites everything in the registry entry. Same when it is uninstalled: It clears the registry value.

    All in all, be careful when installing Password Capture Agent if you have either of these too. Hopefully once I have my Identity1 background fully operative I'll be able to get rid of both Google's and Redhat's.

    Thanks, Markus, for pointing me out in the right direction.
    Regards!

Children
No Data