I don't remember the exact number, but it starts off as a few seconds and gets longer for each try after the limit of 5.  It can get up to minutes or hours if you keep trying incorrect logins, and then will reset to nothing after login succeeds.  Do you need the exact number for something?

If the disable checkbox is not checked, it will start delaying the response about whether or not the login succeeded after there have been too many attempts.

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.

Async mirrors are commonly used for reporting and other purposes.   What do you want to scale down to use it here?   

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.