By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,667 Members | 2,084 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,667 IT Pros & Developers. It's quick & easy.

User not in Admins - how to circumvent their not being able to create a new user?

P: n/a
MLH
I was running the following code while logged
in as a user belonging only to the Users group.

Set usrNew = .CreateUser(Me!UserID) 'The user ID is in a
control on the form
usrNew.PID = "AAA123456789"
usrNew.Password = "password"
.Users.Append usrNew
Of course, the last line resulted in an error. Not wanting
to put a user in the Admins group just for the sole purpose
of adding a new user, I'm seeking a way around this.

Access 2.0 used to have a query permissions setting
allowing some users to run it with owner privileges. Is
there something akin to this line of thinking that will
let user "Bob" (in the Users group only) run code to
create a new user account?
Nov 13 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
MLH
It must be necessary for many of you to enable a user
login ID that allows the creation of new users without
giving that special user full Admin rights to every other
object in the database. How does one secure his app
but allow one administrative function - the creation of
new users - maintaining the security of the other objects
the the full extent desired? Is that achieved primarily
via the mde file?
Nov 13 '05 #2

P: n/a
On Mon, 06 Jun 2005 19:47:49 -0400, MLH <CR**@NorthState.net> wrote:

I haven't tried this, but I would think you could CreateWorkspace
using the superuser, and then CreateUser in that workspace.

-Tom.

I was running the following code while logged
in as a user belonging only to the Users group.

Set usrNew = .CreateUser(Me!UserID) 'The user ID is in a
control on the form
usrNew.PID = "AAA123456789"
usrNew.Password = "password"
.Users.Append usrNew
Of course, the last line resulted in an error. Not wanting
to put a user in the Admins group just for the sole purpose
of adding a new user, I'm seeking a way around this.

Access 2.0 used to have a query permissions setting
allowing some users to run it with owner privileges. Is
there something akin to this line of thinking that will
let user "Bob" (in the Users group only) run code to
create a new user account?


Nov 13 '05 #3

P: n/a
MLH
On Mon, 06 Jun 2005 19:47:49 -0400, MLH <CR**@NorthState.net> wrote:

I haven't tried this, but I would think you could CreateWorkspace
using the superuser, and then CreateUser in that workspace.

-Tom.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thanks Tom. How have you been? I will give your suggestion a try
after first trying the following that I found at
http://www.microsoft.com/AccessDev/A...missions_Query
Here's a snippet from that page...
Configuring a Remote Workgroup so that Onsite Administrators Can
Manage User Accounts Without Gaining Permissions to Your Objects
You have built a multiuser application that will be administered by
users at a remote site. You want to lock up your code and other
objects to protect your intellectual property and to prevent users
from inadvertently breaking your application. Different users at the
sites have permissions to different forms in the database because they
are authorized to perform different duties. You don't want to manage
individual user accounts yourself because you are not on site and they
change frequently. How can you grant remote administrators the ability
to manage user accounts without at the same time giving them access to
your code?
Using the Workgroup Administrator, create a secure workgroup named
MySys.mdw. This will be the "master" workgroup for your database.

While logged on with this workgroup, follow the steps to secure a
database above.

Create your own custom groups that correspond to the different levels
of permissions that you will want your remote users to have. Write
down the exact names of these groups (case sensitive) and the personal
identifier (PIDs) you use to create them. You will need these strings
later.

Assign the appropriate permissions to these groups. Make sure you
don't grant Administer permissions to anything -- just grant the Read
Data, Write Data, and Open/Run permissions that are necessary for
users to run your application and perform their appropriate functions.

Use the Workgroup Administrator to create a new system database that
you will distribute with your application. Call it CusSys.mdw. Make
sure you use different strings for the name, company name, and
workgroup ID than the ones you used for MySys.mdw.

Log on under CusSys.mdw and re-create the exact same group names that
now exist in MySys.mdw, using the same case-sensitive names and the
same PIDs.

Create a user account for your remote administrator to use, and add
him to the Admins group of CusSys.mdw. For this example, call him
Fred.

Put a password on the Admin user, and make sure that you have removed
the Admin user from the Admins group. Putting a password on the Admin
user will force the Log on dialog box to appear, and it will make Fred
the effective administrator of the CusSys.mdw workgroup.

Distribute CusSys.mdw with your application. Make sure that the user
profile file used to start Microsoft Access for your application
points to CusSys.mdw. The Setup Wizard available in the Microsoft
Access Developer's Toolkit can help automate this process.
Now Fred will be able to create new user accounts, reset passwords,
and add users to the groups that you have already created. As users
are added to these groups, they will automatically gain the
permissions that you assigned to these group accounts in step 4. This
is because the SIDs of the group accounts in MySys.mdw are identical
to the SIDs of the custom group accounts in CusSys.mdw. However, the
SIDs of the Admins group in the two workgroups are different.
(Remember that these SIDs are generated from the strings fed into the
Workgroup Administrator, and you used different strings in step 5.)
Because the database was originally secured under MySys.mdw, not
CusSys.mdw, the Admins group in MySys.mdw has ultimate permission
setting privileges over all the objects in the database. The Admins
group of CusSys.mdw does not. So while Fred can add and delete users
from the groups you created, he does not have any special privileges
to your objects, and he therefore cannot see or modify the design of
any of the objects to which you haven't granted him permissions.
Nov 13 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.