Managing Expiring Passwords Across Multiple Files

[tgilders]

Hi all, I have had the great fortune of always using External Authentication for managing users across multi-file solutions. I am now building a solution that will be hosted via a 3rd party cloud hosting provider. I've emailed them asking if they somehow support external authentication and the answer is no, unless we purchase a dedicated server. Which is what I expected.

 

My question is, what is the best practice for managing local accounts across multiple files, specifically how to manage the case of first time login or password resets which force the user to change their password upon login.  Keep in mind I'm not building "my own" login routines in any way. I'm using native FileMaker security and scripting the account creation and management using the script steps FMI provides us.

 

My one sticking point is how to "expire" the password and handle the user interaction and change the passwords in the other files using the native FileMaker capabilities. What is the best/most secure way to solve this issue?

[Steven H. Blackwell]

This is a complex problem for which there really is not a good answer. This was one of the principal reasons why FMI instituted External Server Authentication when FileMaker® Server 7 was released.

 

It's fairly straightforward to force users to change passwords at next log-in, enforce password length (but not complexity), and set expirations.  All these are done in either the Privilege Set definitions or the Account creation dialogs.

 

The complexities start with error trapping and error handling, and they become vastly more complex with multiple files. The error codes are in the low 200's.  You can find them in the FileMaker Pro documentation.

 

The real issue is not trapping errors, but handling them.  Do you roll everything back if an error occurs, and if so, how? And what if the rollback itself produces more errors? Or, do you just leave everything alone if a user makes an error, and then have an administrator reset the passwords for the Account and force the user to start over again?

 

By the way, please avoid too frequent expirations of passwords, i.e. too short an interval before a new password again expires.  Too short of an interval actually lessens security.

 

Finally, the most obvious solution to the issue with any hosting company's lack of support is not to use the hosting company's services.  The failure to support robust external server authentication is--in my view--one of the major factors arguing for avoiding most hosting companies.  The companies, of course, have a different view.  When the marketplace demands this support at a high enough level, it will come.  Either that, or a new hosting model will emerge.

 

Steven

[tgilders]

Thank you Steven. This was the answer I expected, but was hoping there was a technique or method that people are using that, while not perfect, has been generally accepted as reasonable for this case.

 

I'm working with the hosting vendor and they are willing to work with me to try to get external authentication setup, which is great news. Since we're using virtual clients hosted on their servers, it's reasonable to expect that they can integrate external authentication as well since it's all on the same network, domain, etc...

 

If this doesn't work out I think I will go with the option you describe where if something fails, the administrator will need to step in and see what went wrong and reset the user. I'm trapping and logging everything very robustly, the handling is definitely the complex part.

[Vaughan]

Since we're using virtual clients hosted on their servers, it's reasonable to expect that they can integrate external authentication as well since it's all on the same network, domain, etc...

 

 

If your FMS is being hosted in your own "dedicated" virtual machine then you can use the local OS accounts instead of an AD/OD for external authentication.

[tgilders]

Thanks Vaughan, good point. I've done that before for very short-term databases that just need a few users instead of creating a new group in the AD domain. I would hope that at the hosting vendor they integrate the virtual client login (remote desktop or citrix) accounts into the domain using domain accounts, and can then setup the requested groups for the database external authenticaion (perhaps prefixing them with a client identifier). 

 

I think the only "issue", which is small, is that the hosting vendor will need to manage adding and removing the users from the groups. But overall this doesn't happen much, and we don't have very many users at this point.