T
TC
That just means the property was not created with the DDL parameter set to
True.
HTH,
TC
True.
HTH,
TC
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
G
Gary Dikkema
Question Joan...
If I were to give a non admin user "Full Permissions" then that would allow
them the ability to flip the Bypass flag (similar to an Admin user) as well?
This is what I am seeing and am wondering if it's correct.
TIA.
Gary D
If I were to give a non admin user "Full Permissions" then that would allow
them the ability to flip the Bypass flag (similar to an Admin user) as well?
This is what I am seeing and am wondering if it's correct.
TIA.
Gary D
J
Joan Wild
Gary said:Question Joan...
If I were to give a non admin user "Full Permissions" then that would
allow them the ability to flip the Bypass flag (similar to an Admin
user) as well?
No that shouldn't do it. You'd need to make them a member of the Admins
group. Note that they would need to be a member of the Admins group *in the
mdw that was used to secure it with*, assuming you set it while logged in
using this mdw.
That might be confusing, but I generally don't ship the mdw that was used to
secure the mdb. I ship a separate mdw for production use. Therefore, the
Admins group is not the same as the mdw that was used to secure it with.
T
TC
Joan Wild said:No that shouldn't do it. You'd need to make them a member of the Admins
group. Note that they would need to be a member of the Admins group *in the
mdw that was used to secure it with*, assuming you set it while logged in
using this mdw.
(snip)
I've never checked, but I imagine that giving them Administer permission on
the database, would probably also allow it.
Cheers,
TC
G
Gary Dikkema
Hummmm...
A little background for you and for me to help understand your comments...
<VBG>...
I have been doing development on a couple of machines here plus I have a
WS2k3 TS Server where I host an Internet demo presence.
I have the application in it's own subfolder with the *.mdw file. I work on
one or the other machine and as significant milestones are achieved I copy
the folder from whichever Dev site to the TS box and to the other Dev site.
I then run thru the app after the copy to verify everything works. I had a
couple of errors and got back into the application and gave my non Admin
'power user' full permissions. After that, I noticed that user could also
flip the bypass flag (using that Utility).
I did this more than once to confirm my suspicions. I then also created a
new database and copied over everything, locked it down, tested it, then
again gave this user full permissions and again that user could flip the
bypass status.
And I was logged into the MDW file in this applications folder each time.
I find your last paragraph intriguing though... if you don't ship the MDW
that was used to secure it with the application, how does one gain access?
You must have a MD file on the system with the Users that will be using the
application already defined? And these Users already have the needed
permissions?
Guess I always thought the Users had to be members of the same /wrkgroup for
those permissions to work.
Maybe I need to read the security doc again...
A little background for you and for me to help understand your comments...
<VBG>...
I have been doing development on a couple of machines here plus I have a
WS2k3 TS Server where I host an Internet demo presence.
I have the application in it's own subfolder with the *.mdw file. I work on
one or the other machine and as significant milestones are achieved I copy
the folder from whichever Dev site to the TS box and to the other Dev site.
I then run thru the app after the copy to verify everything works. I had a
couple of errors and got back into the application and gave my non Admin
'power user' full permissions. After that, I noticed that user could also
flip the bypass flag (using that Utility).
I did this more than once to confirm my suspicions. I then also created a
new database and copied over everything, locked it down, tested it, then
again gave this user full permissions and again that user could flip the
bypass status.
And I was logged into the MDW file in this applications folder each time.
I find your last paragraph intriguing though... if you don't ship the MDW
that was used to secure it with the application, how does one gain access?
You must have a MD file on the system with the Users that will be using the
application already defined? And these Users already have the needed
permissions?
Guess I always thought the Users had to be members of the same /wrkgroup for
those permissions to work.
Maybe I need to read the security doc again...
G
Gary Dikkema
TC,
Yes, if I gave them Admins priviledges that would make them an Admin.
However, Full Permissions means to me just that. An Admins user has full
permissions... right?
TIA.
Gary D
Yes, if I gave them Admins priviledges that would make them an Admin.
However, Full Permissions means to me just that. An Admins user has full
permissions... right?
TIA.
Gary D
J
Joan Wild
Gary said:I then run thru the app after the copy to verify everything works. I
had a couple of errors and got back into the application and gave my
non Admin 'power user' full permissions. After that, I noticed that
user could also flip the bypass flag (using that Utility).
But is this user a member of the Admins group?
Guess I always thought the Users had to be members of the same
/wrkgroup for those permissions to work.
Maybe I need to read the security doc again...
Yes, it is covered in the FAQ:
33. I want users in other groups besides the Admins group to be able to
administer the db and add
accounts
J
Joan Wild
Gary said:Yes, if I gave them Admins priviledges that would make them an Admin.
What do you mean by this? 'Admin' and 'Admins' are the names of built-in
user/group in Access. Are you referring to these?
However, Full Permissions means to me just that. An Admins user has
full permissions... right?
Not necessarily.
G
Gary Dikkema
Sorry! Yes, one is a Group, the other a User account.
Oh... no?
Oh... no?
G
Gary Dikkema
Joan,
I see I missed a few points. Read inline please.
Saw that, was just about to get into that.
However, i am not adding anyone.
I was just commenting on your statement of using a different MDW.
I see I missed a few points. Read inline please.
Joan Wild said:But is this user a member of the Admins group?
No.
Yes, it is covered in the FAQ:
33. I want users in other groups besides the Admins group to be able to
administer the db and add
accounts
Saw that, was just about to get into that.
However, i am not adding anyone.
I was just commenting on your statement of using a different MDW.
J
Joan Wild
Gary said:Saw that, was just about to get into that.
However, i am not adding anyone.
Doesn't matter. The principle is the same. In your development mdw, you
create the groups and assign permissions to the groups. You create a
separate production mdw, and in it you create the exact same group names and
SIDs. The advantage is that no one in your production mdw will have the
same power as the user in the Admins Group of your development mdw (the
Admins group is different).
J
Joan Wild
Gary said:Sorry! Yes, one is a Group, the other a User account.
OK, but 'if you give them Admins priviledges' i.e. put them in the Admins
Group, that *does not* make them an Admin (i.e. the Admin user). I don't
follow what you're doing here.
Oh... no?
An Admins user doesn't necessarily have full permissions. The owner of an
object could remove permissions from the Admins group.
G
Gary Dikkema
I will check out 33.
Thanks again Joan!
Thanks again Joan!
Joan Wild said:Doesn't matter. The principle is the same. In your development mdw, you
create the groups and assign permissions to the groups. You create a
separate production mdw, and in it you create the exact same group names
and
SIDs. The advantage is that no one in your production mdw will have the
same power as the user in the Admins Group of your development mdw (the
Admins group is different).
G
Gary Dikkema
So it appears to be a double lock system.
I set up a Dev and a Distr set of MDW files.
I also rebuilt and recreated my database file using the Dev MDW. I set up
one group for this one application. I am beginning to think that I should
have done it a little different for a couple of reasons. It seems to re
secure the MDW I had to use an Admin user from when I originally created the
database. Secondly, no one in the created group can open anything in the
database. However, using the SiteAdmin account gives me full access but NO
ability to flip the Bypass flag.
Obviously my understanding of creating Groups my be a mistake. Maybe I
should have created users. I created a special group and then inside the
Distr MDW I created a few accounts there should have 'power' user access and
View only access. I gave them access to the Group I created and new, full
update etc. However, I didn't give Read access and can't seem to get
anywhere with these User ids.
But I am getting closer. No one can flip the Bypass flag...
Now to give Users access to the application.
I set up a Dev and a Distr set of MDW files.
I also rebuilt and recreated my database file using the Dev MDW. I set up
one group for this one application. I am beginning to think that I should
have done it a little different for a couple of reasons. It seems to re
secure the MDW I had to use an Admin user from when I originally created the
database. Secondly, no one in the created group can open anything in the
database. However, using the SiteAdmin account gives me full access but NO
ability to flip the Bypass flag.
Obviously my understanding of creating Groups my be a mistake. Maybe I
should have created users. I created a special group and then inside the
Distr MDW I created a few accounts there should have 'power' user access and
View only access. I gave them access to the Group I created and new, full
update etc. However, I didn't give Read access and can't seem to get
anywhere with these User ids.
But I am getting closer. No one can flip the Bypass flag...
Now to give Users access to the application.
T
TC
(snip)
Remember when you create a new user, you must enter a Personal Identifier or
PID for that user. (This is totally unrelated to the user's password.)
Access scrambles the username + PID. The result is called the Security
Identifier (or SID) for that user.
When Access notes which users own, and have permissions on, which objects in
the database, it uses the SIDs to identify the relevant users - not their
user names.
So if you have 10 different workgroup files, and each one has a user John
Smith who you created with PID 1234, all those John Smiths are
*indistinguishable* to Access, because they all have the same SID. So the
permissions that you applied for one of those John Smiths (in workgroup file
#3, for example), would automatically & instantly apply to each of the other
9 John Smiths.
If you added a new workgroup file and created another John Smith but with a
*different PID* - say 1235 - this John Smith would be a *totally different
person* to the other (10) John Smith(s), because he has a different PID, and
thus, a different SID.
By this clever means, you can distinguish between the following cases:
(1) An individual must be defined in several different workgroup files. (For
example, a single individual John Smith must be defined in several different
workgroup files.) In this case you would be sure to give those users the
same PID, so Access knows they are identical.
versus:
(2) Several different individuals who happen to have the same names, must be
defined in several different workgroup files. (For example, several
different John Smiths must be defined in several different workgroup files.)
In this case you would be sure to give those users *different* PIDs, so
Access knows that they are different users.
HTH,
TC
Guess I always thought the Users had to be members of the same /wrkgroup for
those permissions to work.
Remember when you create a new user, you must enter a Personal Identifier or
PID for that user. (This is totally unrelated to the user's password.)
Access scrambles the username + PID. The result is called the Security
Identifier (or SID) for that user.
When Access notes which users own, and have permissions on, which objects in
the database, it uses the SIDs to identify the relevant users - not their
user names.
So if you have 10 different workgroup files, and each one has a user John
Smith who you created with PID 1234, all those John Smiths are
*indistinguishable* to Access, because they all have the same SID. So the
permissions that you applied for one of those John Smiths (in workgroup file
#3, for example), would automatically & instantly apply to each of the other
9 John Smiths.
If you added a new workgroup file and created another John Smith but with a
*different PID* - say 1235 - this John Smith would be a *totally different
person* to the other (10) John Smith(s), because he has a different PID, and
thus, a different SID.
By this clever means, you can distinguish between the following cases:
(1) An individual must be defined in several different workgroup files. (For
example, a single individual John Smith must be defined in several different
workgroup files.) In this case you would be sure to give those users the
same PID, so Access knows they are identical.
versus:
(2) Several different individuals who happen to have the same names, must be
defined in several different workgroup files. (For example, several
different John Smiths must be defined in several different workgroup files.)
In this case you would be sure to give those users *different* PIDs, so
Access knows that they are different users.
HTH,
TC
T
TC
Gary, you need to be careful with exact usage of terms when you discuss
Access security. Otherwise, it all gets too confusing!
So, avoid terms like "Admis priviliges", or "an Admin". Those really are not
well-defined. Instead, use terms like: "A member of the Admins group of the
workgroup file that was used to create the database".
When I referred to "Administer permission", that is not a term that is
necessarily or closely related to being "an Admin" - whatever that means!
Administer permission is a specific permission, like Read Design permission,
or Delete Data permission. A suitably authorized user (say user A) could
assign "Administer permission", >on< a specified object (say the database
object), >to< some other specified user (say user B). That would not make A
or B "an Admin" (whatever that means!). But it might make user B able to
flip the database properties, despite >not< being a member of the Admins
group of the workgroup file that was used to create the database. (But I
might be wrong there.)
You are clearly very keen to learn more about Access security & understand
it very well. My advice would be, make sure you know which terms are
well-defined & have specific meanings - eg. "a member of the Admins group" -
and which do not - eg. "an Admin".
Also, whenever you talk about permissions - say Administer permission, or
Read Data permission - be sure to state the >user< and >object< to which
those permissions apply. Otherwise, it doesn't make sense. So:
"User A has Read Design permission on table T". Makes sense.
"User A has Read Design permission". On what object??
"Users have Read Design permission on table T". Which users??
Cheers,
TC
Access security. Otherwise, it all gets too confusing!
So, avoid terms like "Admis priviliges", or "an Admin". Those really are not
well-defined. Instead, use terms like: "A member of the Admins group of the
workgroup file that was used to create the database".
When I referred to "Administer permission", that is not a term that is
necessarily or closely related to being "an Admin" - whatever that means!
Administer permission is a specific permission, like Read Design permission,
or Delete Data permission. A suitably authorized user (say user A) could
assign "Administer permission", >on< a specified object (say the database
object), >to< some other specified user (say user B). That would not make A
or B "an Admin" (whatever that means!). But it might make user B able to
flip the database properties, despite >not< being a member of the Admins
group of the workgroup file that was used to create the database. (But I
might be wrong there.)
You are clearly very keen to learn more about Access security & understand
it very well. My advice would be, make sure you know which terms are
well-defined & have specific meanings - eg. "a member of the Admins group" -
and which do not - eg. "an Admin".
Also, whenever you talk about permissions - say Administer permission, or
Read Data permission - be sure to state the >user< and >object< to which
those permissions apply. Otherwise, it doesn't make sense. So:
"User A has Read Design permission on table T". Makes sense.
"User A has Read Design permission". On what object??
"Users have Read Design permission on table T". Which users??
Cheers,
TC
G
Gary Dikkema
Thanks!
I am keen to ensure my code is secure from being pilfered. <VBG>
Now to be a little more precise in terminology.
I am keen to ensure my code is secure from being pilfered. <VBG>
Now to be a little more precise in terminology.
J
Joan Wild
Gary said:Obviously my understanding of creating Groups my be a mistake. Maybe I
should have created users.
You'll find it easier to assign permissions to groups rather than users -
makes for easier maintenance.
I created a special group and then inside
the Distr MDW I created a few accounts there should have 'power' user
access and View only access. I gave them access to the Group I
created and new, full update etc. However, I didn't give Read access
and can't seem to get anywhere with these User ids.
That makes no sense to me. You can't grant update permissions and deny read
permissions.
G
Gary Dikkema
You're right! I've been doing this too long and some of it by rote as
opposed to using logic and common sense. <VBG>
Let me tinker some more. Thanks for staying with me Joan; I am beginning to
think I am as frustrating to this NG as the Security is to me.
<VBG>
opposed to using logic and common sense. <VBG>
Let me tinker some more. Thanks for staying with me Joan; I am beginning to
think I am as frustrating to this NG as the Security is to me.
<VBG>
G
Gary Dikkema
One of my challenges is tables created by the Owner, that a subsequent macro
will delete. However, the person invoking the macro will be a User and not
the Owner or an Admin User.
I suspect I can recreate the macro by either emptying the table and
appending or making that User the owner.
I favour making the User (non owner, non admin) the owner... then the macros
will all simply just run.
I can't seem to locate in the Macro any ability to run with the Owner's
credentials.
Comments?
will delete. However, the person invoking the macro will be a User and not
the Owner or an Admin User.
I suspect I can recreate the macro by either emptying the table and
appending or making that User the owner.
I favour making the User (non owner, non admin) the owner... then the macros
will all simply just run.
I can't seem to locate in the Macro any ability to run with the Owner's
credentials.
Comments?
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.