An unbindrequest basically puts the connection back to an unauthenticated state.
I have not figured out what code (3) is, but these are usually constraints put on the connection by the LDAP Server/Domain controller.
When I searched our database of cases for "unbindrequest", I found nothing with a 3 or (3) after it, and plain unbindrequest found things such as
"Are you sure that they are using a user that has permission to this level of the tree?"
This brings up issues of scope of the identity source, what is your base DN and what are your user and group search filters. Or this could be a Cert or Cipher issue.
You options are to continue to try some hit or miss tactics;
1. Flush cache in Ops Console
2. Reboot the AM server to ensure all cached items are cleared
I do not foresee us figuring this out by chatting, Support needs to see the WireShark trace, because there could be several reasons for this, inclucing intermittent connectivity and firewall blockage. We may need some verbose logs when this happens too, but check with your TSE when you open the case.
You said the LDAP account password is set to never expire, has it always been set that way or was it changed then set to never expire. This brings us back to Ed's original thought, that an old LDAP password is cached. So try flush Cache in Ops console, then try reboot, then if necessary open a support case. Regards,
