Migrating to External Server Authentication

[brian rich]

We have a large number of databases - 95 - hosted on a Filemaker 11 Server Advanced running on Windows Server, with 55 users logging in using 12 user accounts.This works reliably, but we have reached the point where we want to change passwords on the accounts, which is a mammoth task and will require taking the system offline for around a day.

 

We're considering migrating to Server External Authentication.  (We've have already got EA set up and working for a few accounts accessing a third party database on our server, so we know that part works.) We think that we'd need to proceed as follows:

1. Set up a set of Windows Domain groups, one to match each of the 12 user accounts already in use.  (e.g. a Windows Domain group called 'EA_Eng' would be set up to match the Filemaker account called 'Eng') 
2. Set up an exterally authenticated account for each Filemaker account in each database to match the appropriate group created in 1 above.  Each new account would be set as active, and would be moved just above the Filemaker Groups. When complete, all the EA groups would all be placed above the Filemaker groups, and in the same order.
3. Test the externally authenticated groups using test accounts in the Windows domain.
4. Once satisfied with step 3, add each Windows user who needs access to the Filemaker databases to the appropriate Domain Group. (As the FMP server is part of the domain, the user can now access Filemaker without the need to login again.)

Some questions:

 

Is that a reasonable approach and does it cover everything?

 

Do we need to take the databases off-line at any point -  we think it would be advisable at step 4?  (We would keep the users in the loop about any changes in log-in behaviour they might see)

 

Should we turn off the Filemaker authenticated accounts (except admin) once the EA version is in place for everyone? What is the effect if we don't?

 

Thanks

 

Brian

 

 

[Wim Decorte]

You don't need to set up one Windows domain group per existing FM account, but rather one Windows domain group per existing privilege set.  A group is a role, a privilege set is a role.

[brian rich]

Hi Wim

 

Oh dear, if we have to match the Domain Group name to a Privilege Set name, then we've got a problem.  In these legacy databases there is no consistency in the naming of privilege sets so the set 'Priviliege Set 2' in one database might have the Eng, QA and Sales accounts using it, whilst in another database Eng and QA accounts use 'General', and Sales uses the privilege set 'General 2'.  Unscrambling that will be a nightmare. 

 

I've just re-read pages 39/40 in the Server External Authentication for FMP9, and it explains about matching the Domain Group name to the Filemaker Account name.  How do you set the Domain Group to link to a privilege set?

 

Thanks

 

Brian

 

[dansmith65]

How do you set the Domain Group to link to a privilege set?

 

give them both the same name

[Wim Decorte]

How do you set the Domain Group to link to a privilege set?

 

 

When you create an "external" account in FM you're really creating a group account.  And just like an individual account you assign it a privilege set.

As DanSmith said: common practice is to name the externally authenticated FM account/group the same as the priv set/role that describes that group of users.

 

Even though it may be a lot of work to streamline the groups/roles and their associated privileges, you do NOT create one domain group for each individual FM account. 

Your solution's security will benefit from the streamlining.

[brian rich]

Thanks for that advice.

 

If we streamline the groups/roles, is there any problem with having both methods active concurrently? if we do this, how should we set up the authentication order - EA groups above FMP groups or some other way? 

 

If we implement this, it would be useful to be able to do it a group at a time so we start, for example, with engineering then when they are all working relaibly we switch the sales team over to EA.  Does this work, or do we have to do it all in one go.

 

Thanks

 

Brian

[Wim Decorte]

Nothing wrong with doing this one group at a time.  In the FM "manage security" window, on the Accounts tab, note the "view by" selection at the lower right.  You can set it to "Authentication order".

FM will stop at the first account / group that matches the user's credentials

[brian rich]

Hi Wim

 

By way of testing this out, I've just added a number of new privilege sets corresponding to the roles, and set up a new set of matching EA accounts which point to these privilege sets.  The most obvious difference when I tried logging in was that I got a 'coffee cup' icon displayed for about two seconds before the log-in activated.  By altering the authentication order, it was apparent that this was caused if a user's Filemaker account was below any EA account. This suggests that EA is much slower at logging in, which I suppose is reasonable since I assume that the login is handed off to the domain server for verification. Are there are ways of speeding it up?  (If it is relevant, at the moment I have no corresponding domain security groups set up to match these new EA accounts.)

 

Two questions: 

