External Authentication across related files

[PGageler]

I have around 50 users variously interacting with around 10 databases. Using internal (FileMaker) authentication, it is becoming increasingly cumbersome to maintain passwords across the various solutions. Resetting a password for someone, for example, may mean that I have to go an make the same chnage in each of 10 databases.

For an easier life for myself and my users I am looking at implementing External Server Authenication. But after reading the FileMaker Paper on the subject, I still have a couple of big questions:

(I apologise in advance if this is a bit long or confusing)

1. As these databases are in constant use now, I cannot afford to have any current functionality upset. If I set the server to use External Authentication as well as FileMaker Accounts, and do not make any other chnages affecting current users, will they all log in just as they do now? The reason I want to know is that after turning this function on I would like to do some general testing, but I don't want to upset of affect existing users for the time being.

2. Currently users may have access to any number of the 10 or so databases, being assigned to differnt privilege sets the different databases. When I first set up a user, I ask them to set the same password in each solution, so that after logging into the first database (a menu screen) those details will be passed through to any other databases that they have permissions for. With External Authentication I image I will set up a User Group on the Domain Controller for each Database-PrivilegeSet combinations. Is it the case that the users windows username will allow appropriate access in each related database, so that users will only see related data according to their privileges (as they do now)? That is, with external authenication, does the person's user information get passed from one database to the next, or it is always via the domain controller? Therefore can the user be part of a different FileMaker Account user groups in the different databases (eg. may be a "manager" in the salary database, but only a "browser" in the training database?

3. Finally, I have a few databases that are read-only to most users (holding generel reference data used across a number of solutions. At the moment, these databases are set to open using Guest privileges. Can these detabases be left as they are or would I have to set up new accounts if people accessing the main related databases are being authenticated externally?

I would be appreciative of any advice. Thanks

[Wim Decorte]

#1: yes, changing that FMS option does not affect how users log in with internal accounts. It just signals to FMS that it should also look elsewhere for account info.

#2: the same "external account" (or group account basically) needs to exist in each file. Just like what is the case with an internal FM account. The privilege set you assign to that account does not have to have the same rights in each file.

#3: you can leave those as it is now. Remember that External Authentication is just to let FM know who the user is. What the user can do is in the privilege set.

[jlr]

Developing an authentication scheme for a network can bring on many challenges the greater the number of users on the network. For this reason, I always try to simplify things as much as possible. In terms of authentication, I consider this a two part process.

First there are the credentials necessary to access the local computer on the network. For this I use a domain controller to authenticate and never make local user accounts. This way, I can control access at the server level and use a sample profile as a basis for all users accounts.

Second, I developed an authentication scheme for Filemaker that uses only two accounts (under Define accounts and privileges). One global user account for all users which is automatically logged into when the file is opened and the other for myself, the developer. Users use a script to logon to interface.fp7 which has limited menus to prevent access to data.fp7 files. Interface.fp7 is maximized and locked. User experience is dictated by lots of scripts. For all users, access is determined by a database (users.fp7) where I set general categories for privileges, like administrator, manager, user, and custom user (with decreasing privileges for the latter). These accounts have view, edit, create, delete, privileges setup that are set to global fields when the user logs on with script. These globals are used in the privileges of the global user account.

For more information, I recommend www.filemakermagazine.com – there is a video that uses a similar model.

Good luck.

[Steven H. Blackwell]

I would [color:red]strongly recommend that you rethink this process. It offers a significant number of avenues for unauthorized access to the FileMaker Pro system. You have already authenticated the users with Active Directory; now simply use the Groups feature in FileMaker Pro to determine their privileges. Very straightforward and simple.

I have not looked at the article in Advisor, but that publication in the past has been full of bad advice about security. Take a look at these Tech Briefs and White Papers on the FileMaker, Inc. website:

http://www.filemaker.com/downloads/pdf/techbrief_fm8_server_auth.pdf

http://www.filemaker.com/downloads/pdf/techbrief_security.pdf

http://www.filemaker.com/downloads/pdf/techbrief_fm8_server.pdf

Steven

[jlr]

Maybe my explanation was bit too short but it follows that each user account has a unique group account since this is where the actual security occurs. At worst your global account will not have privileges to edit scripts and layouts to minimize access the core of your FM development.

The core of your security is NOT going to come from FM but how you setup your Active Directory and privileges to shared objects, not to mention the level of trust you have of your users. If you don’t want someone to access your FM databases block them at the AD level and prevent access to computers on the network by forcing domain log-ons through local machine security or even isolate the computer from network (but that defies the idea of a network). Otherwise, you have to depend on FM which has only a basic security.

But having global group accounts and script logons with circular arguments within a contained paradigm is the best you can do with FM. You have to weigh your time vs. how much security you’re getting in return. You could just sit there and watch a person work that would get you lots of security but that would be counter productive. So any model you create has to have some return in the business world. Giving each person a log on would be a nightmare to manage, you would have little time to do more productive things like tinkering with your offline server to do disaster preparation and development.

[PGageler]

Thanks for the various replies. I have taken the plunge and implemented external athentication and it all seems to be working perfectly.

Initially, I was concerned when I read Wim Decorte's comment:

#2: the same "external account" (or group account basically) needs to exist in each file. Just like what is the case with an internal FM account. The privilege set you assign to that account does not have to have the same rights in each file.

In testing however, I found that people could belong to different groups across the different databases, allowing me the flexibility to mix and match privileges across a range of solutions and users. The only trick is to ensure that the authenication order correct, so that a user who belongs to more that one group has the right privileges assigned in a specific database.

Again, thanks for the help.

[Wim Decorte]

That comment of mine was under the assumption you wanted to have the same rights for the same user in the different files. What you're doing works too, but it somewhat goes against a standard "roles based" setup. You have 1 user playing two different roles (each group is a role normally).

[mcyrulik]

Will this also work accross multiple files located on multiple servers? Assuming that the Account/Password exists in some form on the remote server.

[Steven H. Blackwell]

If all servers are members of the same domain, it will work. In Server 8 with External Server Authentication, trusted domains were introduced. There have been some issues with getting them to work.

Steven