system.mdw/default/secured mdw etc.

[Mike MacSween]

Yes, I've downloaded and read the FAQ. And searched the archives. I'm just
treading a little carefully here because of the caveats about locking myself
out of the db forever. Some answers I could probably get myself just by
trying things out. But don't want to 'play' around too much.

I ran the Security Wizard on my system at my office. Did all the usual
things, admin -> users, users group have no rights. Assigned rights as
required. The job isn't quite finished in terms of RWOP queries and back end
rights but thats WIP.

Everything is hunky dory here but goes a bit harewire at the clients:

1. I work out (after quite a while) that the shortcut has to include the
path to the access exe - "path to msaccess.exe" "path to mdb" /wrkgrp "path
to secured mdw file". Or does it? Given that it's just possible that the
path to access may not be the default I'd rather not have to create
shortcuts one by one. Or does it just have to include the path if I want to
use a non default mdw? I'm putting my secure mdw on the server. At the
clients the system.mdw is still there in the default place. Is this because
I haven't used the wizard? I would actually prefer to leave it there. Partly
because I don't want to have to update each workstation, and also so that
any of the users can do Access work without me if they want to. Just as
admin/blank.

2. How do I recreate system.mdw on my machine here?

3. There is an autoupdate thingy in this app. Basically at startup the app
checks a version number in a table against an mdb held in an update folder
on the server. If it's the same the mdb opens. If not it opens an updater
mdb, closes, the updater copies from server to workstation reopens
workstation version. Problem I was getting at the clients was that it
wouldn't look at the copy in the update folder. Trying to open it,
presumably (?) using system.mdw. And of course admin/blank doesn't have any
rights on that database. But once there is a running instance of Access
isn't the same mdw used for any app? At the office it works fine, because
secure.mdw seems to be the default mdw - as far as I could tell from poking
around in the registry. Am I on the right lines here?

4. Is running wrkgadm.exe the same as running the User Level Security wizard
from the UI?

Yours, Mike MacSween

[Mike MacSween]

Further to all that. I kept a record of everything while I created the mdw.
WID of workgroup. PIDs of users and of the one group I so far created. But
can't find one for Admins group. Am I correct in thinking that as its a
built in group there won't be a PID? This is what I've recorded so far:

For the mdw:

Name
Company
WID

for the one group I created so far:

Name
PID

for each user I created:

Name
Password
PID

Is that enough information to recreate the mdw if I have to?

In the documentation that was offered on creation Group ID for Admins and
Users and PID for admin are all described as <previously created>.

Yours, Mike MacSween

[Keith Wilby]

"Mike MacSween" <mi******************@btinternet.com> wrote:

<snip> 1. I work out (after quite a while) that the shortcut has to include

the path to the access exe - "path to msaccess.exe" "path to mdb"
/wrkgrp "path to secured mdw file". Or does it? Given that it's just
possible that the path to access may not be the default I'd rather not
have to create shortcuts one by one. Or does it just have to include
the path if I want to use a non default mdw? I'm putting my secure mdw
on the server. At the clients the system.mdw is still there in the
default place. Is this because I haven't used the wizard? I would
actually prefer to leave it there. Partly because I don't want to have
to update each workstation, and also so that any of the users can do
Access work without me if they want to. Just as admin/blank.
Hi Mike.

AIUI the entire paths to all three (msaccess.exe, the FE and the mdw) are
required. I have many users across many sites and have never come across
Access being in a non-standard location.

You say you've read the FAQ but I detect some holes in your understanding
:-) I've never used the security wizard but it sounds like it is a bad
idea if it modifies your system.mdw. The correct way to proceed is to
create a *new* myfile.mdw and place it where all your users can see it,
leaving all system.mdw's intact. Your shortcut command line will then
switch the user's machine (for that Access session only) to your mdw when
they execute it. Therefore, system.mdw is not queried on any machine by
your app.

