G
I have a few general questions. I am working on a new database to be
used within my company. I would like to give a couple of people,
particularly HR, the ability to add and delete Access users, and
add/remove them to groups, so as people join and leave the company,
they can be added/removed as database users at that time. However, I
don't want them to have to do it through the standard Access
users/groups interface, and I don't want any of the code or other
design details to be visible to them. I am aware of code (such as the
CreateUser command) to perform those functions via code, but I'm
assuming that the user that is logged in must have permissions to
administer users for the code to work. I've read the MS article 120911
about giving users ability to add users without viewing the design, but
I'm a bit confused by it. It states "Because Mary was not a member of
the Admins group in the system database in use when the database was
created, Mary will not have permissions on objects that already exist
in the database.". To me, this insinuates that Mary *WOULD* be able to
view the design of anything added to the database AFTER the point in
time she was added to the admins group. If I'm understanding this
correctly, this would mean that the user or group you wanted to be able
to administer users should not be given this capability until AFTER the
database is complete. Unfortunately, this is not practical for me, as
it will be in a constant state of development for a long time. I
expect, however, that I'm misunderstanding something.
What exactly gives a user or group permission to administer users? I
know how to assign various permission levels to various database
objects, but none of the options seem specific to administering users.
Is that an inherent ability to the built-in "Admins" group, regardless
of what permissions you give to the Admins group for various database
objects? If so, should I create a "developer" group, that actually has
permissions to everything, and strip the Admins group of permissions
related to design, and add those users that should be able to
administer users to the Admins group? Are there any other inherent
abilities invisibly given to the Admins group that would be a caveat to
adding non-developers to this group?
I also have a couple of other security related questions (I've not had
to worry about security too much in the past). I realize that Access
is not the most secure application. For the vast majority of our data,
the standard "good practices" should be sufficient. For standard
users, I plan on giving them user IDs that are the same as their
network log-in, and kicking them out of the database if someone tries
to log in to the database under a userID that doesn't match the account
they are logged in to the network under. But for more sensitive data,
I intend on creating a second back-end that will be located on a
security restricted network share, that only those that should have
access to the sensitive data can get to. Does this seem like a
reasonable approach? Are there any caveats to this?
TIA!
used within my company. I would like to give a couple of people,
particularly HR, the ability to add and delete Access users, and
add/remove them to groups, so as people join and leave the company,
they can be added/removed as database users at that time. However, I
don't want them to have to do it through the standard Access
users/groups interface, and I don't want any of the code or other
design details to be visible to them. I am aware of code (such as the
CreateUser command) to perform those functions via code, but I'm
assuming that the user that is logged in must have permissions to
administer users for the code to work. I've read the MS article 120911
about giving users ability to add users without viewing the design, but
I'm a bit confused by it. It states "Because Mary was not a member of
the Admins group in the system database in use when the database was
created, Mary will not have permissions on objects that already exist
in the database.". To me, this insinuates that Mary *WOULD* be able to
view the design of anything added to the database AFTER the point in
time she was added to the admins group. If I'm understanding this
correctly, this would mean that the user or group you wanted to be able
to administer users should not be given this capability until AFTER the
database is complete. Unfortunately, this is not practical for me, as
it will be in a constant state of development for a long time. I
expect, however, that I'm misunderstanding something.
What exactly gives a user or group permission to administer users? I
know how to assign various permission levels to various database
objects, but none of the options seem specific to administering users.
Is that an inherent ability to the built-in "Admins" group, regardless
of what permissions you give to the Admins group for various database
objects? If so, should I create a "developer" group, that actually has
permissions to everything, and strip the Admins group of permissions
related to design, and add those users that should be able to
administer users to the Admins group? Are there any other inherent
abilities invisibly given to the Admins group that would be a caveat to
adding non-developers to this group?
I also have a couple of other security related questions (I've not had
to worry about security too much in the past). I realize that Access
is not the most secure application. For the vast majority of our data,
the standard "good practices" should be sufficient. For standard
users, I plan on giving them user IDs that are the same as their
network log-in, and kicking them out of the database if someone tries
to log in to the database under a userID that doesn't match the account
they are logged in to the network under. But for more sensitive data,
I intend on creating a second back-end that will be located on a
security restricted network share, that only those that should have
access to the sensitive data can get to. Does this seem like a
reasonable approach? Are there any caveats to this?
TIA!