I have my database on a server now, split it, removed the admin user from admins group,removed user permissions, changed the db owner to myself by importing to a new db,have all accounts and permissions set, and a shortcut to include the new system.mdw. I have done everything (I think)but encrypt it. Still, I can go to a different machine and open the db without using the shortcut and get into it with no logon. Short of wiping out the system.mdw file on 120 machines, how do I stop this?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations bkrike on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
still unsecure
- Thread starter billcam
- Start date
Ouch! It sounds like you've done everything right, but you must have missed something.
How did you create the secured system.mdw? I hope you did it with the Workgroup Administrator, and that you specified a Workgroup ID for it. If you just made a copy of the default system.mdw, that's your problem. The default system.mdw installed with Access will have the same Security ID (SID) as your secure system.mdw. Access can't tell them apart if the SID is the same. And since the default system.mdw has Admin in the Admins group, you can't protect against the casual user.
If that's what you did, you can fix it. But it's a tricky procedure, and I don't want to spend time checking my advice until I know that this is your problem. So let me know, OK? Rick Sprague
How did you create the secured system.mdw? I hope you did it with the Workgroup Administrator, and that you specified a Workgroup ID for it. If you just made a copy of the default system.mdw, that's your problem. The default system.mdw installed with Access will have the same Security ID (SID) as your secure system.mdw. Access can't tell them apart if the SID is the same. And since the default system.mdw has Admin in the Admins group, you can't protect against the casual user.
If that's what you did, you can fix it. But it's a tricky procedure, and I don't want to spend time checking my advice until I know that this is your problem. So let me know, OK? Rick Sprague
- Thread starter
- #4
I did use the workgroup administrator and created a new system.mdw file in the shared folder. I didn't think to name it something besides "system.mdw" at the time. I tried renaming it but that didn't work. Think that's my problem? Everything else seems to work fine.
No, the name of the file doesn't matter to the security function. What matters is that it has a different Workgroup ID.
Did you remove permissions from the Admins group in the default workgroup? Log on using a default system.mdw, then go in and remove all permissions from the Admins group. This won't affect the permissions of the Admins account in your secured system database, because although the names are the same the accounts are distinguished by the Workgroup ID. I'll bet that's what you missed. Rick Sprague
Did you remove permissions from the Admins group in the default workgroup? Log on using a default system.mdw, then go in and remove all permissions from the Admins group. This won't affect the permissions of the Admins account in your secured system database, because although the names are the same the accounts are distinguished by the Workgroup ID. I'll bet that's what you missed. Rick Sprague
- Thread starter
- #6
No, it doesn't. The permissions themselves are stored in the database, it's only the user and group definitions that are stored in the system database. So you only have to do it once (unless you have multiple copies of your back end).
Make sure you only remove the permissions for the default Admins group. As long as you're logged on via a default system database, you should be safe. Rick Sprague
Make sure you only remove the permissions for the default Admins group. As long as you're logged on via a default system database, you should be safe. Rick Sprague
- Thread starter
- #9
Nothing I tried worked so I went back and started a new db from scratch and now I think I have it working. I imported all my objects but now I have to do something about my users and groups. Is there any way to import them or do I have to retype all of them?
A thought I had is if you create a user group with the admin level authority but not called admin, why not automatically logoff admin when they start the database. For your startup form on Current get it to check the current user, if Admin Docmd.quit.
Would this be insane? You could create a Msgbox which informs the user to contact you then shuts down the database.
I havent tried it but would think it would stop the harmless users who just do not know better.
This could be commented out 90% of the time in your dev copy but active in the mde.
Would this be insane? You could create a Msgbox which informs the user to contact you then shuts down the database.
I havent tried it but would think it would stop the harmless users who just do not know better.
This could be commented out 90% of the time in your dev copy but active in the mde.
- Thread starter
- #11
Maybe. It might mean you've defined a user or group account with a different PID, or you missed a user, so there are permissions in the database for a user or group account that was not found in the new system database. (An account [other than one of the predefined accounts] must have both the same name and the same PID to be recognized as the same user or group by Access.)
As long as you deleted all your custom user and group accounts from your earlier system database, you're OK; the old permissions will exist but there will be no account that uses them. Rick Sprague
As long as you deleted all your custom user and group accounts from your earlier system database, you're OK; the old permissions will exist but there will be no account that uses them. Rick Sprague
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question
