Access security in a Windows 2000 network

[heighwayman]

I have created an access database with user level security on a server in a Windows 2000 network. I was logged on to the server and the database was placed in a folder with general access for all network users. When I log into the database from the server, the appropriate security requests appear and the Access user level security permissions all work as expected.
However when I log on to a typical user/client computer on the network and create a shortcut to the secured database, and log into the database via the shortcut, I am allowed to go straight to the main user menu that I have created, without any security requests. Not only that, the user level security permissions are being totally ignored and a read only user can update anything for example.
Any help would be gratefully received. PS. Is this an Access or Windows 2000 network problem?

 

[psemianonymous]

1. This is an Access security problem--you apparently didn't set up security totally properly.

Check out the MS Security FAQ to run through a checklist of all things you need to do. The first step is to *NOT USE* the default workgroup to start with, which you have apparently done. Sorry, but you're probably going to have to start over.

http://support.microsoft.com/support/access/content/secfaq.asp

 

[jrollins]

Oh, just shoot me. I have been to every forum and newsgroup and find this problem everywhere. I have read-read-read the MS Access Security FAQ. I have created a new database and imported all the objects. I have renewed the SYSTEM.MDW file from the MS Office installation disk. I have tried removing User group and Admin user permissions manually (without the Wizard). The security works just fine on my PC. And STILL! - any user on the network can bust right into the database with full rights. Anybody out there with a fresh idea?

 

[psemianonymous]

You never mentioned firing up the Workgroup Administrator to create your custom MDW file. For me, the EXE file resides in "C:\WINNT\SYSTEM32\WRKGADM.EXE" - for you, the location may differ. Use that to create your own MDW file, then you can follow the steps on the FAQ above.

And by the way, the Workgroup Admin is step 1 on the Access Security FAQ - I just checked it.


Good luck

 

[jrollins]

Sorry I didn't mention it but I did use wrkgadm.exe to create a new .mdw file as the first step in the process.

 

[psemianonymous]

Here's the deal then:

Somehow you are not denying access to the default "System.MDW". There are many ways that this can be happening:

1. You're not using a different MDW file. Open Access using the "/wrkgrp C:\etc\yourWIF.mdw" parameters to ensure your workgroup is used instead of the default System.MDW. You might have created it, but are you using it? Go to your immediate window (CTRL-G) and type/paste in:

?syscmd(acSysCmdGetWorkgroupFile)

that will show you what workgroup file you're using. Make sure it's the one you think it is.


2. You have to remove ALL permissions from the Users group and the Admin user.

3. It's best if your "superuser" user has ownership of all the database objects. Not the Admin user (since it is shared with the default System.MDW), but some other user.

 

[jrollins]

Interesting. When I run wrkgadm.exe it says my default .mdw is DLEC_PD.MDW (the new one I created). Then, if I dbl-clk on the file thru Explorer it opens the login dialog box. I log in as the different users I've created and the permissions are all restricted as expected. However, I tried to open it with the icon

(target: "C:\Program Files\Microsoft Office\Office\MSACCESS.EXE" "Z:\DLEC PROJECTS Database\DLEC PROJECTS Database.mdb" /wrkgrp "Z:\DLEC PROJECTS Database\DLEC_PD.MDW&quot

and I get this message: You do not have the necessary permissions to use the 'DLEC PROJECTS Database.mdb' object. Have your system administrator or the person who created this object establish the appropriate permissions for you.

I am the 'superuser' and all users have access to the Z: drive.

 

[psemianonymous]

1. I recommend you re-JOIN the default workgroup in the Workgroup Administrator, just to set things back to normal, and ensure you're using your special workgroup only when you explicitly want to.

2. I don't know exactly how it works, but sometimes DOS/Command-line stuff doesn't like spaces in filenames. Find the equivalent FOLDER~1\ nomenclature and use it for your db. This one is guessing, and depends on your version of Access as much as anything else.

3. This is an entirely different problem from what you stated above. Now you don't have enough permissions when using a shortcut? I still recommend you do the syscmd test - see what workgroup you are Actually using instead of what you think you're using. This sounds like you accidentally set up all the permissions in your default System.MDW file, THEN created your PD.MDW file, THEN made the shortcut, and THEN are not able to enter the database because you have all your users and permissions set elsewhere. This is the only way I can explain the behavior.


really, though, I'm stumped. Come back with a list of the following if you're still stumped:

1. What workgroup file you're currently JOINed to in the Workgroup ADministrator. Full path & file.

2. The userlist of your System.MDW file. Yes, this means setting stuff back so you can get back into the system.MDW. For a shortcut, you can temporarily rename it to .MDB and open it, and look at the query "userlist" or something similar.

3. The userlist of your PD.MDW file.

4. The target of your shortcut. Copy/paste preferrable.

5. The owner of the database - this means going into User And Group Permissions and checking the owner. Note if the owner says "unknown". Tell me which workgroup you're using when you do this--either will work ( use ?syscmd(acSysCmdGetWorkgroupFile) )

6. Result of ?syscmd(acSysCmdGetWorkgroupFile) when the database "works". Full path/filename.

--
7. And now a small slice of permissions:
-Check the Users and Admin for permissions on the database itself--Open/Run; Open Exclusive; Administer
-check for your System.MDW
-check for your PD.MDW

 

[jrollins]

Thanks. I'll go thru this and report back. I think I understand why you're at the top of the experts list.