2. How do I recreate system.mdw on my machine here?
If you've modified your system.mdw I believe that overwriting it with a
'clean' copy will do the job, else all of your Access sessions will be
opened referencing your modified system.mdw.

3. There is an autoupdate thingy in this app. Basically at startup the
app checks a version number in a table against an mdb held in an update
folder on the server. If it's the same the mdb opens. If not it opens
an updater mdb, closes, the updater copies from server to workstation
reopens workstation version. Problem I was getting at the clients was
that it wouldn't look at the copy in the update folder. Trying to open
it, presumably (?) using system.mdw. And of course admin/blank doesn't
have any rights on that database. But once there is a running instance
of Access isn't the same mdw used for any app? At the office it works
fine, because secure.mdw seems to be the default mdw - as far as I
could tell from poking around in the registry. Am I on the right lines
here?

I think my earlier comment covers some of this, but the approach I use is
to have your users' shortcut open a batch file. The batch file copies the
latest version of my FE from my 'public' server folder to their C drive and
then opens it. That way, they *always* get the latest version without the
need to check version numbers anywhere.

eg:
XCOPY "M:\KeithWilby\Public\MyGUI.mdb" C:\Temp\MyFolder /I
"C:\Program Files\Microsoft Office\Office\MSACCESS.EXE"
"C:\Temp\MyFolder\MyGUI.mdb" /wrkgrp "M:\KeithWilby\Public\MyWIF.mdw"

4. Is running wrkgadm.exe the same as running the User Level Security
wizard from the UI?

As I say I've never run the wizard but I very much doubt it. I have a step-
by-step example on my web site which you might find useful. It does take a
while IMO for the Access security penny to drop but once it does ... :-)

HTH - Keith.
www.keithwilby.org.uk

[Mike MacSween]

"Keith Wilby" <ke*********@AwayWithYerCrap.com> wrote in message
news:Xn************************@10.15.188.42...

Thanks for replying Keith

AIUI the entire paths to all three (msaccess.exe, the FE and the mdw) are
required.
Right. I'll do it that way.
I have many users across many sites and have never come across
Access being in a non-standard location.
Sure. But ya never know <g> My 3 installs of Office are all in non standard
locations.
You say you've read the FAQ but I detect some holes in your understanding
:-)
Quite possible. Amazingly enough, there are times when I don't quite
understand things perfectly!
I've never used the security wizard but it sounds like it is a bad
idea if it modifies your system.mdw.
Well I'll go to the foot of our stairs! System.mdw is there. But the
registry has been altered to make mine the default.
The correct way to proceed is to
create a *new* myfile.mdw and place it where all your users can see it,
leaving all system.mdw's intact. Your shortcut command line will then
switch the user's machine (for that Access session only) to your mdw when
they execute it. Therefore, system.mdw is not queried on any machine by
your app.
Yes,
I think my earlier comment covers some of this, but the approach I use is
to have your users' shortcut open a batch file. The batch file copies the
latest version of my FE from my 'public' server folder to their C drive and then opens it. That way, they *always* get the latest version without the
need to check version numbers anywhere.

eg:
XCOPY "M:\KeithWilby\Public\MyGUI.mdb" C:\Temp\MyFolder /I
"C:\Program Files\Microsoft Office\Office\MSACCESS.EXE"
"C:\Temp\MyFolder\MyGUI.mdb" /wrkgrp "M:\KeithWilby\Public\MyWIF.mdw"
Yes. This has become a bit of pain. I may well switch to a simple xcopy like
yours. I'll have to see how long it takes though. I keep telling them not to
leave it open if they don't need to and so on.

4. Is running wrkgadm.exe the same as running the User Level Security
wizard from the UI?

As I say I've never run the wizard but I very much doubt it. I have a

step- by-step example on my web site which you might find useful. It does take a
while IMO for the Access security penny to drop but once it does ... :-)

It's dropping, it's dropping, OK!

