Re: Able to open secured database with default MDW

Joan: I logged on as sradmin and confirmed that the database and all objects
were owned by that user. The admin user is in the Users group -- and I
confirmed that this group has no privileges on anything. Then typed what you
suggested in the immediate window -- and my custom workgroup appeared in
response.

All this and I can still get into the database directly when using
System.mdw. I really am puzzled.
--
susan


"Joan Wild" wrote:

When you open your secure database, are you logging in as sradmin? If so,
then you can go to Tools, Security, Permissions and verify that the Admin
User and the Users Group have NO permissions on anything. You can also go
to the Change Owner tab, and verify that sradmin does indeed own everything.

You may not need to start over.

Also once you log in, hit Ctrl-G and type
?DBEngine.SystemDB
That should tell you for certain, what mdw file you are currently using.


--
Joan Wild
Microsoft Access MVP

Susan L wrote:
I'm pretty sure I was. Could my user "sradmin" be the owner of the
database and all objects if I were't in the custom workgroup file
when I created the new database? Do you think I need to start all
over? --
susan


"Joan Wild" wrote:

Hi Susan,

You missed a step somewhere.

Are you sure you were joined to your secure mdw when you added the
user? You may have still be joined to system.mdw.


--
Joan Wild
Microsoft Access MVP


"Susan L" wrote:

I've searched the newsgroups on this topic and have come up with
answers that I have already addressed. The problem is that I am
able to open my "secured" file when using the default System.mdw.
(I'm using Access 2003) Plus, I followed Joan Wild's and Lynn
Trapps instructions closely. Maybe there's something I've
overlooked? 1) Created custom workgroup file, with a custom admin
user, "sradmin." 2) Logged on as SR admin & created password.
3) Logged on again as sradmin and created blank database into which
I imported all objects.
4) Verified that sradmin owns all objects including the database
itself. 5) Verified that the Users group has no privileges.
6) Moved the Admin user to the Users group.
7) Created shortcut for opening the secured database.

When I set up security before (Access 2000), whenever I double
clicked the database icon, I received a "no privileges" message.
The only way to get in was to use the shortcut. I originally
thought it might be my copy of Access at work, but the same thing
is happening on my home computer (Access 2003). Any suggestions?
--
susan



.

Relevant Pages

  • Re: Able to open secured database with default MDW
    ... Joan and David: I want to thank you both for your efforts to help me. ... The admin user can be in any other group in any other ... system workgroup that does have permission. ... All this and I can still get into the database directly when using ...
    (microsoft.public.access.security)
  • Re: Decompile a secured mdb
    ... It's not properly secured if the default Admin user can open the database. ... You should also remove the ability of the Users group to open the database. ... Don't give permissions to open/run those forms except to the groups that are ...
    (microsoft.public.access.security)
  • Re: Workgroup files and Open/Run in 2002
    ... >> joined to the standard system.mdw, then your database isn't secure. ... > the Admin account can't even be taken out of the Users group. ... The default group "Users" must have zero permissions and the default user ...
    (microsoft.public.access.security)
  • Re: to Joan Wild
    ... > Hi Joan, ... > sorry to bother... ... > If the new database will use the same .mdw file that is used for the secured ... > Admin through the system.mdw I built and saved a form. ...
    (microsoft.public.access.security)
  • Re: Database, its security and a server.
    ... Look in section 1 (What are the steps to help protect a database?). ... guessing you missed step 6 (Remove the Admin user from the Admins group so ... that Admin is a member only of the Users group.) ... But it does not ask for a log-in on anyone else's computer. ...
    (microsoft.public.access.security)