Practical management of domain groups

[Philip Sommers]

I have been tasked with converting about 120 FMP 6 databases to FMP 8. In the process, I am converting over from Filemaker authentication to domain authentication for most of the databases (except for full-access accounts). I understand how domain authentication works and already have it operating on a few files on our Filemaker 7 Server Advanced/Windows Server 2003. Currently, I plan on having three privilege set groups to authenticate externally: Read only, Read/Create/Edit, and Read/Create/Edit/Delete.

The problem is that I do not want, for example, everyone in the Read/Create/Edit group to be able to edit data in every database, only certain ones. I know this could be remedied by having three groups per database, but the guys who manage the domain accounts don't want to have to contend with three groups per database (and I don't blame them).

What is everyone else doing in this situation? Is there a better way doing this (by calculation maybe)?

Edited December 29, 2005 by Guest

[Wim Decorte]

I think you're confusing two concepts:

- authentication (who are you?), and

- authorization (what are you allowed to do?)

Priv sets are all about authorization, accounts are for authentication. These two have very little in common.

You create accounts to divide people in groups that make sense (sales, sales managers, accounting, accounting managers, ...). You create priv sets based on different roles people will have in your system, different levels of authorization (view records, create records, delete). Where those two come together is when you assign priv sets to accounts (groups really in the EA scenarion).

Some groups (accounts) will have the same priv set, others not. The number of groups and the num ber of priv sets are not related. "Accounting Managers" may have the same privileges as "Sales Managers", or not...