Basic security questions

  • Thread starter Thread starter Amy Blankenship
  • Start date Start date
A

Amy Blankenship

Hello, all;

Basically what I want to do is have my database have two password-protected
users: One that can see everything and one that I just show the forms to.
I am having conceptual problems with the whole security scheme + Access
thing.

In an ideal world, I'd like to be able to hand the Access file (by itself)
to the client, plus the two user names & passwords, and have the user in
question be able to open the database in the appropriate view. Sounds
simple enough, but when I crack open the help, it seems that all the
password protection stuff wants this workgroup definition file thing. Isn't
there any way to just set up users with passwords that are saved with the db
itself?

Barring that, I'd like to have the database look for its workgroup file in
the same directory as itself. How would I specify a relative path for the
workgroup file for the "b" option, assuming the "a" option isn't possible?

TIA;

Amy
 
Amy Blankenship said:
Hello, all;

Basically what I want to do is have my database have two
password-protected users: One that can see everything and one that I just
show the forms to. I am having conceptual problems with the whole security
scheme + Access thing.

In an ideal world, I'd like to be able to hand the Access file (by itself)
to the client, plus the two user names & passwords, and have the user in
question be able to open the database in the appropriate view. Sounds
simple enough, but when I crack open the help, it seems that all the
password protection stuff wants this workgroup definition file thing.
Isn't there any way to just set up users with passwords that are saved
with the db itself?
Click to expand...

You want an admin account (to see the database window, "everything") and a
user account? That is fairly simple and implies that one of your clients
users is experienced enough to set up the necessary shortcuts depending on
drive mappings. The online help is woefully inadequate and you need to
reference the MS FAQ - link on my website. Be warned though, the FAQ is
"all killer, no filler" and you must follow all the steps. My step-by-step
example may help too, but always work on copies of you files in case you
lock yourself out.
Barring that, I'd like to have the database look for its workgroup file in
the same directory as itself. How would I specify a relative path for the
workgroup file for the "b" option, assuming the "a" option isn't possible?
Click to expand...
The path to the workgroup file is defined in a shortcut in the format:

"Full path to MSACCESS.exe" "Full path to your app.mdb" wrkgrp/"Full path to
workgroup file.mdw"

HTH - Keith.
www.keithwilby.com
 
Amy Blankenship wrote:

(snip)
Barring that, I'd like to have the database look for its workgroup file in
the same directory as itself.
Click to expand...

You misunderstand how it works. Access selects a workgroup file before
it even /opens/ your database. The database itself plays /no part
whatever/ in Access'es decision on which workgroup file to use.

If you double-click an mdb file, the sequence of actions is as follows.

1. Windows determines that mdb files, should be opened with MS Access;
2. Windows starts MS Access, passing the mdb file name as a parameter;
3. MS Access opens the default workgroup file for that PC;
4. MS Access /then/ opens the specified mdb file, then
5, The mdb file works, or doesn't work, depending on whether it is or
is not usable with the PC's default workgroup file.

When you secure an mdb correctly, you create a new workgroup file, and
the mdb file will /not/ work with the default workgroup file. So if you
double-click that mdb file, it will fail, because Access will use the
defauilt workgroup file, exactly as described above.

When you start an mdb file using a shortcut of the standard form, shown
below, Access starts, then opens the /specified/ workgroup file
(regardless of the PC's default workgroup file), then opens the mdb
file. You must use the shortcut approach when opening a
properly-secured mdb file.

"full path to MSACCESS.EXE"
"full path to MDB file"
/wrkgrp "full path to MDW file"

In summary, there is no situation where "the database looks for the
workgroup file". It simply does not work like that.

HTH,
TC
 
So if I put the file on A UNIX server, for instance, and I wanted to pass a
user name and password from an ASP page and windows isn't actually involved,
what would the process look like then?

And I've also gotten password-protected databases from people in the past
where I didn't change any files on my computer, but somehow when I
double-clicked on the file it asked for a password and let me in when I
provided it. What was the mechanism for this series of events?

Thanks;

Amy
 
Your ASP page would "connect" to the file on the Unix box via ADO or ADO.NET
.... I'm not familiar with .NET, but with ADO your connect string would look
something like this:

oConn.Open "Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source=c:\somepath\mydb.mdb;" & _
"Jet OLEDB:System Database=MySystem.mdw", _
"myUsername", "myPassword"

Connect string from here:
http://www.carlprothman.net/Default.aspx?tabid=87#OLEDBProviderForMicrosoftJet

Your connection would actually use the .mdw file (probably on the Unix box
as well) to "open" the database ... your ASP server would handle the rest.

Password protected databases are different from database protected by ULS
.... password protection travels with the database and requires no external
files. ULS protected databases require the use of the .mdw workgroup file
(which stores Users, Groups, GroupMemberships, and Passwords) and the
database itself ... the .mdw file simply authenticates the user and tells
the db which groups the current user belongs to ... the acutal object
permissions are stored in the database itself.
 
Amy said:
So if I put the file on A UNIX server, for instance, and I wanted to pass a
user name and password from an ASP page and windows isn't actually involved,
what would the process look like then?
Click to expand...

Sorry, I have no idea.

And I've also gotten password-protected databases from people in the past
where I didn't change any files on my computer, but somehow when I
double-clicked on the file it asked for a password and let me in when I
provided it. What was the mechanism for this series of events?
Click to expand...

It was a database password, not a "user level" (username/password) one.

HTH,
TC
 
So you have to provide the mdw in the connection string for this to work.
Why don't you have to give the full path to the mdw, but you do with the
database?

Thanks;

Amy
 
PS Do you have to use the Jet provider? I use stored queries, and I found
that the * in a stored query that works fine when tested internally will
fail when you call it from outside the DB with the Jet provider, because Jet
wants %. Therefore, I prefer not to have to go back and change all my
queries (and not be able to test internally).

Thanks;

Amy
 
I'm guessing that you /do/ need the full path to the workgroup file. I
can't see how it would otherwise work. It's sure not going to scan the
whole hard disk to find that file :-)

HTH,
TC
 
Back
Top