User Account Access to User-Level Secured Database

[Guest]

I have a UL secured database (2002-2003), with two Groups (Admins, Users).

After setting up security, I've printed out the "One-Step Security Wizard"
report after completing the Wizard. This report has all information for
re-constructing the WIF as necessary. However, if I modify the WIF through
the Wizard again, I don't believe I get a comprehensive copy of all WIF
information to completely re-construct. Previous data appears on the
printout as '<Previously Created>'.

Am I missing the mark on this or is there a way to get a comprehensive copy
of all WIF information? If not, what protocol is recommended to warehouse
this information?

Another way to modify the WIF is through the Access Security Menus. How do
I keep up with PIDs, etc. entered through this avenue?

Do I need to create a separate Management System for security related
information?

Regards,
VBA Dabbler

 

[Joan Wild]

I have a UL secured database (2002-2003), with two Groups (Admins,
Users).

So you aren't creating any groups of your own? You usually don't give any
permissions to the Users Group, so that would leave you with just one group
Admins, which doesn't provide much security since this group can do just
about anything.

After setting up security, I've printed out the "One-Step Security
Wizard" report after completing the Wizard. This report has all
information for re-constructing the WIF as necessary. However, if I
modify the WIF through the Wizard again, I don't believe I get a
comprehensive copy of all WIF information to completely re-construct.
Previous data appears on the printout as '<Previously Created>'.

That's why you'd keep each copy of the report. However, you shouldn't keep
running the wizard, as you can modify things via the security dialogs.

Another way to modify the WIF is through the Access Security Menus.
How do I keep up with PIDs, etc. entered through this avenue?

If you assign all permissions to groups (and not users), you really only
need to record the PIDs for the groups. There's no need to record the
information for users. You can always recreate a user (even the same one
but a different PID), and assign them to whatever group you want.

 

[Guest]

So you aren't creating any groups of your own? You usually don't give any
permissions to the Users Group, so that would leave you with just one group
Admins, which doesn't provide much security since this group can do just
about anything.

I postponed creating them (groups) as I wanted to wait until later, after
determining what the requirements would be.

What do you do about retrieving the GID for the 'Admins' group? The
original "One-Step Security Wizard" report did not display the GID for this
group. Is this the way it is?

That's why you'd keep each copy of the report. However, you shouldn't keep
running the wizard, as you can modify things via the security dialogs.

I presume you write down PIDs for new groups created in the security
dialogs...

This sure seems rather manual, but if that's what must be done, then so be it.

 

[Joan Wild]

I postponed creating them (groups) as I wanted to wait until later,
after determining what the requirements would be.

OK, but be aware of a potential problem in doing this. It may not affect
you, but if you are going to let users create/save queries, then read on...
http://www.jmwild.com/MSysTables.htm

What do you do about retrieving the GID for the 'Admins' group? The
original "One-Step Security Wizard" report did not display the GID
for this group. Is this the way it is?

Yes it is. The GID for the Admins Group is (I believe) derived from the
Workgroup Name, WID and Organization Name (so be sure you have that
recorded).

I presume you write down PIDs for new groups created in the security
dialogs...

Of course.

This sure seems rather manual, but if that's what must be done, then
so be it.

An opportunity to practice your penmanship, I guess. <g>

FWIW, I don't use the wizard, but instead secure manually, so I am writing a
good deal more.