Can't read table permissions!

[Chris O''''Neill]

I have just started the process of securing an Access XP application I have
developed, and I have run into a problem. Here's the steps I've done so far:

1. Created a new workgroup file and saved in the same directory as my MDB
file.

2. Using the new workgroup file, I opened my MDB file using the default
Admin user.

3. I created a user account for myself, and assigned myself to the Admins
and Users groups. I also removed the Admin user from the Admins group. So,
now, I'm the only member of the Admins group.

4. I ran the Access XP User-level Security Wizard to back-up my MDB file
and create a new, secured MDB file. During that process, I did not create
any users (I'll do that programatically when new users first log onto the
system) or user groups (I want to do that manually).

The Wizard seemed to run fine.... no error messages or any other
indications of problems. I then shutdown Access, restarted it, and was able
to log-on using my new user account and password.

I then went to the User and Group Accounts section and created the groups I
want. Again, no apparent problems doing this.

Finally, I went into the User and Group Permissions section to start
assigning permissions to my groups. I immediately found one table where the
following error message popped up:

"You can't view this object's permissions. To view or change permissions
for this object, you must have Administrator permission for it."

I don't seem to have this problem with any other object in the database, at
least so far. I have confirmed that I am a member of the Admins group and
have full "Administer" rights to the database, including that table.

What's happening, and how do I correct it???

Any and all help will be greatly appreciated!

Regards, Chris

 

[Keith Wilby]

I have just started the process of securing an Access XP application I have
developed, and I have run into a problem. Here's the steps I've done so
far:

1. Created a new workgroup file and saved in the same directory as my MDB
file.

2. Using the new workgroup file, I opened my MDB file using the default
Admin user.

3. I created a user account for myself, and assigned myself to the Admins
and Users groups. I also removed the Admin user from the Admins group.
So,
now, I'm the only member of the Admins group.

4. I ran the Access XP User-level Security Wizard to back-up my MDB file
and create a new, secured MDB file. During that process, I did not create
any users (I'll do that programatically when new users first log onto the
system) or user groups (I want to do that manually).

The Wizard seemed to run fine.... no error messages or any other
indications of problems. I then shutdown Access, restarted it, and was
able
to log-on using my new user account and password.

I then went to the User and Group Accounts section and created the groups
I
want. Again, no apparent problems doing this.

Finally, I went into the User and Group Permissions section to start
assigning permissions to my groups. I immediately found one table where
the
following error message popped up:

"You can't view this object's permissions. To view or change permissions
for this object, you must have Administrator permission for it."

I don't seem to have this problem with any other object in the database,
at
least so far. I have confirmed that I am a member of the Admins group and
have full "Administer" rights to the database, including that table.

What's happening, and how do I correct it???

Any and all help will be greatly appreciated!

Regards, Chris

It looks to me like you missed at least one step because, based on your
description, you won't be the database object's owner, "Admin" will. You
should have created a new, blank database file whilst logged in as your
custom admin user and imported all objects into it. You would then have
been the owner of the objects instead of "Admin".

Go back to the backup that the wizard (should have) created and follow all
of the steps in the FAQ (link on my web site). You need to follow *all*
steps in the order stated.

Regards,
Keith.
www.keithwilby.com

 

[Joan Wild]

As Keith said you missed a step between 3 and 4. Also, don't change the
permissions on any Msys objects.

 

[Chris O''''Neill]

Thank you, Keith (and Joan), for the quick reply. I've had a busy day and
haven't had a chance to persue your suggestions, but I did notice last night
that the db is owned by "Admin" and not my new account. I was working from
the MS Access Security FAQ and didn't think I had missed something, but it
was late so that's a definate possibility.

Anyway, I'll go start over later tonight, and will post another message
reporting on my progress.

Thanks, again, for your help...

Regards, Chris

 

[Chris O''''Neill]

It looks to me like you missed at least one step because, based on your
description, you won't be the database object's owner, "Admin" will. You
should have created a new, blank database file whilst logged in as your
custom admin user and imported all objects into it. You would then have
been the owner of the objects instead of "Admin".

Go back to the backup that the wizard (should have) created and follow all
of the steps in the FAQ (link on my web site). You need to follow *all*
steps in the order stated.

Instead of reading the MS Access Security FAQ online, as I did last night,
tonight I printed it out and followed it closely. I should note that the FAQ
does not talk about creating a blank database and importing all objects into
it. Rather, the FAQ says that the Security Wizard does this for you, and I
ran the Wizard last night. So, all I can think of is that I ran the Security
Wizard while still logged in as Admin instead of my new user account, so the
Wizard created the new database with Admin as the owner.

Anyway....

I successfully created the secured database by manually importing the object
into the new database *after* I reassured myself that it was owned by the new
user account. That has fixed the "Can't view the object's permissions" error
message. Thank you VERY much for that assistance!

While I have your attention, I have another question...

I have locked down my front end database by removing Admin from the Admins
group and removing all permissions from the Users group. So, anybody trying
to get in using a generic system.mdw file is going to be out of luck.
(Tomorrow night, I'll start setting up the new group accounts in my custom
MDW file.)

I'm now thinking about the back end database. I understand from the FAQ
that the permissions I applied to the links in the front end don't effect
the actual permissions on the back end which, right now is wide open. I also
understand from the FAQ that if I totally lock down the back end I'll have to
use RWOP queries to access the data.

What I'm wondering is if I duplicate the custom group accounts in both the
front and back end will users be able to access the data from my front end
but someone won't be able to open the back end using a generic MDW file? My
gut tells me that will work, but then again my gut was telling me I was on
the right path last night. (Grin!)

Thanks, again, for your advice and assistance. MUCH appreciated!

Regards, Chris

 

[Keith Wilby]

What I'm wondering is if I duplicate the custom group accounts in both the
front and back end will users be able to access the data from my front end
but someone won't be able to open the back end using a generic MDW file?
My
gut tells me that will work, but then again my gut was telling me I was on
the right path last night. (Grin!)

You don't need to duplicate anything. All you need to do is join your
custom workgroup and import your BE tables into a new, blank database file.
You can then either assign permissions to the tables using you existing
users/groups or assign no permissions and use RWOP queries in the FE.
Remember to relink the FE to the new BE file too of course

It's also worth testing your security by attempting to open the db file from
an explorer window whilst joined to the default "system.mwd" workgroup. You
should get an access denied message.

Regards,
Keith.
www.keithwilby.com

 

[Joan Wild]

What I'm wondering is if I duplicate the custom group accounts in both the
front and back end will users be able to access the data from my front end
but someone won't be able to open the back end using a generic MDW file?
My
gut tells me that will work, but then again my gut was telling me I was on
the right path last night. (Grin!)

Account information is not stored in either the frontend or the backend -
only the permissions are stored in the mdb file. It's the mdw file that
stores usernames/passwords/groups/group membership information. So the key
is to use the same secure mdw to secure both the FE and BE.

 

[Chris O''''Neill]

You don't need to duplicate anything. All you need to do is join your
custom workgroup and import your BE tables into a new, blank database file.
You can then either assign permissions to the tables using you existing
users/groups or assign no permissions and use RWOP queries in the FE.
Remember to relink the FE to the new BE file too of course

Actually, that's exactly what I meant... do the same process (import into
new table using new MDW file) on the BE as I did on the FE. Thanks for
confirming that'll work. (Thought I'd better check before I get too crazy
locking things down. Wouldn't wanna lock myself out of something too!
<Grin!>)