1. Is the slower EA login time cumulative?  That is, if the user login is below 10 EA accounts in the authentication order, does it take longer than if it was below 5 EA accounts?
2. If the database that the user logs into uses file references to a number of other Filemaker databases hosted on the same server which would get opened 'hidden', is there any additional delay whilst each 'hidden' database is authenticated against the External server or does the initial authentication do for them all?

I don't want to go down the path of adding the new accounts and privilege sets if it's going to slow down logging in too much.

 

Thanks

 

Brian

[Wim Decorte]

I have never seen authentication producing a two-second coffee cup.  I have seen situations where EA was slow if the:

- network was complex

- the AD machine was particularly busy

- or the nearest AD box was physically a long way away (hundreds of miles)

 

So there should not be a de facto slowdown just because EA is used.  I would venture to say that something else is going on.

[brian rich]

Thanks Wim

 

I'll run some further tests with logging in and see what I can unearth.

 

On a different issue, how do you handle the situation when someone has more than one role when EA is active?  We have one user who acts as Sales Admin for one part of our business, and also accounts clerk for all parts of the business, using some common databases.  With Filemaker based authentication, she logs in using either a Sales account or an Accounts account and gets the appropriate privileges.  With EA, if I put her in both security groups, she will be authenticated based on the order in which the EA privilege sets are in the security list for the database.  How does she swap to the other role? 

 

I suppose that I could make one of her roles EA authenticated and the other Filemaker authenticated, but she would always get logged in under the EA accoount in the first instance. She could relogin using the Filemaker authenticated account but this could be an issue as we have a large number of spearately hosted databases, many of which get opened concurrently simply by opening the first database, so the relogin would need to accommodate a relogin to all of these databases.  Not an easy scenario to manage as the first database she opens won't always be the same one.

 

Thanks

 

Brian

[Wim Decorte]

The principle of role-based security is that no user can have more than one role.  Hard to pass any kind of audit if that weren't true...  Nobody can be allowed to do a certain action on a record and at the same time not be allowed to do the same action on the same record.

if that's the case in your scenario then I'd say that needs to be tackled from a business point of view first.  The system should enforce security, it can not be left to the discretion of a user.

 

In general: the combination of two roles is a new role.  So her role is unique and different than any of the two roles that you have in mind.

[brian rich]

Doh!  Slaps forehead. Sometimes you get so bound up the the database you forget the business analysis.

 

Thanks Wim

 

Brian

[Fitch]

In these legacy databases there is no consistency in the naming of privilege sets so the set 'Priviliege Set 2' in one database might have the Eng, QA and Sales accounts using it, whilst in another database Eng and QA accounts use 'General', and Sales uses the privilege set 'General 2'.  Unscrambling that will be a nightmare.

 

It may be common practice to name the EA the same as the privilege set, but there's no requirement to do so or performance hit if you don't. It will just make your life a little easier in the long run if you clean it up. But that's really a FileMaker issue, whether or not you're using EA.

 

Just as with FileMaker-authenticated accounts, externally-authenticated accounts can be assigned to different privilege sets in different files. By design.

 

(Just wanted to clarify that point. I totally defer to Wim on security issues.)

[brian rich]

Thanks @Fitch

 

I've been through the process of setting up separate EA accounts and privilege sets, and am in the process of testing the new accounts.  Everything appears to work as suggested, but I still have the issue that if I put any EA account so it is authenticated before a Filemaker account, then Filemaker accounts get a coffee-cup delay of 1 to 2 seconds when they log in.

 

@Wim Decorte suggested that this seemed a long delay.  Any suggestions as to how to investigate what is causing this delay?  Our FMP Server 11 Advanced is hosted on a Windows 2008 R2 server (64-bit) whilst the primary and secondary domain servers are hosted on Windows 2008 servers, all on our own internal network.

 

Thanks

 

Brian

[Wim Decorte]

The delay happens before they get the account / pw dialog or after?

[brian rich]

Hi Wim

 

Afterwards

 

I looked at answer #7544 on the Filemaker Support forums, which discussed poor performance when accessing files via External Authentication, which seems to confirm that there is a problem.   It uses the term 'parent file login' as the first type of login attempt - but I'm not sure what that means. 

 

As an example, after I open our Parts List database, there will be nine other databases on the Window Menu which will show with their names in brackets; all are used by the Parts List in various ways.  Are these what are referred to as 'Parent Files'? 

 

FWIW, there are no 'Log in using' default accounts on our databases.

 

Thanks

 

Brian