Cheers, Mike

[Keith Wilby]

"Mike MacSween" <mi******************@btinternet.com> wrote:

You say you've read the FAQ but I detect some holes in your
understanding
:-)
Quite possible. Amazingly enough, there are times when I don't quite
understand things perfectly!

Was meant tongue-in-cheek, hence the smiley.

I've never used the security wizard but it sounds like it is a bad
idea if it modifies your system.mdw.

Well I'll go to the foot of our stairs! System.mdw is there. But the
registry has been altered to make mine the default.

To make system.mdw the default use the Workgroup Administrator. And mind
that penny doesn't hit yer foot ;-)

Good luck!

Regards,
Keith.

[David W. Fenton]

ke*********@AwayWithYerCrap.com (Keith Wilby) wrote in
<Xn************************@10.15.188.42>:

"Mike MacSween" <mi******************@btinternet.com> wrote:

<snip> 1. I work out (after quite a while) that the shortcut has
<to include

the path to the access exe - "path to msaccess.exe" "path to
mdb" /wrkgrp "path to secured mdw file". Or does it? Given that
it's just possible that the path to access may not be the
default I'd rather not have to create shortcuts one by one. Or
does it just have to include the path if I want to use a non
default mdw? I'm putting my secure mdw on the server. At the
clients the system.mdw is still there in the default place. Is
this because I haven't used the wizard? I would actually prefer
to leave it there. Partly because I don't want to have to update
each workstation, and also so that any of the users can do
Access work without me if they want to. Just as admin/blank.

AIUI the entire paths to all three (msaccess.exe, the FE and the
mdw) are required. I have many users across many sites and have
never come across Access being in a non-standard location.

!!!

I have plenty of clients with machines old enough that their hard
drives are partitioned into C: and D:, with Office installed on D.
My home machine has *all* programs installed in D:\Programs. The
C:\Program Files folder does not exist on my PC.

It's not unusual at all.

But, it's not such a big deal, as long as Office is installed in
the default program files location (as indicated in the registry).
A batch file could use the %ProgramFiles% environment variable to
do the job:

%ProgramFiles%\Microsoft Office\Office\MsAccess.exe

would do the trick for any installation that had a non-standard
default location.

The problem here is that most people who install in a different
location do *not* change the registry key that sets the default
programs folder, so this is unlikely to work with any reliability.

You could also get the information from the registry (I forget the
exact registry key name), but it does only work if there's only one
version of Access installed. Wait -- maybe that's wrong. It works
for different versions of access but not for others? I just can't
remember. Yes, I see that for Office97,
HKEY_LOCAL_MACHINE/SOFTWARE/MICROSOFT/OFFICE/8.0/Access/BinDirPath
gives you the path to where MSAccess.exe should live. For Office
2K, it's
HKEY_LOCAL_MACHINE/SOFTWARE/MICROSOFT/OFFICE/8.0/Access/InstallRoot/
Path.

But you have to run something that can get that path, so you might
use an unsecured launcher MDB that figures out where the executable
is and then uses SHELL to launch the secured MDB.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

mi******************@btinternet.com (Mike MacSween) wrote in
<3f***********************@news.aaisp.net.uk>:

