Security: Advice on remote admins

[TinkerMan]

Hi

I'm currently in the process of testing security before shipping my database off. I have read the access security faq, but I'm not sure which option to go for. The main factor that makes me doubt, is that the db will be sent to locations that I will not be able to physically get to myself. I am hoping that some of you have some experience on dealing with remote installations of your databases.

Option 1:

• Use one workgroup file
• make a user_admin user which is NOT member of the admins group
• rename the workgroup file to an mdb, open it and give the user_admin permissions to edit the user and group table

The problem with this approach is that the user_admin can assign any user to the admins group, which basically defeats the whole purpose of this option really.

Option 2:

• Use two workgroup files (development/securing and distribution)
• make the user_admin a member of the Admins group in the distribution file

As the Admins group is different in the distribution workgroup file, it is impossible to change any database object. The only problem is if something were to go wrong (which I think is highly unlikely ) it might be good to be able to manually walk the user through fixing the problem, and to do that it is likely that some database object needs changing, therefore needing an admin login...

comments or suggestions welcome

Thanks again

 

[ghudson]

Your db must be split. Providing db design updates to the front end when neccessary will prevent the user from losing data. Search around for the topic is all over the forum.

 

[TinkerMan]

Thanks ghudson

This is a very important point, although I have always done that, exactly for that reason, for all my db's.

After keeping this on the backburner over night, I seem to have concluded that option 2 is the only alternative that does not by default invalidate the security. I'll try fixing the problems by sending them new frontend db's. If all hell breaks loose, I'll just send a workgroupfile with a temp admin password. As long as that file is not spread to other sites it'll probably be ok. If I get really paranoid I could always recreate the db with new admins ID to invalidate the temp workgroup file.