Are you authenticating via Active Directory?
Yes, forgot to add that. It is also a multi file solution with typically 60 active connections
Yes, this is typical when using AD. We used to see it on all our solutions. It appears to have gotten a lot better in versions 12 and later. Surprises me that you're still seeing it with version 13, though; I only have a single failure today on my version 12 server. The development version of 13 I have only throws the error (more precisely, warning) when I actually goof up and type in the wrong credentials.
But unfortunately, I don't know of a way to suppress it. It appears to crop up under a few different circumstances:
1) Using an opener file, where credentials are passed but they fail.
2) Having an auto-enter account that doesn't exist.
3) Attempting to pass credentials between hosted files. (For some reason, AD credentials don't seem to get passed between files when you open the Manage Database dialog.)
4) Obviously, any time someone puts in incorrect credentials in a login dialog.
I don't know that any of that helps you, but it might provide some places to look and / or some explanations for your security folks.
Sorry not more help. Maybe someone else knows more.
Do you have a file that is still set to auto-login? That would generate the error.
Or a file that is accessed by way of a local launcher/opener file? That would do it too. In that case, switch to using the FMP protocol to open the hosted file.
We use a local launcher file that is auto logged in with the launcher file's username and password. The launcher then opens a hosted file that uses active directory for login.
This setup allows for the hosted file to open without user intervention for a username and password. I am not sure of another way to set this up. Removing the auto login prompts for a password. Changing to external server for authentication prompts for a password. Auto login using an account in active directory opens the host file with the user hard coded in launcher, not the local machine.
We use a local launcher file that is auto logged in with the launcher file's username and password.
What happens is that the launcher's account is used on the hosted file, that fails and logs the error.
Check out the FMP protocol instead of a local launcher file.
Here is a document.
NOTE: In FileMaker Server 10 and later the failed authentication warning will only get logged if 1) login is not SSO or 2) Setting “Client Auth Method” is set to use both FMPro and External Server accounts.
If so, to Not logged we need 1) login is SSO and 2) Setting ... to use only FMPro accounts.
Then you can't stop logging.
what do you mean "adminaccount " ? Full access account in the database to open or default "Admin" in all newly created database or windows "administrator" or FMServer admin console user ?
The adminaccount is the auto login account in the launcher file.
Thanks, I was avoiding using the FMP protocol because it seems like it is a kludge. I prefer the opener file because it allows you to pin the file on the Windows 7 or 8 taskbar within the FileMaker application. It also allows for some error handling when the host file cannot be reached. But if the FMP protocol fixes the greater issue, I guess that is what I will do.
Have not tried this, but could you use the local opener file as is, but instead of using the regular "Open File" script step to open the hosted dB, use "Open URL" script step with the desired FMP URL in it?