1. I work out (after quite a while) that the shortcut has to
include the path to the access exe - "path to msaccess.exe" "path
to mdb" /wrkgrp "path to secured mdw file". Or does it? . . .
If you're using the default workgroup file (set with the workgroup
administrator), no application path is needed, because you're not
providing a workgroup argument. If you're not using the default
workgroup file (which, I gather from later things you say, you
don't want to do), then you need the path.
. . . Given that
it's just possible that the path to access may not be the default
I'd rather not have to create shortcuts one by one. Or does it
just have to include the path if I want to use a non default mdw?
I'm putting my secure mdw on the server. At the clients the
system.mdw is still there in the default place. Is this because I
haven't used the wizard? . . .
The default workgroup file has nothing to do with it. It only
controls what workgroup file is used during the execution of Access
without any /wrkgrp parameter.
. . . I would actually prefer to leave it
there. Partly because I don't want to have to update each
workstation, and also so that any of the users can do Access work
without me if they want to. Just as admin/blank.
If you're specifying a shared system.mdw that is not the one set by
the workgroup administrator, then you need the path to the
application file. My other reply in this thread gives the details
on how to get that from the registry for A97 and A2K. I'm sure from
that, you should be able to figure out how to get the path to
MSAccess.exe for later versions of Access.
2. How do I recreate system.mdw on my machine here?
GroupID, UserID, GroupName, UserName, Password. You don't have to
worry about the Admin groups/users, as those are the same in every
System.mdw (this is why any MDB in which the admin group/admin user
has any rights is not secure, since every Access installation's
default installation has permissions because admin user/admin group
are identical in every copy of Access).
3. There is an autoupdate thingy in this app. Basically at startup
the app checks a version number in a table against an mdb held in
an update folder on the server. If it's the same the mdb opens. If
not it opens an updater mdb, closes, the updater copies from
server to workstation reopens workstation version. Problem I was
getting at the clients was that it wouldn't look at the copy in
the update folder. Trying to open it, presumably (?) using
system.mdw. And of course admin/blank doesn't have any rights on
that database. But once there is a running instance of Access
isn't the same mdw used for any app? At the office it works fine,
because secure.mdw seems to be the default mdw - as far as I could
tell from poking around in the registry. Am I on the right lines
here?
Have a launcher MDB instead of an updater. It will check the
registry for the default location of access and with SHELL execute
the command line necessary to open the secured front end using the
appropriate system.mdw.
4. Is running wrkgadm.exe the same as running the User Level
Security wizard from the UI?

The wrkgadm.exe tool has zilch to do with the user-level security
wizard. All it does is set a registry key for what system.mdw
instances of Access should use if there is no commandline switch
provided.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Mike MacSween]

"David W. Fenton" <dX********@bway.net.invalid> wrote in message

GroupID, UserID, GroupName, UserName, Password. You don't have to
worry about the Admin groups/users, as those are the same in every
System.mdw (this is why any MDB in which the admin group/admin user
has any rights is not secure, since every Access installation's
default installation has permissions because admin user/admin group
are identical in every copy of Access).

Er, is that true? Admins group and admin user are 2 different things aren't
they? With a non-default installation the admins SID is generated from the
WID used for the mdw. So the admins group IS secure, in that case. As long
as the admin user is moved to the users group (who have no permissions).
Somebody can only get in as a member of Admins if they can recreate your
admins group, which would involve knowing the WID you used, and at least one
PID for a memeber of that group.
Admins group has certain irrevocable rights, I thought.

Or have I misunderstood.

Mike

[David W. Fenton]

c.*******@worldnet.att.net.invalid (Chuck Grimsby) wrote in
<sn********************************@4ax.com>:

On Tue, 09 Dec 2003 21:08:06 GMT, dX********@bway.net.invalid
(David W. Fenton) wrote:

I have plenty of clients with machines old enough that their hard
drives are partitioned into C: and D:, with Office installed on
D. My home machine has *all* programs installed in D:\Programs.
The C:\Program Files folder does not exist on my PC.
It's not unusual at all.

Just d:? Wait till you see some of the paths that get used in
Terminal Server or Citrix sessions! Log into one machine, your
home drive is on another, and all the programs are installed on a
3rd machine. Then of course, you have a MDB on another
machine.... Yikes!

Man, I am *so* glad I learned how to use SHGetFolderLocation API
call!

How do you use that in VBA? What does it get you that a registry
key lookup wouldn't? Especially in cases where more than one
version of Access is installed?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

mi******************@btinternet.com (Mike MacSween) wrote in
<3f***********************@news.aaisp.net.uk>:

