Super .mdw file surpasses all security 8

[AcquisitiveOne]

I have setup a workgroup for a specific database that I have created. The permissions work great for each user but for some reason if the user uses the system.mdw file it will surpass all security for that database file and the user will be allowed full access. I understand that the admin password needed to be changed in order for this not to happen and i even assigned the admin user to not have any permissions to the database (not even be able to open it). Still the user can get in the database. The weird thing is that on 2 of my computer the system.mdw is located in C:\Program Files\Common Files\SYSTEM and it will surpass all security. On other computers the system.mdw file is located C:\Windows\System\ system.mdw and when you try and open the database with using this workgroup it will say do not have permissions to view database. Some computers have two system.mdw files one in C:\Windows\System\ (this file wont pass security) and one file in C:\Program Files\Microsoft Office\Office\System.mdw (this one will pass security). So my question is why is it doing that. If anyone who isn't in my workgroup happens to be by default assigned to this workgroup they can get in my database. But since there are two mdws how do i know if the security is working please help. Cuz this is making me frustrated! %-(

 

[Guest_imported]

hi,

i have an .mdw-file without the company-information and the workgroup-id. Does anyone know way to get these info's?

jens.thun@delphi-mb.de

 

[Francescina]

For 50$ you can buy a program that can read all the usernames and their passwords of ANY MDW file. Therefore it is not necessary to have the other information that defines the MDW.

 

[FireViking]

hi all,

I have just read all the messages in this post and i think you have all lost the context of the original question that was asked. I have exactly the same problem. The database security features work fine on a single pc that the database was created on. I have put the database and the security file onto a network for a small amount of ppl to access. I placed an icon(shortcut as previously outlined) on each of the pc's i wanted to have access and thought everything was fine until oneday the person beside me in the office accessed the database without any user/password promt. This frightened the liven daylights out of me as the database contained sensitive information.
I have now researched this problem and havnt found a solution.

 

[JeremyNYC]

FireViking,

You're right about the thread getting WAY off topic.

What's going on in your situation is that you haven't fully secured the database. I promise you that it is NOT possible to get into a properly secured mdb without being attached to the MDW with which it was created.

Get the Access Security FAQ (I've got a copy on my website), and read it many, many times. The instructions there for locking down a database may be confusing, but they are accurate.

Jeremy =============
Jeremy Wallace
Designing, Developing, and Deploying Access Databases Since 1995

http://www.AlphaBetCityDataworks.com

Take a look at the Developers' section of the site for some helpful fundamentals.

 

[FireViking]

Jeremy,

I followed the procedure in the FAQ and thank you it worked. I originally created the database and then applied the security wizard to create the workgroup file instead of creating the workgroup first. This obviously isnt the way to do it and I still dont fully understand why it doesnt work in both situations. Any how as long as it is a fix.

cheers and have a lovely Christmas.

 

[JeremyNYC]

FireViking,

Glad to have helped, and that you've gotten your problem sorted.

The reason it works one way and not the other is that the workgroup with which a database is created will always have a way to get into the database, and the default workgroup can always be recreated by Access, whether or not you've secured one copy of that workgroup.

Enjoy the holidays.

Jeremy =============
Jeremy Wallace
Designing, Developing, and Deploying Access Databases Since 1995

http://www.AlphaBetCityDataworks.com

Take a look at the Developers' section of the site for some helpful fundamentals.

 

[FireViking]

Hi all,

Well well!! I cannot beleive this but the security has failed again. It was all working fine, the database was placed on a network and only those with access and permissions could open it. I tested it on a number of occassions and from different computers and I thought it was a winner. Went on holidays and got a call from a work colleague informing me that the security had failed, everyone now had access, for some reason the database was reverting back to the default system.mdw. I had changed the .mdw to a specific name and this is now not recognised by the database. :-(

This is the second time this has happened and cant afford to bother with it anymore. I will write my own security module and use that instead. At least I know that will work.

I do remember seeing a while ago now some code that could give permissions to control access. Can someone point me in the right direction please.

Thank you all for your input.

 

[Francescina]

Fireviking,

There is only one possible explanation for this behaviour:
You did not delete all rights from the standard user and admin (both users AND groups) and replaced them with custom admin and users.
This is why as soon as any standard MDW is used (containing the standard admin and user that have all rights) your application is no longer protected.

P.S.:
Developing your own security-system will not only be extremely time-consuming but can not be more secure than the standard security-system.

 

[FireViking]

Hi all,

Your suggestion Fran made me take a closer look at the FAQ and follow process more precisely. I realised that I didnt follow the last point of creating a new database and importing all tables etc to remove the open/run properties. I think the most important point is to remove all permissions from the users group and create a new specific group with assigned permissions.
This seems to have fixed my problem for now.
I am indebted to you.

 

[KornGeek]

JeremyNYC,
Why is it necessary to trap the user to your mdw file? The way I have done security is to:

1) Create my own mdw file.
2) Remove the "admin" user from the "admins" group.
3) Create a "myadmin" user with all rights set at the user level.
4) Remove all rights from the "admins" group and the "users" group.
5) Enable on the "users" group only the permissions I want everybody to have.

In my understanding, this allows my end-users to use whatever mdw file they want, and still be limited to the permissions I selected for the "users" group. Am I misunderstanding something about Access security? Sleep is for people with no caffeine.

 

[JeremyNYC]

KG,

Hmmm. Never thought about that approach. Does that mean that I could build an mdw and start assigning permissions on my own? That wouldn't be a good thing. Does it mean that users don't have to log in? Depending on what your database does that could be OK or it could be a big risk. In any case, if you can use any mdw, it's a lower level of security than having to use a specific mdw, which contains user and group accounts designed specifically for the database.

