Rights for creating a user

[Chris O''''Neill]

What rights are required for creating a user? In my application, I'm
designing a start-up procedure whereby a new user of my application accepts a
license agreement, establishes an "Admin" account for themself (but this
isn't the defalt "Admin" account so it doesn't have total rights, just ones I
grant and, btw, my code blocks using "Admin" as a user name), and then goes
through some configuration steps.

I've got a mock up of my code working when I'm logged on, but I'm wondering
if it's going to work for a new user with no real rights (yet) on the system?
Thoughts and suggestions how how to impliment this would be appreciated.

Regards, Chris

 

[Joan Wild]

A user needs to be a member of the Admins Group in order to create a user.
You can create a separate mdw file for shipping with your app (separate mdw
than the one you secured it with). You can set up a user in this
'production' mdw that the person uses to first gain access. Make it a
member of the Admins group, and then once they're in, they can create a new
user and assign to your groups.

 

[Chris O''''Neill]

A user needs to be a member of the Admins Group in order to create a user.
You can create a separate mdw file for shipping with your app (separate mdw
than the one you secured it with). You can set up a user in this
'production' mdw that the person uses to first gain access. Make it a
member of the Admins group, and then once they're in, they can create a new
user and assign to your groups.

Thanks, Joan, for the suggestion. Uhhh... that opens up another can of
worms...

Right now, I'm the only member of the "Admins" group and that group has full
rights to everything. Of course, I don't want a new user to have those
rights. Soooooooo....

When I create this "production" MDW file, should I give it esentially no
rights to the application (i.e. it can just be used to create a user account,
and then assign myself to another "admins" group (e.g. "MyAppOwner" that has
full rights? If I go that route, do I lose any rights because I'm not a
member of Access' default Admins group even though I'm the owner of the
database?

Just so it's clear what I'm trying to accomplish, here's the process flow
I'm trying to implement.

1. When the application starts, a "Startup" form is loaded. The OnLoad
event of this form checks to see if the EULA has been agreed to (right now,
this is stored in a boolean field on a table in the FE) and, if so, It
cancels opening the form and loads the log-on screen so the user can log-on.

2. If the EULA hasn't been agreed to, the Startup form presents the EULA to
the user and gives them a check box to check if they agree. There's also a
check box for "I just want to look around." The user can check one (but not
both) of the check boxes and then click the "Continue" command button. If
the user clicks "Continue" without checking one of the two check boxes, the
applications closes.

3. If the user checks "I just want to look around," and then "Continue"
they're allowed into the system using a non-password protected "DemoUser"
account which has *very* limited access. This gives the person an
opportunity to check out the application without going through the whole
setup procedure.

4. If the user checks the "I accept the EULA" and "Continue," the
application presents the user with a series of forms to set-ulp the system.
The first form is a "CreateUsers" form so that the user can create one (and
only one... I check for this) account that's a member of the applications
"MyAppManagers" group, and as many "MyAppRegularUsers" accounts as desired.

5. Once the account(s) have been setup, the user is presented with the
log-on form so they call log-on and proceed with setup.

Any comments, suggestions, pointers to other web 1resources on how to
implement this scenario would be greatly appreciated.

Regards, Chris

 

[Chris O''''Neill]

Btw, one other piece of information, in case it makes a difference...

This application is not networked nor is it multi-user. It's a standalone
PC application that will be delivered to the users via mail or maybe internet
download. The FE and BE will both reside in the same directory on one PC.
If there are more than one users (ie. a "manager" and an "employee") it is
assumed that they'll share the host PC.

Regards, Chris

 

[Joan Wild]

Right now, I'm the only member of the "Admins" group and that group has
full
rights to everything. Of course, I don't want a new user to have those
rights. Soooooooo....

When I create this "production" MDW file, should I give it esentially no
rights to the application (i.e. it can just be used to create a user
account,
and then assign myself to another "admins" group (e.g. "MyAppOwner" that
has
full rights? If I go that route, do I lose any rights because I'm not a
member of Access' default Admins group even though I'm the owner of the
database?

No. When you create a new mdw, you set it up so that the workgroup name and
ID is different than your development mdw. This ensures that the Admins
Group in it is *different* than the Admins Group in your development mdw.
The Admins Group here won't have the same permissions as the Admins Group in
your development mdw, so will just be able to create users. Then you create
the exact same groups in this production mdw as you have in your development
mdw (use the exact name and PID strings when you create the groups).
There's more on this in the security FAQ
http://support.microsoft.com/?id=207793

Just so it's clear what I'm trying to accomplish, here's the process flow
I'm trying to implement.

1. When the application starts, a "Startup" form is loaded. The OnLoad
event of this form checks to see if the EULA has been agreed to (right
now,
this is stored in a boolean field on a table in the FE) and, if so, It
cancels opening the form and loads the log-on screen so the user can
log-on.

I assume this application loads using the standard system.mdw, or are you
using your secure mdw?

3. If the user checks "I just want to look around," and then "Continue"
they're allowed into the system using a non-password protected "DemoUser"
account which has *very* limited access. This gives the person an
opportunity to check out the application without going through the whole
setup procedure.

You could use the standard Users Group for this purpose - that way the user
doesn't need to log in with any username (they'll just use their standard
system.mdw and move about as 'Admin', which would have these "*very* limited
access" rights.

4. If the user checks the "I accept the EULA" and "Continue," the
application presents the user with a series of forms to set-ulp the
system.
The first form is a "CreateUsers" form so that the user can create one
(and
only one... I check for this) account that's a member of the applications
"MyAppManagers" group, and as many "MyAppRegularUsers" accounts as
desired.

5. Once the account(s) have been setup, the user is presented with the
log-on form so they call log-on and proceed with setup.

Any comments, suggestions, pointers to other web 1resources on how to
implement this scenario would be greatly appreciated.

Before you go too far with this, you do understand that Access security can
be broken fairly easily by anyone willing to do a search on the internet,
right? You shouldn't expect much more than 'application guidance for the
honest' out of Access security.

 

[Chris O''''Neill]

Joan Wilde said:

No. When you create a new mdw, you set it up so that the workgroup name and
ID is different than your development mdw. This ensures that the Admins
Group in it is *different* than the Admins Group in your development mdw.
The Admins Group here won't have the same permissions as the Admins Group in
your development mdw, so will just be able to create users. Then you create
the exact same groups in this production mdw as you have in your development
mdw (use the exact name and PID strings when you create the groups).
There's more on this in the security FAQ
http://support.microsoft.com/?id=207793

Thank you for clarifying that. I think I understand now.

Just so it's clear what I'm trying to accomplish, here's the process flow
I'm trying to implement....

[Snip!]

I assume this application loads using the standard system.mdw, or are you
using your secure mdw?

My prototype uses the secure mdw.

You could use the standard Users Group for this purpose - that way the user
doesn't need to log in with any username (they'll just use their standard
system.mdw and move about as 'Admin', which would have these "*very* limited
access" rights.

That sounds reasonable, but then I need to programmatically switch to the
secure if they accept the EULA because then they'll no longer be "just
looking around." Can this be done and, if so, can you give me some sample
code?

Before you go too far with this, you do understand that Access security can
be broken fairly easily by anyone willing to do a search on the internet,
right? You shouldn't expect much more than 'application guidance for the
honest' out of Access security.

Yes I realize that. I understand that if someone *really* wants to crack
the security they'll figure out how to do it. My application won't be used a
bank, health facility, or some other environment where very high security is
required. My focus is directed more at ensuring that unauthorized "casual
browsing" is thwarted. As well, I want to control what different classes of
users can do and what data they can see. For instance, there are some
tableds where a "regular user" will be able to add and update data, but
"system manager" rights will be required to delete a record. Access'
security appears to more than adequately meet those needs.

Thank you, again, for all your advice and assistance. I very much
appreciate your help!

Regards, Chris

 

[Joan Wild]

I think you should keep on with what you have - startup using your secure
mdw with a 'DemoUser' account, in a production copy of the mdw. Try that
out.

--
Joan Wild
Microsoft Access MVP

Joan Wilde said:

No. When you create a new mdw, you set it up so that the workgroup name
and
ID is different than your development mdw. This ensures that the Admins
Group in it is *different* than the Admins Group in your development mdw.
The Admins Group here won't have the same permissions as the Admins Group
in
your development mdw, so will just be able to create users. Then you
create
the exact same groups in this production mdw as you have in your
development
mdw (use the exact name and PID strings when you create the groups).
There's more on this in the security FAQ
http://support.microsoft.com/?id=207793

Thank you for clarifying that. I think I understand now.

Just so it's clear what I'm trying to accomplish, here's the process
flow
I'm trying to implement....

[Snip!]

I assume this application loads using the standard system.mdw, or are you
using your secure mdw?

My prototype uses the secure mdw.

You could use the standard Users Group for this purpose - that way the
user
doesn't need to log in with any username (they'll just use their standard
system.mdw and move about as 'Admin', which would have these "*very*
limited
access" rights.

That sounds reasonable, but then I need to programmatically switch to the
secure if they accept the EULA because then they'll no longer be "just
looking around." Can this be done and, if so, can you give me some sample
code?

Before you go too far with this, you do understand that Access security
can
be broken fairly easily by anyone willing to do a search on the internet,
right? You shouldn't expect much more than 'application guidance for the
honest' out of Access security.

Yes I realize that. I understand that if someone *really* wants to crack
the security they'll figure out how to do it. My application won't be
used a
bank, health facility, or some other environment where very high security
is
required. My focus is directed more at ensuring that unauthorized "casual
browsing" is thwarted. As well, I want to control what different classes
of
users can do and what data they can see. For instance, there are some
tableds where a "regular user" will be able to add and update data, but
"system manager" rights will be required to delete a record. Access'
security appears to more than adequately meet those needs.

Thank you, again, for all your advice and assistance. I very much
appreciate your help!

Regards, Chris

 

[Chris O''''Neill]

I think you should keep on with what you have - startup using your secure
mdw with a 'DemoUser' account, in a production copy of the mdw. Try that
out.

Yes, I have a "gut feeling" that's probably the best way to go. Thank you,
again, for all the advice and assistance. Now, all I have to do is figure
out how to actually implement all this! ;-)

Regards, Chris

 

[Joan Wild]

Yes, I have a "gut feeling" that's probably the best way to go. Thank
you,
again, for all the advice and assistance. Now, all I have to do is figure
out how to actually implement all this! ;-)

Backup, take your time, step by step.