Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsFormsForms ProgrammingQueriesModules / DAO / VBAReports / PrintingMacrosDatabase DesignSecurityConversionImporting / LinkingSQL Server / ADPMultiuser / NetworkingReplicationSetup / ConfigurationDeveloper ToolkitsActiveX ControlsNew UsersGeneral 1General 2
Access DirectoryToolsTutorialsUser Groups
Related Topics
SQL ServerOther DB ProductsMS OfficeMore Topics ...

MS Access Forum / Security / December 2007

Tip: Looking for answers? Try searching our database.

SID, Container and Document object

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Paul - 22 Dec 2007 17:29 GMT
I understand permissions that control access to objects can be written/read
via the Container/Document objects. When users and groups are added to the
workgroup file, SIDs are created for each. When I create a group (Employees)
and assign explicit permissions to that group on selected database objects, I
assume SID entries are created in the database (corresponding Document
objects) to reflect this. My questions are:
1) Are SID entries created for every object in the database, even on those
objects that I did not specify any access?
2)When I add a user (Bob) to that group and don't assign any explicit
permissions to Bob, are new SIDs entries created for all the objects in my
database for this user even though no explicit permissions were assigned?

I have developed a database and deployed to several customers. During
development I am using a workgroup file that contains employee names from
separate customers and even dummy names for testing purposes (note that I
have not assigned any explicit permissions to any of these users, they are
all members of Employees). My concern is that when I deliver my update to my
different customers, does the database contain all of these useless SIDs?

This leads to the next question. I know I can delete all of these SIDs by
importing to a blank database. In this case what happens when I install the
update at my customer who has a workgroup file with a bunch of employees that
I don't have in my workgroup file? This leads me to believe that SID entries
are only created in the database for users (and groups) that have been
assigned explicit permissions, otherwise, could they be created when that
user logs in (somehow I doubt that, but you never now)?

I have tried pretty hard to research this, but am coming up empty.

Thank you in advance!
Paul
Joan Wild - 23 Dec 2007 14:13 GMT
>I understand permissions that control access to objects can be written/read
> via the Container/Document objects. When users and groups are added to the
[quoted text clipped - 4 lines]
> 1) Are SID entries created for every object in the database, even on those
> objects that I did not specify any access?

No I don't believe so.

> 2)When I add a user (Bob) to that group and don't assign any explicit
> permissions to Bob, are new SIDs entries created for all the objects in my
> database for this user even though no explicit permissions were assigned?

No.

> I have developed a database and deployed to several customers. During
> development I am using a workgroup file that contains employee names from
> separate customers and even dummy names for testing purposes (note that I
> have not assigned any explicit permissions to any of these users, they are
> all members of Employees). My concern is that when I deliver my update to my
> different customers, does the database contain all of these useless SIDs?

No.

> This leads to the next question. I know I can delete all of these SIDs by
> importing to a blank database.

No you can't; SIDs are stored in the mdw, not the mdb.  By importing, you lose *all* permissions, even those set on groups.

what happens when I install the
> update at my customer who has a workgroup file with a bunch of employees that
> I don't have in my workgroup file? This leads me to believe that SID entries
> are only created in the database for users (and groups) that have been
> assigned explicit permissions, otherwise, could they be created when that
> user logs in (somehow I doubt that, but you never now)?

That is why it's a good idea to manage permissions based on groups rather than users.  Users will inherit the permissions from the group - no need to assign explicit permissions on a user.

Also, assuming you have split the mdb, you will most likely be updating the frontend - and the permissions wil be stored in that mdb.

Signature

Joan Wild
Microsoft Access MVP

Paul - 23 Dec 2007 15:52 GMT
Thank you for your reply. I am afraid I was unclear by saying "SID entries".

I will try to explain differently. When I import my database to a blank
database, all security is deleted from the imported database. That
information that was in the original database is deleted. I believe that info
is stored in the MSysACEs table.  My question is... when I add new users to
the mdw file and don't assign them any explicit permissions, are new records
added to the MSysACE table. In other words if I have 700 objects and 100
users (with no explicit permissions) will I have 70,000 records in this table?

Thank You!
Paul

> >I understand permissions that control access to objects can be written/read
> > via the Container/Document objects. When users and groups are added to the
[quoted text clipped - 37 lines]
>
> Also, assuming you have split the mdb, you will most likely be updating the frontend - and the permissions wil be stored in that mdb.
david@epsomdotcomdotau - 26 Dec 2007 05:57 GMT
When you add new users to the mdw file, no changes at all are made to the
mdb.

When you alter the permissions in the mdb, no changes at all are made to the
mdw.

Users are stored in the mdw. Permissions are stored in the mdb. Adding
users does not add permissions.

If you give permissions in the mdb to a group in an mdw, all members of
that group have those permissions. Adding or removing members of the
group in the mdw have no effect on the mdb. All users are members of
the USERS group. You can't remove that.

If you strip out of the MDB all removable permissions, the only
permissions remaining will be the permissions given to the OWNER
(which you can't remove) and to members of the original ADMINS
group, that is the ADMINS group used to create the MDB, which
you also can't remove.

If you have 100 users with no other group membership, they will be
members only of the USERS group (you can't remove that).  If they
have no explicit permissions, they will only have the permissions given
to the USERS group.

If you remove all removable permissions from the MDB, users who
are only members of the USERS group will have no permissions. If
you add 100 more members to the USERS group, that is if you add
100 more members to the MDW, they will all still have no permissions.

If you add individual permissions to individual mdb objects for each
of those individual users, then you will eventually increase the size of
the mdb by a small amount.

(david)

> Thank you for your reply. I am afraid I was unclear by saying "SID entries".
>
[quoted text clipped - 48 lines]
> >
> > That is why it's a good idea to manage permissions based on groups rather than users.  Users will inherit the permissions from the group - no
need to assign explicit permissions on a user.

> > Also, assuming you have split the mdb, you will most likely be updating the frontend - and the permissions wil be stored in that mdb.
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.