Permissions Keep Changing

[Janet]

About a year ago, I set up User Level Security per some step-by-step
instructions I found from the internet. I set up different groups with
different permission levels, and assigned each user (we have about 90 users)
to the appropriate group. I then removed the Admin user from the Admins
group, placed Admin in the Users group, assigned a password to the Admin
user, as well. I then eliminated all permissions from the Users group. This
seemed to work out well. All users have been getting the correct access, no
problems.

There are only 2 persons with permissions to do everything in the database
(design, delete records, and modify permissions) -- myself and the IT
Director. No one knows anyone else's passwords because I have a button where
the users changes his/her password as often as they like to whatever they
like. I don't have the IT Director's password, and she doesn't have mine --
so there is no password sharing.

No one (except IT Director and myself) can delete any data from the
database. There is a frontend and backend, and data can only be deleted from
the backend tables.

Recently, there have been some odd things happening with the data -- mainly
records disappearing. I have audit tables, too, and when the records
disappear, all related insert/modify records in the audit table disappear as
well. Kinda looked like someone deleted records, then deleted any evidence
the records were there. BUT, the evidence that the records was there because
there was still related data in other tables, once connected to the client id
that had been deleted.

I was puzzled by the fact that records were being deleted when no one had
permission to do so except myself and the IT Dir. Neither of us were doing
this. I looked at the permissions, and it had all been changed, where most
of the groups had permission to delete records. AND -- ALL the User group
permissions (that I so carefully removed a year ago) had been restored.

I fixed all the permissions the way they were supposed to be, and eliminated
all permissions from the Users group. Records continued to be deleted. I
checked the permissions again, and the Users group had again been restored.
I removed permissions from that group again. Records still were being
deleted.

I looked at the hidden system tables, and saw that the Users group had full
permissions for all of the System tables, so I deleted permissions from the
Users group for the system tables. I had to GIVE "read" permission to all of
the groups for the MSysAccessObjects, MSysObjects, and MSysQueries tables in
order for staff to use the database.

The reason I did this is because a couple of months ago, one of our staff
suddenly couldn't open the database. When I watched her try to open it, her
computer attempted to bypass the login screen to open the database directly,
but instead she got an error message saying something like she didn't have
design permissions for MSysAccessObjects -- and she could not get in. One of
the IT people found something from Microsoft about how hackers try to use the
Admin user to get in the database, like a "backdoor" entrance -- so I thought
there might have been some vb code on her computer that was attempting to
bypass the login and go straight into the computer as the Admin user, but
failed because I had the Admin user disabled in the Users group. IT worked
on this person's computer for a long time, could NEVER get it to be able to
open an access database, and finally had to trash it. It wasn't just a
simple matter of not being connected to the wrong workgroup, it wouldn't open
any database due to "you don't have design permissions for MSysAccessObject"
(or something to that effect). So, when I saw the Users group having
permission to MSysAccessObject (knowing that the Admin user is part of the
Users group), I removed all permissions to the system tables from the Users
group.

A week later, the Users group had permissions restored to the system tables,
and it was removed from all the other groups. I removed permissions for
System tables from Users group, and restored it for the staff groups. A day
later, Users group had System table permissions again (that was yesterday),
so I removed again. So far, today, Users group does not have any permissions
to the systems table, but I keep checking throughout the day.

The IT Dir has been on vacation all week, and we both changed our passwords
just before she left. If someone is getting into the database on one of our
passwords, how could they get the password since we don't share with anyone?
Or, does Access automatically restore permissions to the Users group for
system tables after a day or so? If so or if not, how could records get
deleted when only the IT dir and myself have delete permissions (and she is
on vacation)? And how could all the other group permissions for delete get
restored when I painstakingly removed delete permissions a year ago to all
the tables? I'm stumped and not quite sure which way to proceed to get this
database secured.

Oh, I disabled the shift+enter key bypass on both front and backends. I
also unchecked all the boxes in the startup menu except for the db to open to
the main menu. I also password-protected all the modules. Does anyone
understand what's going on and/or how to fix it?

All advice greatly appreciated.

 

[Lynn Trapp]

