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?