Opening a Connection with user level security enabled

[DaveFromDover]

I have built an application for a customer that posts charges to customer
accounts at various times of the day.

The way I've done this is to use the windows task scheduler to open a form
using command line trigger in the shortcut.

The form then on open opens a connection with valid authentication like so.

cnn.open currentproject.connection "Master","Pswrd"

I use a connection object because transaction processing is somewhat
important in the process.

My concern is that I have given the user the ability to add and delete users
through a custom security interface bypassing the Access Security menu. The
interface doesn't show the "master" user but I'm concerned that if someone
plays around with the access interface they may find the security screens and
inadvertently delete the "Master". Then this mission critical process would
cease to work automatically (of course, there are several audits that will
tell you when it hasn't run, it would have to be run manually.)

Any help is most appreciated.

 

[TC]

S, each user has sufficient Access permissions to delete other users
through the normal Access user interface - correct?

If so, that's no the way you'd usually do it. There is a technique for
letting a low-permission user, perform higher-permission operations,
completely under program control. With that technique, the users could
not delete /any/ users via the normal Access interface, but /could/ do
so via your custom form - and only via that form.

To learn how that works, google for posts containing the word
"privdbengine" in this & other Access newsgroups.

HTH,
TC

 

[DaveFromDover]

I couldn't find much on privdbengine but while reading through some of it
triggered a thought. Why not use ADOX to add a user right before executing
the command and then delete the user right after?

Seems like it should do what I want which is to ensure that the user is
always in the workgroup when I try to open the connection without leaving a
backdoor in open.

Do you see any pitfalls?

Thanks for your reply.
Dave

 

[TC]

Gak! Sorry, I mislead you completely :-((

The technique that I had in mind, uses the CreateWorkspace method, not
the PrivDBEngine object.

Like this: (untested)

dim ws as workspace, u as user
set ws = dbengine.createworkspace ("", "supervisor", "s3cr3t")
set u = ws.createuser (<parameters for new user>)
ws.users.append u ' u.name?
set ws = nothing

Say the current user /does not/ have permission to create new users.
Say "supervisor" and "s3cr3t" are the username and password of a user
who /does/ have that permission. If the current user runs the code
above, he *can* create new users. He temporarily acquires the
higher-level permissions of the other user, to perform that function.
Similarly, you could let the lower priviliged user, delete existing
users, even though he did not actually have that permission, himself.

If you put that code in an MDE, this would prevent any user from
modifying it to perform other (unauthorized) tasks.

That is what I had in mind. Does it help?

Cheers,
TC