"Joan Wild" wrote:

> "MattyM" <Mat***@discussions.microsoft.com> wrote in message news:A2144187-6E63-4C34-B679-877EB0782CDB@microsoft.com...
> > Joan,
> >
> >   Originally I didn't have an ID, so I logged into one of the other MDBs
> > with the admin ID and created one for myself, as well as added it to the
> > admins group.
>
> I have a feeling that you are making these changes in the standard system.mdw that ships with Access.  The first step in securing a database is to create a *new* mdw file - that's a very important step.
>
> > The other MDBs don't seem to give the permission issues.
>
> Likely because they aren't secured - the Users Group has permissions to the database (which means that any mdw file would let them use it).
>
> > In any
> > event, I was then able to log into the problematic MDB with my new ID. This
> > seems to tell me that it is using the same MDW as the rest of the apps. Am I
> > wrong in assuming that?
>
> I think you are.  If the Users Group is given any permissions, then that mdb can be opened using any mdw file.  I think that these 'other' applications were never secured, (perhaps were never meant to be secured)?
>
> > As far as clearing the Admin password, I did it on a copy I made from the
> > production server into developement. All of the main files involved are
> > intact. I only did it because to my knowledge no one knows the actual admin
> > password. Figured I would attempt to clear it and see if logging in as that
> > would do any good. Which since I am posting this question you can see it
> > didn't :)
>
> And yet you were able to login with a username that allowed you to create a new user (meaning you logged in as a member of the Admins Group).
>
> I would start by searching your computer for all *.mdw files (be sure to search in hidden and system folders).  Make a note of each path.
>
> Use the workgroup administrator to join one.  Try to open your mdb.  If you are prompted with a username/password, then the mdw you are joined to has a password set for the Admin user (i.e. that mdw was meant to be used with a secure mdb).  If you get in, check the ownership of objects (as long as none are <unknown> you have the right mdw).
>
> Repeat with the next mdw you found.  Try and sort out which mdw belongs with which mdb.  I'll bet that some of the mdb files open just fine using the standard system.mdw (which wouldn't have a login prompt when used).
>
> --
> Joan Wild
> Microsoft Access MVP
>

"MattyM" wrote:

> Joan,
>
>    I searched the server the apps are sitting on and found three different
> MDW files. I copied them back into developement and tested them out, and I
> have the same issue no matter which one I use. I also checked and all the
> objects show <unknown> for owner, which from your statement below tells me
> they're not the right MDW file. At this point I am at a loss, as  can't find
> any other MDW files out there. Do you know of any utilities that can remove
> the ULS from an MDB file, or have any other suggestions? I'm checking into
> other possible issues that could be messing up this application, but think I
> am eventually gonna have to check the code or queries to see what's going
> wrong.
>
> Thanks for all your help!
>
>
>
>
>
> "Joan Wild" wrote:
>
> > "MattyM" <Mat***@discussions.microsoft.com> wrote in message news:A2144187-6E63-4C34-B679-877EB0782CDB@microsoft.com...
> > > Joan,
> > >
> > >   Originally I didn't have an ID, so I logged into one of the other MDBs
> > > with the admin ID and created one for myself, as well as added it to the
> > > admins group.
> >
> > I have a feeling that you are making these changes in the standard system.mdw that ships with Access.  The first step in securing a database is to create a *new* mdw file - that's a very important step.
> >
> > > The other MDBs don't seem to give the permission issues.
> >
> > Likely because they aren't secured - the Users Group has permissions to the database (which means that any mdw file would let them use it).
> >
> > > In any
> > > event, I was then able to log into the problematic MDB with my new ID. This
> > > seems to tell me that it is using the same MDW as the rest of the apps. Am I
> > > wrong in assuming that?
> >
> > I think you are.  If the Users Group is given any permissions, then that mdb can be opened using any mdw file.  I think that these 'other' applications were never secured, (perhaps were never meant to be secured)?
> >
> > > As far as clearing the Admin password, I did it on a copy I made from the
> > > production server into developement. All of the main files involved are
> > > intact. I only did it because to my knowledge no one knows the actual admin
> > > password. Figured I would attempt to clear it and see if logging in as that
> > > would do any good. Which since I am posting this question you can see it
> > > didn't :)
> >
> > And yet you were able to login with a username that allowed you to create a new user (meaning you logged in as a member of the Admins Group).
> >
> > I would start by searching your computer for all *.mdw files (be sure to search in hidden and system folders).  Make a note of each path.
> >
> > Use the workgroup administrator to join one.  Try to open your mdb.  If you are prompted with a username/password, then the mdw you are joined to has a password set for the Admin user (i.e. that mdw was meant to be used with a secure mdb).  If you get in, check the ownership of objects (as long as none are <unknown> you have the right mdw).
> >
> > Repeat with the next mdw you found.  Try and sort out which mdw belongs with which mdb.  I'll bet that some of the mdb files open just fine using the standard system.mdw (which wouldn't have a login prompt when used).
> >
> > --
> > Joan Wild
> > Microsoft Access MVP
> >