There are probably a lot of ways to do this, but one solution I manage uses FileMaker accounts for the main file that everyone must open first. They are free to change their password without me knowing anything about it.
Once they are logged into the main file the system does a relogin to one of a few different accounts with varying access privileges depending on who they are. Their real account name is kept in global storage so I always know who they are for tracking purposes. This works well for this client - your mileage may vary.
My first thought is that as an administrator you can ALWAYS change someones password and pretend to be them. However, and easy solution, have your management db store the passwords in a global field that is wiped clean after your script completes. If you really want to keep their passwords secret thay'll have to excute this script themselves.
I have developed similar systems in the past to handle the control of User Accounts to multi-file (originally pre FMP7) systems.
Having thought through your request, I don't know of any other system that will handle this the way you want, but I do have an idea that I would like to explain to you.
The main issue here is that each user's password has been entered by yourself into your control database and is therefore available to you.
So imagine your control database without the facility to store the user's password - it wouldn't work, but it wouldn't be a security threat either!
You could then set up the details for a new user in this database and then pass a link via email to the new user, who could then log into their record in the control database (using a default or simple password) and enter their own password. Once entered, the script could apply that password to all the relevant files and then delete itself from the database (or the password could only be stored in a local variable, so that it disappeared once the script finished).
This provides you with a secure system, to which you have no access to the various user passwords. Furthermore, you don't have responsibility for a database which could allow access to anyone's account. Also, you have already written most of the code, you just need to add the form on which the user enters their own password (and a bit more …)
Hope this gives you food for thought …
Please come back here with any difficult issues you might come across.
Best wishes - Alan Stirling, London UK
Our Account Management Database file allows not only creation of accounts across all the files in our system, but the resetting of all passwords for any single account name across all files to a single new password.
We don't store passwords anywhere. If a user forgets it, we ask them what they want us to reset the PW to, and reset ALL of their accounts (same Account name for same user in all files, of course) to that new password.
Yeah account manager is gone and ever since FM 7 came along that product had less significance. Especially if you are dealing with many files it can be a pain. Its one thing to have a login for one file and another login for another file. You can add the passwords to the keychain and you never have to remember them. Or if you were using External Authentication then users would have their credentials all in one place. But doesn't sound like you are doing that.
If you need to make sure that the passwords are in sync with each of the other files so if they change their passwords in one file then it will also propogate throught the other files. You might want to see about using custom menus to trap when they select change password menu item and fire off a script that asks them for their credendials and passes those credentials from one file to anther utill all the files have been updated.
This is the way I remember doing it back then ( pre 7 ). I am sure someone here migh t even have a file that has this in place.
NOTE: There are still many problems with doing this ... you could have changned some passwords only to disover that you'll account name is not present in a particular file. Or worse, you changed some but not all of them have been updated.
As my nephew likes to say - Good Luck With That!
If is is of any help to you I can send you the account manager file if you want to explore it.
Let me konw.
Interesting solution to the sync problem. One of my (unmentioned, sorry) requirements is that the user's actual name be available. For instance, when a third grade teacher logs in, he or she should have a found set consisting of only their students. In your solution, it sounds like the second file doesn't know who the user actually is, only that they have a specific level of access.
We use the user's real name as their Account Name all the time. It works find with the Accounts Management file system I mentioned earlier.
In fact, we don't allow any "generic" account names. It's the permission groups that get the settings for security anyway, not the account name.
I'm surprised nobody has mentioned external authentication. I use EA almost exclusively and I never have to reset passwords, Windows Active Directory handles everything. You just put the user in the correct AD security group and Filemaker uses their Windows login. From a user's point of view there is nothing better. All they do is log onto their computer in the morning -- as they do every day of the week -- and then whenever they use Filemaker Pro it just opens. No username and no password required. FM already knows who it is because it uses their Windows credentials.
From an admin point-of-view all you have to do is get the user added to the proper AD security group. Nothing more is required.
If you're running FM Server on a Windows domain you might want to consider this approach.
I did mention external authenticaion it in my reply to Clay but mentioned alternatives.
Ah yes, I see that now. I stand corrected. I skimmed it pretty quickly expecting to see EA mentioned early on because it is a fantistic method of controlling access if one's infrastructure is right.
We have a mixed Mac-Windows environment, which makes EA more complicated, I believe. I also have reservations about EA's assumption that the person attempting to log in to a FM database now is the same person who logged on to the client several hours ago. In other words, I'm not comfortable having to depend upon users logging out when they leave the room, etc. It certainly merits another look, though.
Part of the issue seems to be user training and configuration.
Sounds like your FM Server should be set to log users out after a relatively short idle period. Same with configuring the timeout of a workstation - activate the screensaver, with a mandatory password to wake. That won't secure the databases, but it helps a bit.
If your data is that sensitive, your users should be trained on the merits and necessity of locking the workstation or closing the database when leaving their desk.
Another option could be an OnTimer script - should the database be idle for a certain period of time it switches to a splash screen, logs in as a user with zero access (except to this screen) and then just sits there until the user logs in again.
I've got clients with mixed environments and I don't recall any issues getting EA to work for them.
A really vicious auditor would say that this approach is flawed, in that you knew what the password was when you reset it, and therefore it isn't truly confidential. Nit-picking, I admit, but nonetheless true.