I'm still trying to tie down some loose ends with security.  I ran across
this in section 8 (How can I secure just my code without users having to log
on) of the Security FAQ:

"Make sure that all permissions to modules are revoked for the Users group
and the Admin user."

There is no option I can see to apply permissions to modules.  Is this
something that applies to older versions of Access only?  As I understand
it, creating MDEs will effectively protect the code, but I believe there is
also a way to secure the code in a VBA project, except I can't figure out
how.

Here is something that was in Jack MacDonald's paper:  "Be sure to write
down the PID whenever you create a user or group. You will need that
information if you ever want to recreate the user or group."

I have read this elsewhere too, I think.  Under what circumstances would I
have to re-create a user or group?  Would that occur if I had to re-create a
secure mdw file because of corruption or whatever?  I remember adding users
and having a complicated PID assigned automatically.  Perhaps I was using
the wizard.  In any case, when I create a new user manually it looks like
the only choice is to add a PID myself.

My questions are about the PIDs.  I don't think I noted those complicated
IDs when I created the users.  Is there anything to be gained by creating a
new mdw file, and creating the users from scratch, writing down all of the
information as I go?  Or maybe there is a way to print out that stuff?
Probably not, but it's worth asking.  Also, when I create a group I add a
PID, but how about if I use a default group such as Full Data Users?  If I
need to re-create the mdw file, are the PIDs for the default groups the same
as in the old group?

I have not yet split the database, but hope to as soon as I can be
reasonably sure the security is implemented properly.  It is working well in
the development version.  What do I need to back up to assure I don't get
locked out of the database some day if a file corrupts or whatever?  Should
I export everything to a new copy of the database in which Admin owns
everything, and save that as the unsecured backup?  Should I keep a copy of
the secure mdw file too, from a time when it works properly?  What are some
hints for managing security, including providing for backups, in the long
term?

Yes; it only applies to older versions.

Tools, <name of mdb>properties, Protection tab

Yes.  If you manage the permissions by groups (and don't assign permissions to users), you only really need the PIDs for the groups, as well as the name/PID you used to create the workgroup file.  You don't really need the users PIDs, as you can just create new users and assign them to the regenerated Groups.

Correct.

Not really.

The wizard offered you the opportunity to print out a report when it was finished - that was your chance, unless you chose to save it.

No they are not.  Each mdw would assign a different PID to the Full Data Users.

I would backup the secure mdw file, for sure, especially since you don't have the PIDs.

You can if you like.

Joan,

I forgot to flag the message, and lost track of it.  I didn't mean to leave
your helpful reply unacknowledged.

I found the place to secure the VBA code.  Thanks.

If I understand you correctly, unless I use the wizard and choose to print a
report I have no way of learning the PIDs of the built-in groups.  Since I
have missed that opportunity, it seems it may be best to create new groups
so that I can note the PIDs.  Or maybe backing up the security mdw file will
be enough.

Most of my questions were driven by a wish to avoid ever getting permanently
locked out of my own database because of a corrupted file somewhere, or
something like that.

Anyhow, thanks for taking the time to respond.

Yes; it only applies to older versions.

Tools, <name of mdb>properties, Protection tab

Yes.  If you manage the permissions by groups (and don't assign permissions
to users), you only really need the PIDs for the groups, as well as the
name/PID you used to create the workgroup file.  You don't really need the
users PIDs, as you can just create new users and assign them to the
regenerated Groups.

Correct.

Not really.

The wizard offered you the opportunity to print out a report when it was
finished - that was your chance, unless you chose to save it.

No they are not.  Each mdw would assign a different PID to the Full Data
Users.

I would backup the secure mdw file, for sure, especially since you don't
have the PIDs.

You can if you like.

You are correct; that horse has left the barn.

Backing up should be sufficient, however creating new groups may not be sufficient, as you'll also need to know the exact name and ID you used when you created the workgroup file.  If you have that, then you can create new groups.  If not, and it's bugging you, then you might consider unsecuring, and resecuring.  There is some helpful code at www.daiglenet.com/msaccess.htm you can use to script out the existing permissions; or use Jeff Conrad's tool to document the existing permissions.

Thanks again, Joan.  I noted the name and ID I used when creating the
workgroup file.  I also noted the PIDs for custom groups.  Beyond that I was
not as meticulous about noting information.  It sounds as if I'll be OK if I
back up the secure mdw (and the database itself, of course).  I will also
keep an unsecured copy of the database.  I may be worrying more than is
necessary.

Thanks for the link, and for pointing out Jeff Conrad's utility.  There's a
lot of stuff on his site; I expect I have missed a number of things, even
though I long ago bookmarked the site.

You are correct; that horse has left the barn.

Backing up should be sufficient, however creating new groups may not be
sufficient, as you'll also need to know the exact name and ID you used when
you created the workgroup file.  If you have that, then you can create new
groups.  If not, and it's bugging you, then you might consider unsecuring,
and resecuring.  There is some helpful code at
www.daiglenet.com/msaccess.htm you can use to script out the existing
permissions; or use Jeff Conrad's tool to document the existing permissions.

If you have the workgroup ID/name and you have the PIDs for your groups, that's all  you really need, provided you manage security via groups and not users.

Armed with just that information, you can recreate the workgroup information file and the groups.  From there you can create entirely new users and assign them to the groups.  This is only if you assign permissions to groups and not to individual users.

Show quoteHide quote

Only groups have permissions, as you and others have recommended.  Thanks
for clearing up these somewhat worrisome points.  I have seen quite a few
posts from people who are locked out or otherwise in trouble because of a
corrupted file or other misfortune.  I want to do everything I can to assure
I'm not going to be one of those people.

If you have the workgroup ID/name and you have the PIDs for your groups,
that's all  you really need, provided you manage security via groups and not
users.

Armed with just that information, you can recreate the workgroup information
file and the groups.  From there you can create entirely new users and
assign them to the groups.  This is only if you assign permissions to groups
and not to individual users.

Show quoteHide quote

Different Computer, Can't Open db with Same Username & Password
ULS Flaw?
Startup Password to access switchboard
User Permissions
Require users to select a password