With delegated logins, you need to return an array from ZAUTHENTICATE with all the properties you want the user to have, including their roles.   This happens during login; you can't change the roles once login is over.  The array used is Properties.  To set the roles in this array, you would do something similar to:

set Properties("Roles")="ACustomRole" 

This would set this user to have the role named ACustomRole.  

Your code gets to decide what that roles are, and can do it based on the group you retrieved.    For example, If you have a group named CacheAdmin and you want all members of that to get the %Manager role, you could do something like

if group="CacheAdmin" {set Properties("Roles")="%Manager"}

(Note that this code makes many assumptions that may not be true for you, such as that you want to overwrite Properties("Roles") instead of adding to it, and the name of the variable you're holding the group name in.)

If you want to add more than one role, you can use a comma separated string, such as "%Manager,ACustomRole"

The %Net.SSH.Session.SetTraceMask method tells a process to collect information about an SSH handshake and connection in a text file, which is useful for debugging SSH connections.  It is information about what the local process is doing and does not include network trace information, such as would be in a WireShark pcap file.  

If you're trying to collect information about an SFTP connection problem, you can use the same SetTraceMethod for the SSH session associated with your FTP connection to collect information.

If you're trying to collect information about an FTPS connection (meaning SSL is in use, not SSH), you can use the ^REDEBUG utility to log information about the SSL handshake to the cconsole.log.  You can enable the REDEBUG flags by running:

Do INTSET^REDEBUG("FFFFFFFF")

in the %SYS namespace.  Remember to set the flags back to "FF" when you're done testing, as the higher log level can generate a lot of data.

If you're trying to debug an un-secured FTP connection or these don't provide the information you want, you may need to use a network trace tool such as Wireshark.

I would suggest you contact the WRC about these questions.  

I usually find that connections may be delayed but do succeed after the "Failure Event: -37 - Unable to exchange encryption keys" messages, so I suspect there may be another issue here.

Using StartTLS (explicit mode) is the default for %Net.FtpSession.   (If you wanted to, you could turn explicit mode off by setting the LegacySSL parameter.)

Have you looked at the connection attempts with a network trace to see what's actually happening?  You might also find useful information by setting the network debug flags to FFFFFFFF via ^REDEBUG in the %SYS namespace, trying a connection, and checking the cconsole.log for information about the SSL configuration which was invoked.  

How would you secure and authenticate network access to the key?  This seems like a question you would want to have a reasonable answer for before considering sending a key over the network.

You might also want to look at the features in InterSystems IRIS data platform.  KMIP support was announced as one of the features in it.

There aren't enough details here for me to guess exactly what's going wrong, but I can suggest some debugging steps that might help make things clearer.

First, if you haven't already, enable auditing and the Protect,  Login and LoginFailure events.  Then try reproducing this and see whether any audit events were generated.  The data in these may make it clearer what's wrong.

Second, I'm not sure how you checked the ^ERRORS global, but if you haven't looked at the "application error log" in the portal (under System Operation > System Logs) I would recommend doing that.  That page lets you see all the namespaces with errors logged.

What you're describing is moving the location of an instance after installation.  It's not supported.  I've seen people do some pretty bad things to their systems by trying it, and would strongly recommend against it.  

You will need to either run the installer in the new path, or keep the paths the same.

I agree - that SOP sounds like you have an outside vendor acting as a CA.  If you're using a CA vendor that still only supports SHA-1, it may be worth considering looking for a new vendor.  Whether an internal or external CA makes sense for you long term can be a complicated question.  It's worth having a detailed internal discussion about what your security requirements are and what the risks and benefits of each case are before making that decision.  

If you want to look at a PEM-format certificate in order to see who it's signed by, you can run:

openssl x509 -in certificate-to-display.pem -noout -text

where certificate-to-display.pem is the name of the file you want to read.  This will display the certificate in a human-readable format.  The CA who signed the certificate will be listed in the Issuer field.  

I'm worried that you may be conflating several ideas here.   You said you need to sign your partner's certificate to do mutual authentication.  That's not required technically.  (Maybe it is required by policy for your particular organizations, but I didn't see you say that so I suspect it's not.)

A CA is a trusted party for verifying identities, usually a third party.  You don't need to sign your partner's certificates yourself to do mutual authentication.  That's the power of using a CA - you don't have to do identity verification and issue certificates for every possible connection partner, you trust the CA to do it for you.   

To use an analogy, if a certificate is a driver's license, then the CA is the state agency that issues licenses.  If you operate a service where you need to check identities of people, you don't need to start issuing your own licenses, you can just trust ones issued by states that you think 1) do a good job checking identities before giving out licenses and 2) you recognize and know how to tell if they're real.

To do mutual authentication, you need to have a certificate, and the other side needs to have a certificate.  Both certificates need to be signed by CAs the other side trusts - meaning your certificate needs to be signed by a CA that your partner trusts, and their certificate needs to be signed by a CA you trust.  

You can (and probably should) get your certificates for use in TLS connections with Ensemble/HealthShare through whatever processes you normally use for generating certificates.  

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.