Auto login on fp7 files doesn't work when hosted on Server

[R.B.]

So we have an install of FileMaker Server 11 running on Windows Server 2008 R2. The databases being hosted have been configured (in Filemaker Pro Advanced) in the "File->File Options..." dialog to automatically log in using a user name with no password, and the feature works fine when opened in FMPA locally from the file system. Once they are being hosted however, opening them on the server or on client machines across the network results in being prompted for a login. This is the dialog box that you can force open by holding the Shift key while opening the file.

We have quite a few deployments like it and have never come across this before, its seems to be something on the FM Server 11 forcing the hosted files to prompt for login. Any ideas?

[Wim Decorte]

Does the priv set that is attached to the auto-login account have the "fmapp" bit set?

[R.B.]

Yeah, they have the privileges. We have a lot of deployments of these files, all those settings are the same on all of them (I did just double check though), and there is only 1 that doesn't work. Could there be something in the Windows environment, security or otherwise, causing this to happen?

[IdealData]

See Sharing > FileMaker Network

Select the offending file, and ensure Network access to file is NOT "No users". If you select "Specify users by privilege set" then the auto login user must be in that set, otherwise set to "All users".

[Wim Decorte]

Is FMS configured to also allow external accounts?

What does the FMS Access log and the Windows security log say about the attempt to log in?

[Matt Klein]

Hi all -

I work with R.B. We found the problem. It's a bit disturbing actually. As R.B. said, we distribute copies of these files to 40-50 customers annually. These files are all set to auto-login using a certain account, allow ALL USERS access via FileMaker Sharing and ALL privilege sets are set with the fmapp bit on.

These files had resided on a workstation for a couple of months and were being moved to a server which is when we found the problem.

Somehow, and this is the disturbing part, FileMaker sharing was set to "Specify user by privilege set" with the Full Access account select and the fmapp bit was off on all but the Full Access privilege set.

We have replaced all the files with the clones that we keep in our corporate offices and all is now good.

I'm curious as to what you all might feel could have caused this. It feels an awful lot like someone was trying to hack the files to me.

[R.B.]

Ok, so it was in the "File > Sharing > FileMaker Network..." menu. All of the files are supposed to be set to "All users", but they were set to "Specify users by privilege set" and only [Full Access] was specified.

On top of that, we found that in the "File > Manage > Security..." menu, under Privileges, each privilege set, except Full Access had the "fmapp" unchecked.

Their are almost a dozen files in the solution and it requires re-entering your password each time you change these settings. The files come from a template set that are already configured. It's not something that we could have done to each file accidentally.

So I'm wondering, are the settings bytes that could have been changed due to encoding mishaps during a transfer. On another note, we know there are plenty of tools out there that can wipe out the passwords in a .fp7 file, allowing you to login with Full Access privileges. Could this somehow be from a failed attempt? Using an old program or script, instead of wiping out the password, it wiped the bytes that set those permissions.

None of our passwords were wiped or changed so its hard to say. Maybe someone has seen something similar happen?

Edited November 24, 2010 by Guest

[Wim Decorte]

If someone can get physical access to the files and media to copy them you should consider them lost. What's to say they haven't been copied to somewhere else and their current passwords stripped out?

[Matt Klein]

If someone can get physical access to the files and media to copy them you should consider them lost. What's to say they haven't been copied to somewhere else and their current passwords stripped out?

Define lost. I mean, we still have them and have restored the proper settings. FYI, there was no data in the files at all. The client hadn't started to use them yet.

[Wim Decorte]

Lost as in they've been copied and the intellectual property of your code has been "lost".

This is the worst-case scenario obviously as I have no idea what's involved in your setup and your people.

But it's a basic rule-of-thumb that clearly shows that physical security of your development setup, backup locations, etc is crucial if you value your work (and potentially your client's data)

[Matt Klein]

Lost as in they've been copied and the intellectual property of your code has been "lost".

This is the worst-case scenario obviously as I have no idea what's involved in your setup and your people.

But it's a basic rule-of-thumb that clearly shows that physical security of your development setup, backup locations, etc is crucial if you value your work (and potentially your client's data)

Thanks for the feedback.  We are aware of that particular rule of thumb. Most of our clients run our app on Server, but there are those who can't be convinced, with mere words, to purchase a server when they only have a single user on a single workstation.  

In all cases, protection of the files falls on the client and there technical professionals.  We can do our best to protect the data via programming, but certainly can't watch over all 400 of our clients to make sure they are properly protecting their files. We can merely offer knowledge in that regard.  In our industry, most of our clients are serious about protecting their data and do it properly.

As for the loss of intellectual property,  it's unfortunately part of the risk of doing business in a vertical market where you don't control the client's environment.