"David W. Fenton" <dX********@bway.net.invalid> wrote in message

GroupID, UserID, GroupName, UserName, Password. You don't have
to worry about the Admin groups/users, as those are the same in
every System.mdw (this is why any MDB in which the admin
group/admin user has any rights is not secure, since every
Access installation's default installation has permissions
because admin user/admin group are identical in every copy of
Access).
Er, is that true? Admins group and admin user are 2 different
things aren't they?

Yes.
. . . With a non-default installation the admins SID
is generated from the WID used for the mdw. . . .
But all system.mdws that ship with Access are the same.
. . . So the admins group IS
secure, in that case. . . .
No. Never.
. . . As long as the admin user is moved to the
users group (who have no permissions). . .
Not always. Never use the admin group and admin user for anything,
even in a custom system.mdw.
. . . Somebody can only get in as
a member of Admins if they can recreate your admins group, which
would involve knowing the WID you used, and at least one PID for a
memeber of that group. Admins group has certain irrevocable
rights, I thought.
The Admins group exists when the thing is created -- you don't
assign the WID.
Or have I misunderstood.

Maybe I have.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[TC]

I haven't followed all this thread, but here are some answers (below).

TC
"Mike MacSween" <mi******************@btinternet.com> wrote in message
news:3f***********************@news.aaisp.net.uk.. .

"David W. Fenton" <dX********@bway.net.invalid> wrote in message

GroupID, UserID, GroupName, UserName, Password. You don't have to
worry about the Admin groups/users, as those are the same in every
System.mdw (this is why any MDB in which the admin group/admin user
has any rights is not secure, since every Access installation's
default installation has permissions because admin user/admin group
are identical in every copy of Access).
Er, is that true? Admins group and admin user are 2 different things

aren't they?
Yes.

With a non-default installation the admins SID is generated from the
WID used for the mdw.
It is generated from the WID *and* company name *and* organization name. By
that means, a company/organization can have different workgroup files with
different Admins group SIDs (if they choose). This is conceptually the same
as how you can have two John Smiths (in different workgroup files), and theyare< or >are not< the same person (from a security viewpoint), depending on whether they do or do not have the same PID (the person-level analogue of
WID).

So the admins group IS secure, in that case. As long
as the admin user is moved to the users group (who have no permissions).
Somebody can only get in as a member of Admins if they can recreate your
admins group, which would involve knowing the WID you used, and at least one PID for a memeber of that group.
Not quite. They need to know the WID and company name and organization
name - period. And the latter two are not hard to guess, or get from other
places on the PC. Once they have recreated the workgroup file, they just
log-on as the default Admin user (with no password). They need not know any
user of the previous Admins group. The default Admin user is now a member of
the Admins group (in the recreated workgroup file).

Admins group has certain irrevocable rights, I thought.
Yes.


Or have I misunderstood.

Mike

[Mike MacSween]

"TC" <a@b.c.d> wrote in message news:1071028750.993768@teuthos...

Not quite. They need to know the WID and company name and organization
name - period. And the latter two are not hard to guess, or get from other
places on the PC. Once they have recreated the workgroup file, they just
log-on as the default Admin user (with no password). They need not know any user of the previous Admins group. The default Admin user is now a member of the Admins group (in the recreated workgroup file).

Yes, that's what I meant. David seemed to be saying that the Admins group is
never secure or securable. Seems to me not only is it securable, given what
you've just said, but that is actually may be necessary, because of the
irrevocable rights.

Assuming you've denied Admin any rights to the database you secure then a
'hacker' needs at least 5 bits of info. Company Name, Organisation, WID (to
recreate the mdw) and User Name and PID of at least one user who has admin
rights. In other words the things you need to re-create the mdw. That sounds
pretty secure to me (within the usual limitations of Access security).

Cheers, Mike

[Keith Wilby]

dX********@bway.net.invalid (David W. Fenton) wrote:

I have plenty of clients with machines old enough that their hard
drives are partitioned into C: and D:, with Office installed on D.
My home machine has *all* programs installed in D:\Programs. The
C:\Program Files folder does not exist on my PC.

A fair point. I was speaking from my experience working for a huge
corporation where all the PCs (in theory) have the same image. I never have
to worry about where the exe is but I see now that my comment was a little
too 'corporate' ;-)

[David W. Fenton]

c.*******@worldnet.att.net.invalid (Chuck Grimsby) wrote in
<1o********************************@4ax.com>:

The SHGetFolderLocation API calls return all the folder names for
the user's (as well as common) things like My Documents, Recycle
Bin, Drives, Fonts, Programs, Printers, Net Hood, Recent
Documents, etc. The whole list is pretty long, actually. 50 or 60
items.

By using a API call, you don't have to worry about security, or
where the specific key is, etc. And it's also faster (IMHO).

How do you find the location of a specific Access version with it?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

ke*********@AwayWithYerCrap.com (Keith Wilby) wrote in
<Xn************************@10.15.188.42>:

dX********@bway.net.invalid (David W. Fenton) wrote:

I have plenty of clients with machines old enough that their
hard drives are partitioned into C: and D:, with Office
installed on D. My home machine has *all* programs installed in
D:\Programs. The C:\Program Files folder does not exist on my
PC.

A fair point. I was speaking from my experience working for a huge
corporation where all the PCs (in theory) have the same image. I
never have to worry about where the exe is but I see now that my
comment was a little too 'corporate' ;-)

Well, another issue is that Office XP introduces a different
directory structure, so it's not just about images. Unless your
organization has created images that use non-default locations for
Office XP, you'll still never know the exact location of
MSAccess.exe if you're using different versions.

And one of my clients has over 1,000 PCs that were supposedly all
installed from a handful of disk images and, well, turns out people
have installed stuff on top of the original configuration and so
things don't always match what is expected.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Keith Wilby]

dX********@bway.net.invalid (David W. Fenton) wrote:

Well, another issue is that Office XP introduces a different
directory structure, so it's not just about images.

I'll look forward to that in due course, but as yet we have no plans to
move away from NT4!

[David W. Fenton]

ke*********@AwayWithYerCrap.com (Keith Wilby) wrote in
<Xn************************@10.15.188.42>:

dX********@bway.net.invalid (David W. Fenton) wrote:

Well, another issue is that Office XP introduces a different
directory structure, so it's not just about images.

I'll look forward to that in due course, but as yet we have no
plans to move away from NT4!

Office XP runs on NT4.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[TC]

Below:

"Mike MacSween" <mi******************@btinternet.com> wrote in message
news:3f***********************@news.aaisp.net.uk.. .

"TC" <a@b.c.d> wrote in message news:1071028750.993768@teuthos...

Not quite. They need to know the WID and company name and organization
name - period. And the latter two are not hard to guess, or get from other places on the PC. Once they have recreated the workgroup file, they just
log-on as the default Admin user (with no password). They need not know any

user of the previous Admins group. The default Admin user is now a

member of

the Admins group (in the recreated workgroup file).
Yes, that's what I meant. David seemed to be saying that the Admins group

is never secure or securable. Seems to me not only is it securable, given what you've just said, but that is actually may be necessary, because of the
irrevocable rights.

Assuming you've denied Admin any rights to the database you secure then a
'hacker' needs at least 5 bits of info. Company Name, Organisation, WID (to recreate the mdw) and User Name and PID of at least one user who has admin
rights. In other words the things you need to re-create the mdw. That sounds pretty secure to me (within the usual limitations of Access security).
NO, he does NOT need the username and PID of a user of the old Admins group!
When you recreate the workgroup file (using the correct WID, company &
organization), that file includes a default Admin user, with no password,
who is a member of that (recreated) Admins group. So you can log onautomatically<, without knowing >any< previous user name or password, as a

