The two places that I would look for more information on a <PROTECT> error are the audit log and the line of code the error is coming from.   The audit entry for a <PROTECT> error sometimes has more information about why the error was generated.  The line of code can also help as it can show you whether there was an explicit permission check, a reference to a particular global, etc.

For <PROTECT> errors, if you turn on auditing of protect errors, the audit log will often have more information about the exact place the error comes from.   To do this, you will need to enable auditing system-wide via either the portal or ^SECURITY, make sure that auditing for the specific event you want (protect) is enabled, then reproduce the error.

There deliberately isn't much information about which permission is missing given to the user who got the error, to prevent a malicious user from mapping out info about the permissions needed.

Is your concern that the audit log will have extra events that aren't really failures?  If the login eventually succeeds, the authentication methods which didn't work should not cause loginfailure audit events.  Otherwise, there would be loginfailure events confusing the audit log on any system with more than one type of authentication enabled.

If the login fails, all types of authentication which were tried will be logged.

Yes, you must enable an authentication type system-wide before you can use it in an application.  An authentication type must be enabled both system-wide and in the individual application or service the login is using to be used.

You can turn LDAP off in all other applications if you only want it in the one application.   The one which is using LDAP authentication will need to look at the shared system-wide settings about domains, servers, attributes, etc, to know what to do with users logging in. 

If the users and employees are part of different domains, you might want to look into the multiple domain support.  You may be able to use the multiple domain support to let both sets of logins work separately.

Mirroring is about creating identical globals on multiple machines with one update.  I assume you don't want these systems exactly the same, but depending on what you do want, maybe you could find a configuration which would do it.  For example, maybe you could put the global you want replicated in its own database on an async member and not mirror any other databases.

It sounds like you're trying to configure a webgateway on Linux to authenticate to an IRIS server on another machine using Kerberos.  Is that right?

If so, are you already using Kerberos authentication on the IRIS server for other connections?    I would start by making sure Kerberos is working for other connection types first, which will help sort out whether this is a configuration problem on the server side or the Webgateway side.

Do you already use Kerberos elsewhere on the Linux server?

IRISTEMP is a bit different than other databases.  For example, it holds the PPGs.  If you're seeing growth in IRISTEMP specifically, then in addition to the other debugging suggestions I would also run:

d ^GETPPGINFO

to get the counts of PPG blocks.  You need to run this before the process which is causing the problem goes away and its blocks are automatically released to get any useful information.

Yes.  There's a property in the %Net.FtpSession class which says which one to use: LegacySSL.  If it's true, you'll get implicit FTPS.  If it's false, you get the default of explicit FTPS.  There's a note in the documentation of that property you might try out if you haven't already:

"Depending on the configuration of the server you are talking to it may be needed to also send 'PBSZ 0' and 'PROT P' before you can communicate, this can be done with 'Set rc=ftp.sendCommand("PBSZ 0"),rc2=ftp.sendCommand("PROT P")'."

If that doesn't help, you might need to give more details about what error it's giving.

Cache 2017.1 supports Kerberos and OpenAM, which are both SSO methods.  You can also implement your own authentication methods using delegated authentication, or use LDAP to do logins with domain accounts (which is not full SSO since you have to type the login again, but sometimes people call it that because it's just one account.)   If you want to set up SSO via SAML, you'll need to write some code to handle that, there isn't anything that can be enabled by just configuring it.

I am assuming you mean Cache database encryption keys, which are stored in files.  If the HSM supports transparently giving the file to Cache when asked, I don't see why this wouldn't work, but I doubt it's been tested. 

If the HSM requires you to enter a passphrase, use a private key to decrypt the file, or other interactive step, you might or might not have a problem.  How are you planning to do the key activation?  Will you be present and able to do those steps?  

I assume your HSM does not support KMIP, which is a communication protocol for sending keys to a central key server.  Cache does support KMIP.

I was wondering if VMS was the issue! 

The server using VMS shouldn't affect the client side, meaning I think you can still set up Studio to use the standard TLS options for all the client apps, if you want to do that.   

VMS versions of Cache do support TLS 1.0, but not 1.1 or higher.  (This is based on the OS library support.)  1.0 is being phased out in many places, so I agree it's best to find a way to use 1.2 or even 1.3 if you can.

First, are you trying to set up stunnel on the Studio machine to encrypt the connection, stunnel on the Cache server to decrypt the connection, or both?  If you're trying to do stunnel on the Studio machine, you would configure it to listen on a local port, then configure Studio to think that is the host and port of the Cache server.  Studio connects to the local port and stunnel forwards the data to Cache after encrypting it.  Using stunnel with Studio shouldn't be different than using it with other protocols; Studio isn't doing anything unusual with the connection.

Second, is there a reason you're using stunnel instead of the built-in TLS support for Studio?  It's been available since Cache 2015.1.  Here's a writeup on setting it up: https://community.intersystems.com/post/configuring-cach%C3%A9-client-applications-ssltls

With LDAP authentication, role assignment is handled by the LDAP server.  There are multiple ways of doing this, and the options vary by version, but the most commonly used is adding your user to a group on the LDAP server with a name that specifies the role you want it to have.  For HealthShare HealthConnect, you can use the same methods of configuring this as Cache or InterSystems IRIS.  Here's the IRIS 2020.1 documentation on it:

https://docs.intersystems.com/irisforhealthlatest/csp/docbook/Doc.View.cls?KEY=GCAS_LDAP#GCAS_ldap_authorization
If you are using an earlier version, or a version of HealthShare other than HealthConnect, your options will be different.

Have you thought about the OS security issues for the instance?  For example: if you do a minimal security install on Linux, many more processes run as root than if you do any other install.  The only safe way to fix that is via a re-install.  I'm always nervous about the idea of converting a minimal install to a more secure one because of those kinds of issues and I don't want people to think their instances are more secure than they really are.

For master key, do you mean the database encryption key, ie, the one Cache is using to encrypt the database?  If so, you need to re-key the database manually if this is something you want to do.  This should be an option available in the ^EncryptionKey utility in the %SYS namespace.  (The older cvencrypt utility will also re-key, but is slower and does not have KMIP functionality.)   The InterSystems IRIS docs cover using ^EncryptionKey for re-keying here:

https://irisdocs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=GCAS_cvencrypt

If you mean a different key than the database encryption one, can you explain which one? For example, you authenticate to the KMIP server using a public/private key pair.  Is this the one you mean?  Something else?