Last time I wrote an article about changing passwords for LDAP users (mainly referring to the other two articles), I noticed a strange phenomenon. The AD server I developed and used is three in one with my own WEB server and certificate server. The password can be successfully changed as described above. The program was packaged into a WAR package and tested on the servers on the 6th floor, 15th floor and 16th floor. They both used a single AD, WEB server and certificate server in one. Both the 6th and 15th floors could normally change the user password of the CONNECTED AD, but the 16th floor did not work. The IP:636 error of simple Bind failed AD was reported all the time, which depressed me very much. Had to search on the net, in the middle because of other task intermittent for a period of time, looked for a few weeks on and off, there is no enable SSL, there is said to be “do not support SSL”, there is said to be your simple binding error (this is nonsense), is not a definite answer. Join several communication groups of LDAP, waffled for a long time, also no solution. During this period, the AD configured by the WEB application on the 15th floor was replaced by another one, but this error also occurred. I found another machine to configure again, but the same error occurred. Xj installed WIN2003 machine, let me test, the same mistake, original WEB applications can be installed on your machine normal change passwords, then even sometimes can’t change, can change sometimes, fifteenth floor originally that one cannot change the password, suddenly can change the password again yesterday afternoon, I asked others, making sure that no one is changed AD or WEB set, same application, the same configuration, perform the same function, can downs about it, that day is my most depressing day. This morning on a sudden impulse, the certificate again guided, the result changed the password successfully. Steps (omit the installation of the certificate service, see the previous section) : 1. Select “Start -& GT; “Run”, enter MMC, enter the console, select “Add Certificate Management Unit” menu item, as before, select “Personal -& GT; After “Certificates”, select the certificate you previously created in the Certificate Services section, and then “All Tasks -& GT; Export “, re-export to a new CER file, and then “start-run-& gt; CMD “into the console, use the CD command to switch to the WEB application under JDK bin directory, enter the command:” the keytool – import – keystore certificate. The keystore file – cer file path “, and to import a new certificate, when we enter the JDK bin directory to be able to see your new name the name extension keystore file, and then set the change password when the certificate path of change to just generate the certificate file path. After restarting the server, test the password change function again, and you’re done. Then I followed suit and did the same on the 14 machine, and the 14 machine was able to change the password successfully. Is too great. I don’t know if this is the exact solution to the simple Bind failure (or did it just happen to cause me to change a setting on my system?). But if any of your brothers have the same problem, try reimporting the certificate and you might be able to fix the problem.