Have you tried specifying the location and name of the SSLDefs.ini file with the ISC_SSLconfigurations environment variable?  This is an alternate way of specifying where the configuration file is.

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.

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.

If you mean how they're moved in the sense of how does Cache make sure data is durable in the database and consistent even if there's a crash, you might look at the data integrity guide's section on the write image journal (WIJ):

https://cedocs.intersystems.com/ens201814/csp/docbook/Doc.View.cls?KEY=…

You might mean a number of other higher-level things though.

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.

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.

Please avoid using irisdb.exe -s ..\mgr if at all possible.  Calling the executable directly doesn't work in some particular cases, and using irisssession is how you're supposed to do this to avoid those issues.  Please look into how you can get irissession if you need it instead of using a wrapper like this.

Are you asking about the KMIP server and how it works?  If so, I don't think this is the right place to ask, and would recommend you talk to people who know more about your KMIP system.

Or are you asking about how Cache handles key rotation for encrypted databases and/or managed key encryption?   If so, this is mostly up to the user.  There isn't automatic re-keying of databases on a schedule.

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

Is there a reason you're using shadowing instead of mirroring?  Shadowing is much older and doesn't really receive updates or improvements.  It was also not as good at telling you when there was a problem and the destination was behind or out of date, which means it's harder to know that the backup server is ok.

The native Cache LDAP support is only for an LDAP client. 

The system monitor checks certificate expirations:

https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCM_healthmon

It's listed in the table "System Monitor Status and Resource Notifications"

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.