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.

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.

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?

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.

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.

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?

I've done a tremendous number of system restores over the years, and generally think that structuring your restore process to require manually removing the WIJ isn't a preferred design choice.  It's too easy to get into the habit of removing it, and then do it at a time when it causes problems.  

I assume you're asking about doing this following a restore of all databases, including CACHESYS,  since if only some databases were restored, removing the WIJ could lead to problems with the databases which were not restored.    I'm also assuming you're talking about designing a backup restore process, not an actual down system you're trying to get back up.  (If you're talking about a down system you need help with right now, please call the WRC.)

In a full system restore, you would restore the databases and WIJ from the older time.   Since you're already restoring all databases, have you considered treating it like a full system restore and including the older WIJ, which would let you avoid the need to remove the current WIJ?   This would also mean that the system would know which journal restore point to start from, and could automatically start journal restore for you at startup, assuming the journals are all available before you start up.

The error sounds like this could be a problem from a lower level (eg, the network), but I would suggest you start by collecting the SSH debugging log information to see if it helps.  You can find how to do that in the last section of this page:  https://community.intersystems.com/post/using-and-debugging-netsshsession-ssh-connections

Are you trying to have the same user have different login namespaces on different systems?  If so, for your InterSystems IRIS instances, have you looked at the "Authorization group ID" and "Authorization Instance ID" which are part of each LDAP configuration?   You can use these to make each instance (or group of instances) look for a different group to define the namespace.    

There are a lot of possible reasons this search be failing, but they mostly boil down to not looking in the right place for the user or not being able to identify the user when you find it.  Here are a few things to try:

For a Windows AD server, you will almost certainly want sAMAccountName as the unique search attribute. 

Check to make sure your base DN includes the location of the user you're trying to authenticate.  You may want to test with a high-level or generic base DN to make sure it matches the user account.  For example, try DC=intersystems, DC=com instead of a longer base DN like: OU=Boston, OU=Users, DC=intersystems, DC=com  This will mean you search a larger part of the tree (which is slower) but will let you make sure you're searching an area which includes your user.

Take a look at exactly what DN the is being used for the failing user.  This should be in the detailed output of the test connection.  Is the base DN being appended to the full DN that you gave as the username?  If so, you may not want to use the full DN as the username, and instead just the value of the account name.

If you use Kerberized telnet with encryption, the connection will be encrypted.  To quote the documentation:

"Kerberos with Encryption — Kerberos manages initial authentication, ensures the integrity of all communications, and also encrypts all communications. This involves end-to-end encryption for all messages in each direction between the user and Caché."