SSL support in Healthshare uses the OpenSSL library.  Which version of the library you have will depend on your exact maintenance kit.  For example: 2016.1.0 has openssl 1.0.1p, 2016.1.1 has 1.0.1t, and 2016.1.2 has 1.0.2h.

You can see which ciphers your version supports by running the following command in the bin directory of your install:

./openssl ciphers ALL

On my install of 2016.1.0 the first cipher listed when I do this is ECDHE-RSA-AES256-GCM-SHA384, which is on your list of preferred ciphers.

If adding less secure ciphers to the list in Healthshare is making your connection work, then I suspect the problem is in the ciphers the other side supports.  You could try to confirm or deny this by looking at the SSL handshake with a tool like Wireshark.

That error looks like the CSP gateway can't log in to the Cache instance.  The CSP gateway needs to log in in order to serve the portal login page to you.  Given that you disabled all the other users, I'd guess you've disabled the user the CSP gateway is trying to log in as.  

You can figure out which user this is by enabling auditing of LoginFailure events, then trying to load the page again, and checking the audit log to see which user failed to log in.  (All of this can be done with ^SECURITY.)  Alternatively, the most likely user for the gateway to be running as is CSPSystem, so you could try enabling that user and see if it fixes the problem.

That error probably means there's a problem on the TCP level or with the SSL handshake, not in the SOAP request.  I'd recommend doing:

%SYS> d ^REDEBUG

and setting the value to FFFFFFFF, then reproducing the problem.  This will log information which should help in the cconsole.log.  

Remember to run the utility again to set the debug level back to FF once you're done, since the higher debugging level puts a lot of entries into the log.

There are a couple of things you could be doing here, so let me make sure I understand what you're trying to do.  Are you trying to configure LDAP authentication so that users who log into Ensemble will authenticate against the LDAP server, based on the settings in the System Administration > Security > System Settings > LDAP options ?

If so:

What error do you get when you try to log in?

Have you tried the "Test LDAP authentication" option in ^SECURITY?  This may give you more details of what's failing.  (It's under 12) System parameter setup, then 3) Edit LDAP options )

Are you using the "Use LDAP Groups for Roles/Routine/Namespace" option?  I'm guessing not, since you said you added IntersystemsAccount to the schema, but want to check because you also mentioned groups.  (You may not have this option on some older versions.)

This error is most often due to the TCP connection going away without the adaptor realizing it.  If the problem is a network issue, the error may go away once that's resolved.  If StayConnected is set to a large value (or -1), it may also help to set it to a small, positive value (such as 5 or 10).  This value controls how many seconds of idle time the adaptor allows.  If it's currently higher than one of the TCP timeouts in your connection, that could account for the error.

Aline has a good description of why this happens.  I wanted to say what it means, in case the effects are not obvious.  

This error means that your database isn't transactionally consistent.  Transactions have several properties.  One is that  either none or all of their updates will happen.  Another is that no one will be able to see a situation where some, but not all, of the updates have been completed.  This error is saying that a process was able to change part of these updates while the transaction was being worked on, and therefore we weren't able to safely return to having none of the updates happen.  

 To put this in an example:  pretend you're doing a bank transfer.  You're taking $100 from account A and putting it in account B.  You don't want the $100 to disappear (be removed from A and not added to B) or an extra $100 to be generated (not be removed from A and be added to B.)  This error is saying that one of those situations where money was created or destroyed probably happened.

To prevent this in the future, you'd want to look into whether there are missing locks in the code the processes involved are running.

I think you may be looking at the wrong class documentation.  

There are two LDAP classes - %Net.LDAP.Client and %SYS.LDAP.  The EnsLib.LDAP.OutboundAdapter is written using %Net.LDAP.Client.Session, which does not have a Binds method.  The %SYS.LDAP class does have a Binds method, and discusses wanting a $lb like you've described.

I want to second Ben's advice to contact the WRC.  

I also want to add, for anyone reading this later, that moving the CACHE.WIJ file (as suggested in the error above) is an extremely dangerous operation.  Please don't ever do this without contacting the WRC.  Moving the WIJ can lead to data integrity problems which may or may not be obvious.  There are almost always other ways to start the system.