Re: How to manage user access in FM7 and later

Carlos Pereira <carlosp@xxxxxxxxxxxxx> wrote:

> Dear group,
>
> Until FM 7, I was used to a self made, internal FM user
> login-authentication and right assigment to layouts and fields.
> However, I have just started to migrate a 40 files / FM5.5 Server / FM
> Pro 5.5 to FM7 and things look quite different to me. We have a
> Windows 2003 domain, so I can use external authentication based on
> Windows group. I could create groups just for the different FileMaker
> profiles and then use this groups to assign rights in FMP. However,
> managing rights has usually being a task delegated to somebody else in
> my company. Before FM7, things worked great: I had Secure FM, a
> personal login system and a users file where a rights manager could
> setup user rights.
>
> What is the best approach to do this is FM7 and later? (a link to a
> sample file would be great)
> Is it still necesary to have that user file to assign rights to
> layout, fields etc.?
>
> Take into account that the delegated rights manager knows nothing
> about FileMaker and would like ot remain like that? He just wants and
> easy layout with checkboxes... (this is what he has at the moment in
> the 5.5 version).

Set up the external authentication to use whatever groups you currently
have, transforming into Privilege Sets and externally authenticated
Accounts assigned to them. Modify your login system to capture
Get(Accountname) on open and match it to your user table. Run whatever
routines you used to when a user signed in.

Then individual privilege bits in your settings can be checked against
and used pretty much in the old fashion. I agree that although just
about everything you can do with homebuilt, individual privileges can be
done with Extended privileges, we really don't want admins mucking about
inside Accounts & Privileges, particularly if you use a multiple file
structure, as makes sense for most large solutions.

And it kinda gives you double protection...the security of needing a
domain login, and then having the internal privileges. Just make sure
the Account names assigned by the domain admin match the user names in
your table, or have those account names recorded in the table.

Lynn Allen
--
Allen & Allen Semiotics www.semiotics.com
FSA Associate Filemaker Design & Consulting
.

Relevant Pages

  • Re: Authenticating a user on Windows Server 2003
    ... > missing privileges (by privileges I mean rights on the acct i.e. does the ... > client user acct have interactive logon privileges and other necessary ... > Are you able to execute "runas" successfully as the user account (with the ...
    (microsoft.public.platformsdk.security)
  • Re: Default privileges of NT AuthorityLocal Service account?
    ... I have looked at the privilege membership in Local Security ... does the account have any NTFS permissions on the local drives? ... > same local rights on the machine. ... The LocalService account is designed to run with few privileges: ...
    (microsoft.public.platformsdk.security)
  • Re: Special privileges assigned to new logon??
    ... Check Local Security Policy/local policies/user rights to see if that user ... does indeed have the user right for impersonate user after logon. ... I would also check his account ... > Privileges: SeImpersonatePrivilege ...
    (microsoft.public.security)
  • RE: Upgraded to Word 2003, now I cant open files
    ... Novell NetWare Network Privileges Required to Run Word ... Description of File System Directory and File Rights ...
    (microsoft.public.word.application.errors)
  • Re: Prevent changes to Administrator password
    ... What I am trying to do is give Taz1972 some options to minimize the risk or make it harder for a lower-level DA to reset the password for the EA account. ... * This posting is provided "AS IS" with no warranties and confers no rights! ... > By adding the Deny Write Permissions ACE, ... > permission to modify the ACL on AdminSDHolder. ...
    (microsoft.public.windows.server.active_directory)