New workgroup assignment?

  • Thread starter Thread starter Luong
  • Start date Start date
L

Luong

Hello,

I have several databases and workgroup created in the past.
Some databases are joined to different workgroup. I could
not find out which database is joined to which workgroup,
so the database is unsecured.

To make life easier, I decided to create one new workgroup
and join all the existing database to this workgroup. Is
it possible to join existing dbs to one workgroup? Because
recreating a new database to replace the existing one is
very time consuming since they are pretty large (approx.
10 mb). Thanks
 
"databases joined to workgroups" is a common misconception. There is
no direct link between the database and the workgroup. Instead there
are accounts (groups and users) defined in workgroups, and database
permissions assigned to those accounts. Thus ANY database can be used
when Access has been started with ANY workgroup, provided the
workgroup contains the appropriate accounts.

So you will need to assign the appropriate permissions in each
database to accounts that exist in your consolodated workgroup. You
could even recreate the accounts from the separate workgroups if you
can remember the key words that were used to create the accounts in
the first place.

See the web site in my signature for additional information.
 
"databases joined to workgroups" is a common misconception. There is
no direct link between the database and the workgroup. Instead there
are accounts (groups and users) defined in workgroups, and database
permissions assigned to those accounts. Thus ANY database can be used
when Access has been started with ANY workgroup, provided the
workgroup contains the appropriate accounts.
Click to expand...

No, that is not the case at all. If you loose the workgroup file, and then
create a new workgroup with eh same users, same passwords for each user, it
will NOT work. I mean, if you could simply create you own new workgroup
file, then you could essentially get into any database, and security would
be a joke!

A workgroup file will ONLY work with the database that it was secured with,
or if you create a NEW workgroup file, you MUST HAVE the used same pid when
you create this workgroup file. If you do NOT have the same pid when you
create, then you can add admins, and all kinds of users and permissions to
that workgroup file, and it will NOT be of any use. I repeat, the work group
file will NOT work! So, if you loose the original workgroup file for a
database, you cannot simply create a new one, and expect it to work. It will
NOT work! (except if create it with the same PID).

If you as matter of course can take any workgroup file, add new users and
permissions, and then gain access to a database that was secured with a
different workgroup file, then you been setting up security ALL WRONG! You
have been missing some steps.

So, while you can argue there is no built in mechanism that selects the
correct workgroup file when opening a database, you most certainly must be
aware that a database is in fact attached to a particular workgroup file, as
other workgroup files will NOT work!. Without question, you MUST use the
correct workgroup file that the database was secured with (or you can create
a new workgroup file, but then the PID's must match)

So, there is most defiantly a connection between the workgroup file and the
database. To state otherwise means you complete miss understand security.

Without such a connection, security would be a joke, as then you could
always create a new group file, and simply give your self admins
permissions.

So, to the original poster:

You can consolidate the workgroup files into one workgroup file if they all
have the same PID. Or, better put, you can use one workgroup file IF you
used the same PID for each workgroup file. If workgroups does NOT have the
same pid, then you will have to join each correct workgroup, open he
database file, and then remove security persimmons. You then will have to
join you new workgroup file, create a new secured database, and import the
objects from that old one (you might be able to change the database owner at
this point...but I am not 100% sure). Regardless, if you used different
PID's when you created your workgroups, then you are most certainly in for a
lot of work...
 
No, that is not the case at all. If you loose the workgroup file, and then
create a new workgroup with eh same users, same passwords for each user, it
will NOT work. I mean, if you could simply create you own new workgroup
Click to expand...

Correct. But if you re-create the users and groups using the same
PID's as was used to create them originally in *any* other workgroup
file, then they will work with the same permissions that they enjoyed
in the original workgroup file.

According to the Jet Database Programmers Guide "... The user name
and PID are fed to the encryption program that generates the SID for
that account". It does not mention the workgroup file name.

This jibes with my experience.

I agree with you that if you could just re-use the names and
passwords, then the security would be a joke, but that's not what I
said.
 
Ah, well Jack, then I am wrong on this!

I did not realize that I could create a group with the same PID, and it will
work for any database group that has the same PID.

My apologies. I am obviously mistaken in the believe that the workgroup id
had to match first.

So, in fact, your statement saying there is no real connection is 100%
correct then!

I don't mind being corrected on this at all. And, point of fact I did not
realize that the only requirement is the PID....
 
No apology necessary, Albert. Your comment made me double-check my
information, which is always a good thing. As the old saying goes "...
learn something new every day", and judging by the depth and scope of
your articles in this newsgroup, you've already done your fair share
of learning!

There is an item in the Microsoft FAQ (#33) that relies on this
characteristic -- it allows you to provide the remote client with
"manage user account" permissions while disallowing other
"admins-type" permissions. It's worth reviewing if you are not
familiar with it. I am just about to implement it with a client of
mine.
 
Back
Top