creating workgroupfile for remote administration

  • Thread starter Thread starter Jesper Fjølner
  • Start date Start date
J

Jesper Fjølner

I have a well-functioning secured database, but now I'm trying to create a
workgroup file allowing a trusted user to add/delete other users.

I originally created an mdw-file called "developer.mdw" with the groups:
AppAdmins, AppUsers, Developer. I'm in the "Developer" group as the only one
and I'm the owner of the database.
I use AppAdmins and AppUsers mainly to discriminate between users.

The SecFAQ says to create another file for distribution with the database in
this scenario. I'll call this "user.mdw".
The SecFAQ says to recreate this manually. But couldn't I just copy
"developer.mdw" into "user.mdw" and change the new "user.mdw" and, at the
end, delete the "developer" group from "user.mdw"?
Maybe not since I'm having trouble.

In "user.mdw" (which is in fact a copy of "developer.mdw") I logged in as
the developer (owner) and created a new user "dbadmin", which I put in the
Admins Group. I want to give "dbadmin" rights to add/delete users.
For "dbadmin" I checked "open", "open exclusive" and "administer" for
"database" in the combo. Is this correct? I removed all checkmarks under
"tables","forms", "reports" etc. Is this the place the check if this users
should be able to administer other users?

However - when I log in with "user.mdw" as "dbadmin" it seems I'm still able
to change permissions for database objects in addition to adding/deleting
users. "dbadmin" should only be able to add+delete users not alter object
permissions.

Could someone tell me:
When doing this MUST I recreate the distributable mdw-file ("user.mdw")
manually or can I copy the "developer.mdw" and change that (ultimately
deleting the "developer" group was my plan)?
How should I be logged in when I create "user.mdw"? Should I be logged into
"developer.mdw" or "system.mdw"?
Do I seem to be missing other things? I'm reading the SECFAQ and Jack
MacDonalds documents, but I'm confused about this part.
Thanks for any input

Jesper F.
 
Hi Jesper

This doesn't answer your question point by point, but it does describe
a standard method for doing what you want.

Say you distribute a workgroup file with your secured database. Ignore
how you got that file, where it came from, who is in it or not in it, &
so on. Just assume that it is a suitable workgroup file for use with
your secured database.

Now let's say there is a user, Fred, in that workgroup file, who has
sufficient permissions to create new users. Ignore how that user got
those permissions. Perhaps he is a member of a that which has those
permissions. Perhaps he has been granted Administer permission to the
database, by another user who had the authority to grant that
permission.

Now say that you do not tell anyone about that user (Fred), and you do
not reveal his password.

At this point, you have a user who can do what you want (ie. create new
users) - but non-one knows about that user, or how to log-on as him.

Now, any /other/ user, can use the CreateWorkspace method, to act "as
if" he were Fred, and do whatever Fred can do - eg. create new users.
The code for that, would look like this:

(untested)

dim ws as workspace, usr as user
set ws = dbengine.createworkspace("", "Fred", "freds password")
' now we can do, through workspace ws, anything that Fred can do.
set usr = createuser (...)
ws.users.append usr ... etc.

So, put that code in a form, and make it get the new username and PID
from two textboxes on the form. Then restrict permission to that form.
Then, any user who can run that form, can create new users through that
form - evn though they /can't/ create new users through the normal user
interface.

You'd also need to convert the database into an MDE fomat, so no-one
could just look at the code for that form, to see Fred's username and
password, then log-on directly as him.

Check online help and google for more infomation on the CreateWorkspace
method.

HTH,
TC
 
Jesper said:
I originally created an mdw-file called "developer.mdw" with the
groups: AppAdmins, AppUsers, Developer. I'm in the "Developer" group
as the only one and I'm the owner of the database.
I use AppAdmins and AppUsers mainly to discriminate between users.

The SecFAQ says to recreate this manually. But couldn't I just copy
"developer.mdw" into "user.mdw" and change the new "user.mdw" and, at
the end, delete the "developer" group from "user.mdw"?
Click to expand...

That is definitely not the way to go. You MUST create a new workgroup file;
otherwise the two will have the same Admins Group, which is what you don't
want.

Create a new workgroup file, and create the AppAdmins and AppUsers Groups
exactly as they were created in the developer.mdw (same name/PIDs).

Then in the user.mdw, you can create a user and put them in the Admins
Group; that will allow them to create/delete users and assign them to
groups, but won't allow them to modify permissions on anything else (because
it's not the same Admins Group as that in the developer.mdw)
When doing this MUST I recreate the distributable mdw-file
("user.mdw") manually
Yes

or can I copy the "developer.mdw" and change
that (ultimately deleting the "developer" group was my plan)?
Click to expand...

No. In fact, you don't really need a developer group, as the Admins Group
in developer.mdw would serve that purpose. However you don't need to
include it in the user.mdw.
How should I be logged in when I create "user.mdw"? Should I be
logged into "developer.mdw" or "system.mdw"?
Click to expand...

Makes no difference, since you will be creating a new mdw.
 
Joan Wild said:
That is definitely not the way to go. You MUST create a new workgroup
file; otherwise the two will have the same Admins Group, which is what you
don't want.
Click to expand...

Oops, I think I misunderstood the question, sorry.
 
Thanks for all the help TC, Keith and Joan.

Since I allready have the db distributed I'll venture into the two-mdw
solution another time, but now I finally know how :-)
I'm creating a couple of forms for a trusted user to add/delete users via a
few custom forms.
Behind it all he's using the workspace of an administrative user. It works
very well and eliminates using the standard account+permissions window
provided by Acces - which isn't that pretty :-)

Thanks again!

Jesper Fjølner
 
Back
Top