member of the (recreated) ADMINS GROUP.

TC

[TC]

"TC" <a@b.c.d> wrote in message news:1071105560.25499@teuthos...

(snip)

So you can log on >automatically<, without knowing >any< previous
user name or password, as a member of the (recreated) ADMINS GROUP.

Oops, not sure where the CAPITALS came from.

TC

[David W. Fenton]

c.*******@worldnet.att.net.invalid (Chuck Grimsby) wrote in
<c4********************************@4ax.com>:

On Wed, 10 Dec 2003 13:45:09 GMT, dX********@bway.net.invalid
(David W. Fenton) wrote:

c.*******@worldnet.att.net.invalid (Chuck Grimsby) wrote in
<1o********************************@4ax.com>:

The SHGetFolderLocation API calls return all the folder names
for the user's (as well as common) things like My Documents,
Recycle Bin, Drives, Fonts, Programs, Printers, Net Hood, Recent
Documents, etc. The whole list is pretty long, actually. 50 or
60 items.By using a API call, you don't have to worry about security, or
where the specific key is, etc. And it's also faster (IMHO).

How do you find the location of a specific Access version with
it?

You can't. Did I say anything to lead you to believe you could do
that? If so, I apologize. That was certainly not my intent. My
intent was to say that the SHGetFolderLocation is a great API call
to figure out where all the user's "special" folders are,
regardless of what machine they are using (which is especially
helpful in Terminal Server and Citrix environments).

Ah. I thought the problem was how to find the location of Access.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Mike MacSween]

"TC" <a@b.c.d> wrote in message news:1071105560.25499@teuthos...

NO, he does NOT need the username and PID of a user of the old Admins group! When you recreate the workgroup file (using the correct WID, company &
organization), that file includes a default Admin user, with no password,
who is a member of that (recreated) Admins group. So you can log on

automatically<, without knowing >any< previous user name or password, as

a member of the (recreated) ADMINS GROUP.

Of course. Let me get this straight. mydatabase.mdb has been secured with
mywkrgrp.mdw

Which has an admins group, and others. User admin has been moved to the
users group. In the mdb the users group has no rights, therefore neither
does admin.

Somebody 'gets hold' of the WID used to create mywkrgrp.mdw (as well as
company and organization) and creates a new mdw. They don't know any User
PIDs but they 'know' the Admin group PID (because its the same as the WID).
So an Admins group which is identical to the one in the 'real' mdw is
created. They can't recreate any of the orginal members of that group, but a
user Admin is created who is a member of that group, with a blank password.
So has access to everything.

If I've got that right then it doesn't bother me one bit. If in order to
recreate the mdw file you need 3 pieces of information, which a clever
developer could make all hard to guess (presumably you could user
'kj309jds03filds30dof03' as a company name, instead of the real one) then
that's quite enough security for me, given the context of Access security.
Seems to me the Admins group can be made 'secure'.

Yours, Mike MacSween

[TC]

"Mike MacSween" <mi******************@btinternet.com> wrote in message
news:3f***********************@news.aaisp.net.uk.. .

"TC" <a@b.c.d> wrote in message news:1071105560.25499@teuthos...

NO, he does NOT need the username and PID of a user of the old Admins group!

When you recreate the workgroup file (using the correct WID, company &
organization), that file includes a default Admin user, with no password, who is a member of that (recreated) Admins group. So you can log on

automatically<, without knowing >any< previous user name or password,

as a

member of the (recreated) ADMINS GROUP.
Of course. Let me get this straight. mydatabase.mdb has been secured with
mywkrgrp.mdw

Ok.

Which has an admins group, and others. User admin has been moved to the
users group. In the mdb the users group has no rights, therefore neither
does admin.
Ok.

Somebody 'gets hold' of the WID used to create mywkrgrp.mdw (as well as
company and organization) and creates a new mdw.
Ok. The new workgroup file will have an Admins group. That Admins group will
be indistinguishable (to Jet & Access) from the Admins group of the original
workgroup file. It will have an Admin user with no password. If you log on
as that Admin user (with no password), you will (effectively) be logged on
as a member of the Admins group of the secured database.

They don't know any User PIDs...
They don't need to. The new (default) Admin user gives them whatever they
want.

but they 'know' the Admin group PID (because its the same as the WID).
Not sure what you have in mind there. The Admins group has a SID, but
because of how that is constructed, it will never be equal to any PID, or to
the workgroup WID.

So an Admins group which is identical to the one in the 'real' mdw is
created.
Yes.

They can't recreate any of the orginal members of that group, but a
user Admin is created who is a member of that group, with a blank password. So has access to everything.
Exactly.

If I've got that right then it doesn't bother me one bit. If in order to
recreate the mdw file you need 3 pieces of information, which a clever
developer could make all hard to guess (presumably you could user
'kj309jds03filds30dof03' as a company name, instead of the real one) then
that's quite enough security for me, given the context of Access security.
Seems to me the Admins group can be made 'secure'.
Exactly. The only problem is when people use the default workgroup file.
That file has a >blank< WID. So anyone who can grab the company &
organization name from the PC (eg. from the registry), can recreate that
workgroup file (with its associated Admins group & default Admin user).

HTH,
TC

Yours, Mike MacSween

[Mike MacSween]

"TC" <a@b.c.d> wrote in message news:1071196108.852240@teuthos...

Exactly. The only problem is when people use the default workgroup file.
That file has a >blank< WID. So anyone who can grab the company &
organization name from the PC (eg. from the registry), can recreate that
workgroup file (with its associated Admins group & default Admin user).

Got ya. But if I HAVE used a real WID and even entered nonsense for the
company and org then at least the workgroup is a secure as we can expect and
Access workgroup system to be?

Cheers, Mike

[TC]

Yes, that is correct.

Cheers,
TC

"Mike MacSween" <mi******************@btinternet.com> wrote in message
news:3f***********************@news.aaisp.net.uk.. .

"TC" <a@b.c.d> wrote in message news:1071196108.852240@teuthos...

Exactly. The only problem is when people use the default workgroup file.
That file has a >blank< WID. So anyone who can grab the company &
organization name from the PC (eg. from the registry), can recreate that
workgroup file (with its associated Admins group & default Admin user).
Got ya. But if I HAVE used a real WID and even entered nonsense for the
company and org then at least the workgroup is a secure as we can expect

and Access workgroup system to be?

Cheers, Mike

[Mike MacSween]

"Keith Wilby" <ke*********@AwayWithYerCrap.com> wrote in message

XCOPY "M:\KeithWilby\Public\MyGUI.mdb" C:\Temp\MyFolder /I
"C:\Program Files\Microsoft Office\Office\MSACCESS.EXE"
"C:\Temp\MyFolder\MyGUI.mdb" /wrkgrp "M:\KeithWilby\Public\MyWIF.mdw"

That works does it? I can't get a batch file to 'use' a wrkgroup file.

Mike

[Michael \(michka\) Kaplan [MS]]

It actually works well -- as long as you include msaccess.exe in the call
rather than just passing the MDB file.
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.
"Mike MacSween" <mi******************@btinternet.com> wrote in message
news:3f***********************@news.aaisp.net.uk.. .

"Keith Wilby" <ke*********@AwayWithYerCrap.com> wrote in message

XCOPY "M:\KeithWilby\Public\MyGUI.mdb" C:\Temp\MyFolder /I
"C:\Program Files\Microsoft Office\Office\MSACCESS.EXE"
"C:\Temp\MyFolder\MyGUI.mdb" /wrkgrp "M:\KeithWilby\Public\MyWIF.mdw"

That works does it? I can't get a batch file to 'use' a wrkgroup file.

Mike