Add/remove users

[Bob Hughes]

Add/remove users

I followed the coding presented by Jeff and TC for adding and removing
users from secure DB. And have successfully created "add new user" and
"delete user" forms
I used
Set wrk = DBEngine.Workspaces(0)
Instead of
Set wrk = DBEngine.CreateWorkspace
("", "AdminUserName", "AdminUserPassword", dbUseJet)
which means you don't have to hard code password in.

Is it possible to create a list of current users and groups?

Bob

 

['69 Camaro]

Hi, Bob.

Is it possible to create a list of current users and groups?

Yes. One can print a report or programmatically retrieve this information.
To print a report, log into the secure database. Select the Tools menu ->
Security -> User and Group Accounts to open the User and Group Accounts
dialog window. Select the "Print Users and Groups" button in the bottom
right corner. Select the "Both Users and Groups" option, then select the
"OK" button.

To retrieve the information via VBA code, please see section 22 of the
Security FAQ on the following Web page:

http://support.microsoft.com/default.aspx?scid=/support/access/content/secfaq.asp

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)

- - -
When you see correct answers to your question posted in Microsoft's Online
Community, please sign in to the Community and mark these posts as "Answers,"
so that all may benefit by filtering on "Answered questions" and quickly
finding the right answers to similar questions. (Only "Answers" have green
check-marks.) Remember that the best answers are often given to those who
have a history of rewarding the contributors who have taken the time to
answer questions correctly.

 

[Bob Hughes]

Thanks Gunny,

I should have seen that in the Security FAQ. It has a lot of good info. I
must spend more time reading it.

Bob

Hi, Bob.


Yes. One can print a report or programmatically retrieve this
information. To print a report, log into the secure database. Select
the Tools menu -> Security -> User and Group Accounts to open the User
and Group Accounts dialog window. Select the "Print Users and Groups"
button in the bottom right corner. Select the "Both Users and Groups"
option, then select the "OK" button.

To retrieve the information via VBA code, please see section 22 of the
Security FAQ on the following Web page:

http://support.microsoft.com/default.aspx?scid=/support/access/content/
secfaq.asp

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a
message will be forwarded to me.)

TO reply via e-mail, change the xxx in the address to bob_

 

['69 Camaro]

You're welcome. (Bring lots of caffeine.)

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)

- - -
When you see correct answers to your question posted in Microsoft's Online
Community, please sign in to the Community and mark these posts as "Answers,"
so that all may benefit by filtering on "Answered questions" and quickly
finding the right answers to similar questions. (Only "Answers" have green
check-marks.) Remember that the best answers are often given to those who
have a history of rewarding the contributors who have taken the time to
answer questions correctly.

 

[TC]

Add/remove users

I followed the coding presented by Jeff and TC for adding and removing
users from secure DB. And have successfully created "add new user" and
"delete user" forms
I used
Set wrk = DBEngine.Workspaces(0)
Instead of
Set wrk = DBEngine.CreateWorkspace
("", "AdminUserName", "AdminUserPassword", dbUseJet)
which means you don't have to hard code password in.

You misunderstand the impact of your change.

With the original code, the current user can do anything through the
'wrk' workspace, that the *hard coded* user is allowed to do. So, the
current user can be allowed to do things that he normally *is not*
allowed to do - such as, perhaps, creating new users. By this means,
you could (if you wanted to) give a very low priovilged user, access to
a form, that let him do certain things requiring a very high level of
privilige but only under program cotrol.

With your change, the current user can only do things, through the
'wrk' workspace, that he is normally allowed to do. Your change removes
the "programattic privilige escalation" purpose of the original code.

I'm not saying that your change is wrong for your purpose. I'm just
saying that you have changed an apple, into an orange. Fine if you like
oranges, but not if you really wanted an apple!

HTH,
TC

 

[Bob Hughes]

You misunderstand the impact of your change.

With the original code, the current user can do anything through the
'wrk' workspace, that the *hard coded* user is allowed to do. So, the
current user can be allowed to do things that he normally *is not*
allowed to do - such as, perhaps, creating new users. By this means,
you could (if you wanted to) give a very low priovilged user, access to
a form, that let him do certain things requiring a very high level of
privilige but only under program cotrol.

With your change, the current user can only do things, through the
'wrk' workspace, that he is normally allowed to do. Your change removes
the "programattic privilige escalation" purpose of the original code.

I'm not saying that your change is wrong for your purpose. I'm just
saying that you have changed an apple, into an orange. Fine if you like
oranges, but not if you really wanted an apple!

You're right TC. I was only thinking about my requirements.

After following this group for a little while, I now have a form that
successfully adds and removes users.
My next question is about the PID. For each new user I could:
Use the same PID.
Create a random PID.
Use a table of PID's & increment it.

What do you recommend?

Bob

 

[TC]

Bob Hughes wrote:

(snip)

My next question is about the PID. For each new user I could:
Use the same PID.
Create a random PID.
Use a table of PID's & increment it.

What do you recommend?

Whatever you do, don't choose any method that lets an evil person guess
its value! (so methods 1 & 3 above are out) Otherwise, it is possible
to impersonate that user by recreating him in a different workgroup
file.

Here's how it works.

To the underlying MS Jet database engine, users are not really defined
by usernames. They are defined by username *plus PID*. The combination
of username + PID is assigned a unique binary number called a Security
Identifier (SID). It is the SID which really defines that user, not his
username.

When permissions are stored within a database (mdb) file, they are
stored against SIDs - *not* usernames. For example:

workgroup file:
username: Fred
PID: 1234
SID: 10F369A7B4402D

database:
table: MySecretData
SID: 10F369A7B4402D
perms: Read only

I imagine there are two reasons why the Jet team did it like that.

(1) You can't acquire a person's permissions just by creating a new
workgroup file then adding a new user with the relevant name. You'd
have to know their PID, as well.

(2) You might have a person Fred Smith in workgroup file #1, and a
different person also called Fred Smith in workgroup file #2. If
permissions were based on usernames, there would be no way to
distinguish the permissions for those two people. But with the method
described above, if you give them different PIDs, they will get
different SIDs, so they will be (in effect) completely different users
to Jet & Access.

This shows the amazing level of thought that the Jet team gave, to the
whole security mechanism. It is truly a work of wonder, in every
respect except one! They made some absolute cryptograhpic "schoolboy
howlers" pertaining to the workgroup file. Hence the existance of
programs that can reverse-engineer the usernames, PIDs and passwords
from a workgroup file. With the tiniest of tiny Jet code changes, it
would not be possible to reverse engineer that information from a
workgroup file. I have put this to MS, but they are not interested :-(
And I don't have the level of win32 skills necessary to write a program
that would patch Jet in memory, at runtime.

So, go the random PIDs! Don't make PIDs predictable. It doesn't matter
if two different people get the same PID (by chance). They will still
have different SIDs (because their usernames are different), so they
will still look different to Jet.

HTH,
TC