Janet,
I believe Joan Wild told you, in another thread, that you should NOT be
attempting to do anything with permissions to System tables. That is a
dangerous practice.

--
Lynn Trapp
MS Access MVP
www.ltcomputerdesigns.com
Access Security: www.ltcomputerdesigns.com/Security.htm
Jeff Conrad's Big List: www.ltcomputerdesigns.com/JCReferences.html

 

[TC]

Well, here's my third (and last) try to help you fix your problem!

You'll get nowhere by:

(1) Listening to people who don't know what they're talking about ("One
of the IT people found something from Microsoft about how hackers try
to use the Admin user to get in the database, like a "backdoor"
entrance")

Or:

(2) Making false assumptions about how to fix the problem. ("So, when I
saw the Users group having permission to MSysAccessObject (knowing
that the Admin user is part of the Users group), I removed all
permissions to the system tables from the Users group.)

Instead, you need to:

(1) Get the db to a known state;

(2) *Do nothing more*, until the permissions have automagically changed
themselves, then

(3) Post back, describing (as best you can) exactly who did what in the
period between (1) and (2).

TC

 

[Joan Wild]

I've waited for others to respond, but now I'll add some more thoughts:

About a year ago, I set up User Level Security per some step-by-step
instructions I found from the internet. I set up different groups
with different permission levels, and assigned each user (we have
about 90 users) to the appropriate group. I then removed the Admin
user from the Admins group, placed Admin in the Users group, assigned
a password to the Admin user, as well. I then eliminated all
permissions from the Users group.

If that is the order you did things in, then it is quite possible that it
isn't secured properly, and someone is able to use it with the standard
system.mdw, and also possible they can change permissions.

Kinda looked like someone deleted records,
then deleted any evidence the records were there. BUT, the evidence
that the records was there because there was still related data in
other tables, once connected to the client id that had been deleted.

If you had set referential integrity on the relationship, then it would be
impossible to orphan records like this.

the database directly, but instead she got an error message saying
something like she didn't have design permissions for
MSysAccessObjects -- and she could not get in.

That is a sign of corruption. See this thread

http://groups.google.com/[email protected] WildMicrosoft Access MVP

 

[Jeff Conrad]

As posted in the thread (at least by my newsreader) Joan's link
will have problems. Use this short link to take you to the thread
Joan was talking about:

http://tinyurl.com/45knb

--
Jeff Conrad
Access Junkie
Bend, Oregon

in message:

I've waited for others to respond, but now I'll add some more thoughts:


If that is the order you did things in, then it is quite possible that it
isn't secured properly, and someone is able to use it with the standard
system.mdw, and also possible they can change permissions.


If you had set referential integrity on the relationship, then it would be
impossible to orphan records like this.


That is a sign of corruption. See this thread

http://groups.google.com/[email protected] WildMicrosoft Access MVP

 

[Joan Wild]

As posted in the thread (at least by my newsreader) Joan's link
will have problems. Use this short link to take you to the thread
Joan was talking about:

http://tinyurl.com/45knb

Thanks Jeff; something screwy about my signature. I'll try again:

http://groups.google.com/[email protected] WildMicrosoft Access MVP

 

[Jeff Conrad]

in message:

Thanks Jeff; something screwy about my signature. I'll try again:

I figured.
http://groups.google.com/[email protected]
WildMicrosoft Access MVP

And same result.

 

[Joan Wild]

And same result.

Anyone understand this? I'm hitting enter a couple of times after the URL.
http://groups.google.com/[email protected](I've saved as draft and it keeps doingthis)--JoanWildMicrosoftAccess MVP

 

[Jeff Conrad]

in message:

Anyone understand this? I'm hitting enter a couple of times after the URL.

Does it happen if you press Enter several times before the sig, back
up a couple of lines, and then paste the link?

Or are you pasting the link, hitting Enter a couple of times, and then
going to Insert | Signature?

 

[Joan Wild]

Does it happen if you press Enter several times before the sig, back
up a couple of lines, and then paste the link?

Or are you pasting the link, hitting Enter a couple of times, and then
going to Insert | Signature?

I've tried both and the same thing happens. I don't use Insert|Sig; it's
automatically inserted when I start a reply.

 

[Jeff Conrad]

in message:

I've tried both and the same thing happens.

Weird, I cannot seem to reproduce this.
However, I do not actually hit "Send" in my tests.

I don't use Insert|Sig; it's automatically inserted when I start a reply.

I did not think so, but it just crossed my mind as a possibility.
Strange.

 

[Janet]

Well, TC, the people who didn't know what they were talking about were
Microsoft, as I had read that in an article from Microsoft. You may or may
not be right about my assuming things about the Users group and System
tables. I don't know for sure yet.

I got the DB in a known state (again), and the permissions changed again
over the weekend. I have no idea of "who did what in the period inbetween"
which is WHY I am posting to this newsgroup. I am trying to find out "what
is happening" to cause my permissions to change.

Oh well, it doesn't seem that anyone there really has any idea of what to do
to solve this issue, so I won't take up your time with any more of this.
Thanks for trying, though.

 

[TC]

Well, TC, the people who didn't know what they were talking about were
Microsoft, as I had read that in an article from Microsoft.

Sorry, my reply was probably not very clear. You said that someone had
told you that "hackers can try to use the Admin user to get in the
database, like a backdoor entrance". I really only meant to say: "This
is not possible, if the database has been properly secured." Somehow,
that came out as: "&*$$% *&%^$# $#@# !!!"

I got the DB in a known state (again), and the permissions changed again
over the weekend. I have no idea of "who did what in the period inbetween"
which is WHY I am posting to this newsgroup. I am trying to find out "what
is happening" to cause my permissions to change.

Ok, so now we have a known state, to take this further. You did not do
/anything/ such as adding or deleting users, or changing user
permissions yourself, or joining different workgroup files, in the
interim period - right?

Oh well, it doesn't seem that anyone there really has any idea of what to do
to solve this issue, so I won't take up your time with any more of this.
Thanks for trying, though.

Sure we can solve it! But we need to go step by step, not changing
/anything/ unless that is discussed "up front". With respect, your
previous attempts were not a success, because you kept making changes
that just caused more problems.

So, if both of us have the patience to follow this through, let's get
going!

I apologise if these questions have been answered before, but I'd like
to get the info. afresh, not go back through all the previous posts.

1. Is you db split into a front-end/back end structure?

2. Is there one BE, stored on a central server? If not, what?

3. Does each user of the FE have a seperate copy of the FE, on their
PC? If not, what?

4. Are you using a single workgroup file, stored on the central server?
If not, what?

5. Does each user start the system via a shortcut of the following form
(all on one line):

"full path to msaccess.exe"
"full path to FE on user's PC"
/wrkgrk "full path to wgf on server"

6. Do any users start the system by double-clicking a database file
(ie. not using a shortcut)?

7. Does any user use the workgroup administrator program manually?

8. How /exactly/ are you checking what permissions a given user has?
IOW, how do you know /for sure/, that someone's permissions have
changed?


Janet, believe me: if you follow this through in a discipled way, I
have no doubt that I can fix your problem! [takes deep breath at
foolish commitment]

Note that I can only get one session on the net, per day. Please take
that into account, when you check for replies.

Cheers,
TC

 

[Janet]

During the interim (this past weekend) the "User Group" permissions were
changed again on both front end and back ends to include ALL permissions for
MSysAccessObjects system table. The change also included removing "read"
permission to other groups for this system table. Several times, I have
removed all permissions from the Users group, including system table
permissions. To enable my other groups to use the database, I had to give to
these groups "read" permission for the MSysAccessObjects system table.
Several times, this has gotten changed back where Users group gets full
permissions to MSysAccessObjects table and my created groups get the "read"
permission to this system table removed. So, last Friday, I removed all
permissions from Users group to the MSysAccessObject table, giving "read"
permission to my created groups to this system table. On Monday when I
returned, Users group again has FULL permissions to MSysAccessObjects, and my
created groups had their "read" permission removed. I don't know how this is
happening -- someone doing it? Access doing it automatically? I have not
changed it again. I have left it where the Users group has full permissions
to the system table, but am not comfortable with it -- but haven't changed it
back since I'm getting so much flack for messing with the system tables. But
my question is: how does this keep changing back over the weekend, when I do
NOTHING to the database over the weekend (am not even here) -- but other
users are here on the weekend....

Sorry, my reply was probably not very clear. You said that someone had
told you that "hackers can try to use the Admin user to get in the
database, like a backdoor entrance". I really only meant to say: "This
is not possible, if the database has been properly secured." Somehow,
that came out as: "&*$$% *&%^$# $#@# !!!"



Ok, so now we have a known state, to take this further. You did not do
/anything/ such as adding or deleting users, or changing user
permissions yourself, or joining different workgroup files, in the
interim period - right?



Sure we can solve it! But we need to go step by step, not changing
/anything/ unless that is discussed "up front". With respect, your
previous attempts were not a success, because you kept making changes
that just caused more problems.

So, if both of us have the patience to follow this through, let's get
going!

I apologise if these questions have been answered before, but I'd like
to get the info. afresh, not go back through all the previous posts.

1. Is you db split into a front-end/back end structure?

YES, I have a back with data and a front with forms, queries, etc.

2. Is there one BE, stored on a central server? If not, what?

There is one BE and one FE, both stored on a network drive.

3. Does each user of the FE have a seperate copy of the FE, on their
PC? If not, what? NO. There is one FE on a network drive that all users have access to. I have to upgrade the db at least weekly, so it would be impossible to go around and upgrade each person's desktop version since there are about 80 different persons who could be using this database (though usually only about 10 people are in it at one time).

4. Are you using a single workgroup file, stored on the central server?
If not, what? YES a single workgroup file stored on a central server.

5. Does each user start the system via a shortcut of the following form
(all on one line):

"full path to msaccess.exe"
"full path to FE on user's PC"
/wrkgrk "full path to wgf on server"

NO -- Each user simply has a shortcut icon on their desktop, from
right-clicking the front-end file, and choosing "Send to Desktop as
Shortcut."


6. Do any users start the system by double-clicking a database file

(ie. not using a shortcut)? Probably so - thinking about my answer to #5 above -- but it's a short-cut to the file, not the file itself. Does that matter?

7. Does any user use the workgroup administrator program manually? I do, and the IT Director could if she wanted (though she says she doesn't). I have the FE setup to that the tools menu is not in the Startup options so regular users can't click Tools, Security, Workgroup Administrator, and I have the shift+enter key disabled, so they can't get to it that way. Is this what you mean?

8. How /exactly/ are you checking what permissions a given user has?
IOW, how do you know /for sure/, that someone's permissions have
changed? I open the db, go to tools/security/permissions and look at each group and what permissions are set for what tables/forms/queries/macros, etc.


Janet, believe me: if you follow this through in a discipled way, I
have no doubt that I can fix your problem! [takes deep breath at
foolish commitment] --No foolish commitment here -- this is my job and I want to keep it -- not by letting the db security be compromised either by my ignorance malicious intent by some user or hacker.

Note that I can only get one session on the net, per day. Please take
that into account, when you check for replies.

Cheers,
TC

Thank you so much TC, and I will hang in here and learn what I can from you.
Just so you will know, I am mostly self-taught in Access over the past 5
years -- have taken a couple of one-day seminars, but found I already knew
what was being taught (and more) -- though self-learning has its draw--backs
because some things are missed that are critical. Thanks again and will
watch for your reply.

 

[Paul Overway]

Aside from questioning whether you've properly secured the database to begin
with, the next thing I'd look at would be how strong is the password you are
using to administer it? There are a variety of hacks that will analyze an
MDW and crack weak passwords. If one of your users has such a utility,
obviously they can log in as you and change the permissions to whatever they
like. FWIW...the hacks that I've seen have trouble cracking passwords
beyond 16 characters, and the inclusion of upper ASCII and/or quotes or
other characters that are troublesome to Jet SQL seem to trip them up...but
no doubt they'll figure that out at some point as well.

USL will keep honest people out, but don't rely on it to guard Fort Knox or
against determined hackers.

--
Paul Overway
Logico Solutions
http://www.logico-solutions.com

During the interim (this past weekend) the "User Group" permissions were
changed again on both front end and back ends to include ALL permissions
for
MSysAccessObjects system table. The change also included removing "read"
permission to other groups for this system table. Several times, I have
removed all permissions from the Users group, including system table
permissions. To enable my other groups to use the database, I had to give
to
these groups "read" permission for the MSysAccessObjects system table.
Several times, this has gotten changed back where Users group gets full
permissions to MSysAccessObjects table and my created groups get the
"read"
permission to this system table removed. So, last Friday, I removed all
permissions from Users group to the MSysAccessObject table, giving "read"
permission to my created groups to this system table. On Monday when I
returned, Users group again has FULL permissions to MSysAccessObjects, and
my
created groups had their "read" permission removed. I don't know how this
is
happening -- someone doing it? Access doing it automatically? I have not
changed it again. I have left it where the Users group has full
permissions
to the system table, but am not comfortable with it -- but haven't changed
it
back since I'm getting so much flack for messing with the system tables.
But
my question is: how does this keep changing back over the weekend, when I
do
NOTHING to the database over the weekend (am not even here) -- but other
users are here on the weekend....

Sorry, my reply was probably not very clear. You said that someone had
told you that "hackers can try to use the Admin user to get in the
database, like a backdoor entrance". I really only meant to say: "This
is not possible, if the database has been properly secured." Somehow,
that came out as: "&*$$% *&%^$# $#@# !!!"



Ok, so now we have a known state, to take this further. You did not do
/anything/ such as adding or deleting users, or changing user
permissions yourself, or joining different workgroup files, in the
interim period - right?



Sure we can solve it! But we need to go step by step, not changing
/anything/ unless that is discussed "up front". With respect, your
previous attempts were not a success, because you kept making changes
that just caused more problems.

So, if both of us have the patience to follow this through, let's get
going!

I apologise if these questions have been answered before, but I'd like
to get the info. afresh, not go back through all the previous posts.

1. Is you db split into a front-end/back end structure?

YES, I have a back with data and a front with forms, queries, etc.

2. Is there one BE, stored on a central server? If not, what?

There is one BE and one FE, both stored on a network drive.

3. Does each user of the FE have a seperate copy of the FE, on their
PC? If not, what? NO. There is one FE on a network drive that all users
have access to. I have to upgrade the db at least weekly, so it would be
impossible to go around and upgrade each person's desktop version since
there are about 80 different persons who could be using this database
(though usually only about 10 people are in it at one time).

4. Are you using a single workgroup file, stored on the central server?
If not, what? YES a single workgroup file stored on a central server.

5. Does each user start the system via a shortcut of the following form
(all on one line):

"full path to msaccess.exe"
"full path to FE on user's PC"
/wrkgrk "full path to wgf on server"

NO -- Each user simply has a shortcut icon on their desktop, from
right-clicking the front-end file, and choosing "Send to Desktop as
Shortcut."


6. Do any users start the system by double-clicking a database file

(ie. not using a shortcut)? Probably so - thinking about my answer to #5
above -- but it's a short-cut to the file, not the file itself. Does that
matter?

7. Does any user use the workgroup administrator program manually? I do,
and the IT Director could if she wanted (though she says she doesn't). I
have the FE setup to that the tools menu is not in the Startup options so
regular users can't click Tools, Security, Workgroup Administrator, and I
have the shift+enter key disabled, so they can't get to it that way. Is
this what you mean?

8. How /exactly/ are you checking what permissions a given user has?
IOW, how do you know /for sure/, that someone's permissions have
changed? I open the db, go to tools/security/permissions and look at
each group and what permissions are set for what
tables/forms/queries/macros, etc.


Janet, believe me: if you follow this through in a discipled way, I
have no doubt that I can fix your problem! [takes deep breath at
foolish commitment] --No foolish commitment here -- this is my job and I
want to keep it -- not by letting the db security be compromised either
by my ignorance malicious intent by some user or hacker.

Note that I can only get one session on the net, per day. Please take
that into account, when you check for replies.

Cheers,
TC

Thank you so much TC, and I will hang in here and learn what I can from
you.
Just so you will know, I am mostly self-taught in Access over the past 5
years -- have taken a couple of one-day seminars, but found I already knew
what was being taught (and more) -- though self-learning has its
draw--backs
because some things are missed that are critical. Thanks again and will
watch for your reply.

 

[Janet]

Thanks Paul, this helps. My Administer password is likely weak. I'll also
relay this to the IT Director (who also has full administer permissions) so
she can be sure her password is strong. Thanks so much.

Aside from questioning whether you've properly secured the database to begin
with, the next thing I'd look at would be how strong is the password you are
using to administer it? There are a variety of hacks that will analyze an
MDW and crack weak passwords. If one of your users has such a utility,
obviously they can log in as you and change the permissions to whatever they
like. FWIW...the hacks that I've seen have trouble cracking passwords
beyond 16 characters, and the inclusion of upper ASCII and/or quotes or
other characters that are troublesome to Jet SQL seem to trip them up...but
no doubt they'll figure that out at some point as well.

USL will keep honest people out, but don't rely on it to guard Fort Knox or
against determined hackers.

--
Paul Overway
Logico Solutions
http://www.logico-solutions.com

During the interim (this past weekend) the "User Group" permissions were
changed again on both front end and back ends to include ALL permissions
for
MSysAccessObjects system table. The change also included removing "read"
permission to other groups for this system table. Several times, I have
removed all permissions from the Users group, including system table
permissions. To enable my other groups to use the database, I had to give
to
these groups "read" permission for the MSysAccessObjects system table.
Several times, this has gotten changed back where Users group gets full
permissions to MSysAccessObjects table and my created groups get the
"read"
permission to this system table removed. So, last Friday, I removed all
permissions from Users group to the MSysAccessObject table, giving "read"
permission to my created groups to this system table. On Monday when I
returned, Users group again has FULL permissions to MSysAccessObjects, and
my
created groups had their "read" permission removed. I don't know how this
is
happening -- someone doing it? Access doing it automatically? I have not
changed it again. I have left it where the Users group has full
permissions
to the system table, but am not comfortable with it -- but haven't changed
it
back since I'm getting so much flack for messing with the system tables.
But
my question is: how does this keep changing back over the weekend, when I
do
NOTHING to the database over the weekend (am not even here) -- but other
users are here on the weekend....

Janet wrote:

Well, TC, the people who didn't know what they were talking about
were
Microsoft, as I had read that in an article from Microsoft.

Sorry, my reply was probably not very clear. You said that someone had
told you that "hackers can try to use the Admin user to get in the
database, like a backdoor entrance". I really only meant to say: "This
is not possible, if the database has been properly secured." Somehow,
that came out as: "&*$$% *&%^$# $#@# !!!"


I got the DB in a known state (again), and the permissions changed
again
over the weekend. I have no idea of "who did what in the period
inbetween"
which is WHY I am posting to this newsgroup. I am trying to find out
"what
is happening" to cause my permissions to change.

Ok, so now we have a known state, to take this further. You did not do
/anything/ such as adding or deleting users, or changing user
permissions yourself, or joining different workgroup files, in the
interim period - right?


Oh well, it doesn't seem that anyone there really has any idea of
what to do
to solve this issue, so I won't take up your time with any more of
this.
Thanks for trying, though.

Sure we can solve it! But we need to go step by step, not changing
/anything/ unless that is discussed "up front". With respect, your
previous attempts were not a success, because you kept making changes
that just caused more problems.

So, if both of us have the patience to follow this through, let's get
going!

I apologise if these questions have been answered before, but I'd like
to get the info. afresh, not go back through all the previous posts.

1. Is you db split into a front-end/back end structure?

YES, I have a back with data and a front with forms, queries, etc.

2. Is there one BE, stored on a central server? If not, what?

There is one BE and one FE, both stored on a network drive.

3. Does each user of the FE have a seperate copy of the FE, on their
PC? If not, what? NO. There is one FE on a network drive that all users
have access to. I have to upgrade the db at least weekly, so it would be
impossible to go around and upgrade each person's desktop version since
there are about 80 different persons who could be using this database
(though usually only about 10 people are in it at one time).

4. Are you using a single workgroup file, stored on the central server?
If not, what? YES a single workgroup file stored on a central server.

5. Does each user start the system via a shortcut of the following form
(all on one line):

"full path to msaccess.exe"
"full path to FE on user's PC"
/wrkgrk "full path to wgf on server"

NO -- Each user simply has a shortcut icon on their desktop, from
right-clicking the front-end file, and choosing "Send to Desktop as
Shortcut."


6. Do any users start the system by double-clicking a database file

(ie. not using a shortcut)? Probably so - thinking about my answer to #5
above -- but it's a short-cut to the file, not the file itself. Does that
matter?

7. Does any user use the workgroup administrator program manually? I do,
and the IT Director could if she wanted (though she says she doesn't). I
have the FE setup to that the tools menu is not in the Startup options so
regular users can't click Tools, Security, Workgroup Administrator, and I
have the shift+enter key disabled, so they can't get to it that way. Is
this what you mean?

8. How /exactly/ are you checking what permissions a given user has?
IOW, how do you know /for sure/, that someone's permissions have
changed? I open the db, go to tools/security/permissions and look at
each group and what permissions are set for what
tables/forms/queries/macros, etc.


Janet, believe me: if you follow this through in a discipled way, I
have no doubt that I can fix your problem! [takes deep breath at
foolish commitment] --No foolish commitment here -- this is my job and I
want to keep it -- not by letting the db security be compromised either
by my ignorance malicious intent by some user or hacker.

Note that I can only get one session on the net, per day. Please take
that into account, when you check for replies.

Cheers,
TC

Thank you so much TC, and I will hang in here and learn what I can from
you.
Just so you will know, I am mostly self-taught in Access over the past 5
years -- have taken a couple of one-day seminars, but found I already knew
what was being taught (and more) -- though self-learning has its
draw--backs
because some things are missed that are critical. Thanks again and will
watch for your reply.

 

[TC]

There are a variety of hacks that will analyze an
MDW and crack weak passwords.

They don't have to be weak. It is not a dictionary or brute-force
crack. All user-level passwords are instantly decryptable, due to a
coding error in the encryption. This could be fixed by changing the
order of two parameters in the Jet sourcecode. Then, it would be
computationally impossible to retrieve the plaintext passwords from a
workgroup file. I have a change suggestion in to the Access team,
regarding this. It would be a significant improvement to Jet security,
IMHO.

Cheers,
TC

 

[TC]

Ok, I'll get back to you within 3 hours. I have to rush off for a
meeting now.

Cheers,
TC

 

[Paul Overway]

True...although the cracks I've seen seem to choke on anything over 16
characters (the 1st 16 are correct, but not after that...). Also, throwing
some high/low ascii characters in the mix seems to fluster them a little
too. I really can't see why they haven't issued a SP for this issue...they
could version MDWs to determine which algorithm to use (broken or more
secure). I've been working on securing an app, and this hole concerns me
somewhat.

 

[TC]

Janet, I have a way forward which will quickly tell us what is going
on.

First, I've made some general comments in a //seperate reply//. Those
comments are just for information at this stage. //Do not change
anything after reading those comments!//

Second, when you say that you open the db & the permissions have
changed:
- which db are you opening - the BE, or one of the FEs?
- exactly how do you open it?

Third, here is how to proceed right now.

1. Pick a table whose permissions are automagically changing. Make sure
it is a BE table, not an FE link to a table. Do not use a system table
- use one of your own tables.

2. Put all the permissions (on all your objects) back the way you want
them to be.

3. Immediately run the code below. NOTE: replace xxxxx with the name of
the table that you chose in step 1. To run the code:

- open the BE db;
- type Ctrl-g to go to the debug window;
- cut & paste the first command;
- put the cursor anywhere in that command;
- press Enter to run that command;
- note the output of that command, then
- repeat for the other commands.

Commands:

debug.print dbengine.systemdb
debug.print dbengine(0)(0).name
debug.print currentuser()
debug.print dbengine(0)(0).tabledefs![xxxxx].owner
debug.print hex$(dbengine(0)(0).tabledefs![xxxxx].allpermissions)

4. Close the db, let your users continue work, and wait for the
permissions to automagically change themselves.

5. Immediately repeat step 3, then

6. Post the output from steps 3. and 5.

Cheers,
TC