Jeremy =============
Jeremy Wallace
AlphaBet City Dataworks

http://www.AlphaBetCityDataworks.com

Take a look at the Developers' section of the site for some helpful fundamentals.

 

[KornGeek]

Jeremy,
Actually, they can build an mdw, but can't assign permissions. This is because their administrator rights have been disabled on everything in the database. I currently don't use the user login (although I might soon, so I may have to re-think this). I believe that by letting the user use any mdw, it is more secure than giving them an mdw with a user with full admin rights. As it was mentioned above, an mdw can be cracked by malicious trolls. The two mdw system mentioned above would protect against this, though.

My main reason for allowing users to use their own mdw's is that they aren't forced to use a shortcut I provide. In my circumstances, this actually reduces my workload by decreasing the tech support calls I get. If users get denied access to the database because they are trying to open the database from within access or by double-clicking the icon, then I will have an angry (and often unreasonable) customer tying up my valuable development time. Do you have issues with this, or have you found a way to deal with it?
Sleep is for people with no caffeine.

 

[JeremyNYC]

KG,

I've never had a single tech-support call about a user not being able to get into my databases, unless it's been a lost password or the network was down.

I don't see how a system in which anyone can get into your database can be considred secure. Certainly the two mdw approach makes the most sense, if you're actually concerned with security.

Of course, if you're (the general you, that is) truly concerned about security, Access is not the product for you.

Jeremy =============
Jeremy Wallace
AlphaBet City Dataworks

http://www.AlphaBetCityDataworks.com

Take a look at the Developers' section of the site for some helpful fundamentals.

 

[KornGeek]

Jeremy,
I guess the issue is that I'm viewing Security not as keeping people out of the database, but instead as a way to limit access to the methods I choose (i.e. not allowing direct editing of tables, etc.).

Now that I'm looking at how to limit who has access, I see that your approach makes sense. How do you allow them to create new users and set their permissions without allowing them to get into protected areas of the program?
Sleep is for people with no caffeine.

 

[JeremyNYC]

KG,

Here's some code I use. I must have gotten some of it from somewhere, but I don't have a note about where. That probably means it came from MS. I have tweaked it some, but it should work in 97 and later versions.

Jeremy

Public Function ChangePassword(sOldPwd As String, sPwd1 As String, sPwd2 As String)
'(c)Copyright 2/6/01 Jeremy Wallace
On Error GoTo Error
Dim wsp As Workspace
Dim uUser As User

Set wsp = DBEngine.Workspaces(0)
Set uUser = wsp.Users(CurrentUser)
If sPwd1 = sPwd2 Then
uUser.NewPassword sOldPwd, sPwd1
DoCmd.Close
Forms!frmswitchboard.Visible = True
Else
MsgBox "The passwords did not match. Please try again.", vbOKOnly + vbInformation, _
"Data Conflict"
End If
Exit Function
Error:
Select Case Err.Number
Case 3033 'wrong current password

Case Else
ErrorTrap Err.Number, Err.Description, "ChangePassword"
End Select
End Function
Public Function DeleteUser(ByVal sUserName As String) As Boolean
'(c)Copyright 2/6/01 Jeremy Wallace
On Error GoTo Error
Dim ws As Workspace

Set ws = DBEngine.Workspaces(0)
ws.Users.Delete sUserName
ws.Users.Refresh
Exit Function
Error:
Select Case Err.Number
Case 3265 'no such user
MsgBox "This user is not present in the Workgroup file."
Exit Function
Case Else
ErrorTrap Err.Number, Err.Description, "DeleteUser"
End Select
End Function
Public Function CreateUser(ByVal sUserName As String) As Boolean
Dim ws As Workspace
Dim usr As User
Dim grpUsers As Group
Dim sSql As String
Dim sPID As String
Dim sPWD As String

Set ws = DBEngine.Workspaces(0)
ws.Users.Refresh
On Error Resume Next
sUserName = ws.Users(sUserName).Name
If Err.Number = 0 Then
MsgBox "The user you are tryping to add already exists.", vbOKOnly + vbInformation, _
"Can't Add User"
CreateUser = False
Else
sPID = "BR" & sUserName
sPWD = sUserName
Set usr = ws.CreateUser(sUserName, sPID, sPWD)
ws.Users.Append usr
ws.Users.Refresh
Set grpUsers = ws.Groups("BRUsers&quot
Set usr = grpUsers.CreateUser(sUserName)
grpUsers.Users.Append usr
Set grpUsers = ws.Groups("Users&quot
Set usr = grpUsers.CreateUser(sUserName)
grpUsers.Users.Append usr
grpUsers.Users.Refresh
CreateUser = True
End If
Exit Function
End Function

=============
Jeremy Wallace
AlphaBet City Dataworks

http://www.AlphaBetCityDataworks.com

Take a look at the Developers' section of the site for some helpful fundamentals.

 

[KornGeek]

Jeremy,
Thanks for the code. Once again, your assistance is appreciated.
Sleep is for people with no caffeine.

 

[Francescina]

Korngeek, Your question:
How do you allow them to create new users and set their permissions without allowing them to get into protected areas of the program?

The answer:
Only users with adminstrator rights (to EVERYTHING) can create new users.
If you absolutely need this feature then you have to deliver a MDW that contains a real administrator (and therefore might be hacked) and use the "prison" form I have been talking about in a former post.

This "prison" form has to be opened automatically once the administrator logs in and gives only access to the user-creation procedure. If the form is unloaded, minimized, closed or left by any other means then your application needs has to close automatically.

I use this "prison" form trick in a couple of my applications and it works 100%, but as far as I remember it was quite tricky to block all non-authorized operations for the administrator.

Happy programming

Francescina