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.

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:

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.

There are two different connections here - one from the browser to the webserver, and one from the CSP gateway to Cache. Either or both can use SSL and they are configured separately.

You said you want HTTPS. This would be used on the connection between the browser and the webserver. It does not involve Cache or the CSP gateway at all. It is configured entirely in the web server configuration. For example, if you are using Apache, it is configured in the httpd.conf and related Apache conf files.

The settings you've shown above are for the CSP gateway to Cache connection. If the gateway and Cache are on separate machines, you may also want to configure SSL for this connection. The gateway will be connecting to the SuperServer on Cache, so you will want to follow the instructions for configuring SuperServer SSL if you want to get this part working. The instructions for that are here: