How to force (or re-enable) workgroup login prompt (1 Viewer)

Bilbo_Baggins_Esq

Registered User.
Local time
Today, 15:29
Joined
Jul 5, 2007
Messages
586
We are performing migrations of all Office files from the older formats to the newer formats.
We have an automated tool which, in addition to converting the format(s), reads the VBE projects and performs remediation of the existing code for deprecated objects, methods, and constants.

To perform this function, the automated tool cannot encounter any scenario where a password or permission is required.

We encountered a submitted mdb database where the automated tool could not perform edits.

My position is to support the team performing the automated functions as a backup when they encounter problems such as this.

When I first checked the database I noticed it has a startup action that loads a form but there was no specified form in the OnOpen section of the Options.
This told me there was an Autoexec macro.

I was easily able to bypass this by holding the shift key down while opening and the full database opens without loading the form.

I was easily able to determine there are several objects (tables, queries, forms, reports, modules, and macros) that have permissions required through the old style User/Group level permissions.
Not all of the objects had this requirement however.
Some of them had no permission requirements at all.

Additionally, at no time during my initial investigation did any dialog fire to prompt for a login ID or password.

I reported my findings back to the automated team and the submitter of the database who promptly began arguing with me that no permissions should be required because he performs all of his work with none.
Ugh, that is a whole other story.
The fact remains despite whatever other objects he was working with that did not require any permissions, the core elements of the database did and do have permissions required to make changes.

During the course of argument, I joined a communicator session with the submitter to prove to him permissions were required for some of the objects.
I opened his local copy of the database while holding the shift key down.
We were both immediately presented with an old style login in dialog box which I had not seen on my copy of the database.

Needless to say, this finally proved to the submitter the truth of what I was saying, but left us with a problem: how to get logged in.
This database is very old and none of the original admins or developers are around.
Apparently, over time, some new objects like tables and queries and forms and reports have been added to the database which did not have any permissions applied to them
Over time, the so-called “owner” of the database commonly would build new pieces and merely refer back to the permissioned objects without ever the need to change their design or to login.
On his version of the database, bypassing the Autoexec seems to have prompted the login.

Somehow, he was able to locate and obtain a set of login credentials and reported back to me.

We joined another communicator session wherein we were able to successfully log in on an account.
I opened the users/groups dialog to examine the permissions applied with the objective of removing them.
Here is where I made my first mistake (inadverdently).
I had opened the customer original database, not a copy.
Even though I clicked cancel in the users/groups dialog, something did get changed because now when opening the database (holding shift) there is no prompt for login credentials. It just behaves now exactly like my version (the version that was originally submitted).

Initially, I did not necessarily think this would be a problem as I knew I could simply create a new blank database and import copies of all the objects from the old database.
I have since been able to successfully import all of the database tables, forms, reports, and query objects from the permissioned database into a new and clean mdb.
However, the import process would not let me import the modules or the macros due to lacking permissions to do so.
So, I was able to open the modules in the VBE and copy/paste the code into a new module in the replacement database and then apply the origin module name to the module in the replacement database. This too was not any problem.
(BTW: I performed all of this with "Track name changes" turned off in the new database)

However, Access will still not let me open (in design view) or copy/export/import the macros.

So, I seem to be forced back to a position where I need to figure out how I can return the database (either my copy or the submitter’s copy) to a state where it will prompt for login credentials.

Of course, the ultimate goal is to get the last remaining macro objects into the new database, but I have no desire to hack or use other unscrupulous means to achieve this.
I do believe, once I can get the credentials dialog to fire that I can use the known credentials to get logged in and open or export the macros to the replacement database.
If the permissions are retained, then I can simply open them each in design view and recreate them manually.

But the key is, getting the credentials dialog to fire.

So, after this long explanation of why, here is the whole question:
How can I re-enable a database that has permissions required for some objects to prompt for login credentials.

Any Ideas?
 

RainLover

VIP From a land downunder
Local time
Tomorrow, 07:29
Joined
Jan 5, 2009
Messages
5,041
Bilbo

There is an answer somewhere on the WWW that explains how to remove ULS. (User Level Security). It would be good if you could find that because it has the answer you need.

Just to confirm that you have ULS I have a couple of questions.

What Version of Access is the problem DB using.

How do you open the Database. More importantly how does the current user open the Database on his machine. Does he have a shortcut. If so please post the string used in that shortcut.
What are you doing to open the Database on a different machine.
 

Bilbo_Baggins_Esq

Registered User.
Local time
Today, 15:29
Joined
Jul 5, 2007
Messages
586
Hi RainLover and thanks for your repsonse.

I had hoped I was clear, but I guess I was not.

The purpose of my question here today is not to seek guidance on breaking or removing ULS.

I need to re-establish the credential prompt which somehow stopped firing.
Assuming i can get the prompt to fire, I have and can enter credentials.

The submitter is using Access 2007 running on Win XP.
I am running Access 2010 on Win 7 and Access 2003 on Win XP.
All three methods achieve the same result.

As for method of opening, no, it is not from a shortcut which I thought was quite odd.
It was firing the prompt for credentials when opening from a direct double click on the acutal database in the Windows Exploring window.
I am familiar with the method of placing start up switches in the shortcut path leading to the workgroup database.
I get that, but in this case, that is not what was happening.
However, despite what i expected, that was not the case.
 

RainLover

VIP From a land downunder
Local time
Tomorrow, 07:29
Joined
Jan 5, 2009
Messages
5,041
Bilbo

My apologies. Similar questions have been asked before with the user not knowing about ULS. You obviously have experience.

If you killed the ULS would you then be able to upgrade or create different copies on different machines without using the .MDW file.

I thought this the logical answer.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 16:29
Joined
Feb 19, 2002
Messages
42,974
All Access .mdb's are "secured" whether you realize it or not. The default work group is system.mdw. This workgroup file includes an Admin user who is the default user for all databases. The confusion you were experiencing probably had to do with what workgroup was defined in the Windows Registry. The typical procedure to log into a "secured" database is to join a workgroup and then open the database. The problem with this method is that the act of "joining a workgroup" causes Access to record that workgroup in the registry and until you actively join a different workgroup, this is now "your" workgroup. Add to that the fact that you don't actually need to request a password and I can understand why the user who probably joined this workgroup years ago didn't think the app was secured since he never got prompted.

FYI - to anyone who is still using ULS. NEVER, NEVER, NEVER, did I say NEVER modify system.mdw. Always create a new workgroup if you want to "secure" an application and secondly, in order to avoid making it look like ALL your Access apps are now secured by the new workgroup, create a shortcut to start each application and pass in the /wrkgrp (or something like that) switch followed by the workgroup path and name. Using the workgroup this way will NOT modify the registry so what ever workgroup you are permanently joined to (and I hope for your sake it is a clean system.mdw) will not be changed.

For these and many other issues, MS decided to eliminate ULS rather than make it understandable by the average programmer.

At http://www.access-programmers.co.uk/forums/showthread.php?t=226293&highlight=security+faq
I posted the security FAQ and a clean copy of system.mdw. The FAQ tells you how to remove the customized security to revert to the standard system.mdw/Admin.
 

Users who are viewing this thread

Top Bottom