Btw, I don't think I'm going to get too "fancy" with the security in the BE.
Just want to make sure that any-old-body can't open it with Windows Explorer
and wander around.

It's also worth testing your security by attempting to open the db file from
an explorer window whilst joined to the default "system.mwd" workgroup. You
should get an access denied message.

Tested that on the FE database already. Worked great! Thanks, again, for
your assistance!

Regards, Chris

 

[Chris O''''Neill]

Account information is not stored in either the frontend or the backend -
only the permissions are stored in the mdb file. It's the mdw file that
stores usernames/passwords/groups/group membership information. So the key
is to use the same secure mdw to secure both the FE and BE.

Right! That concept is a bit tricky go grasp at first, but I think I've got
it now. Thank you for all your assistance!

Regards, Chris

 

[Chris O''''Neill]

Btw....

As Keith said you missed a step between 3 and 4. Also, don't change the
permissions on any Msys objects.

Haven't seen any Msys objects (yet). I'm assuming those are the internal
tables Access uses? Betcha it makes a *real* mess if one mucks with them!

Regards, Chris

 

[Graham Wideman [Visio MVP]]

Hi Chris:

If you 're just getting started on Access security it's a bit mystifying.
You might find this article helpful:

http://grahamwideman.com/gw/tech/access/accesssec/index.htm

Graham