Split Database - Add password from Front End or Back End?

[Cosmos75]

I have a split database.

I intend to make the front end an MDE file and keep the back end an mdb file.

Do I need to add a password to the front end AND back end? or does just one of them need a password? If it's the latter, which end do I add a pasword to? I have a feeling it's the back end, since the front end is already protect as an MDE file putting a password on the front end will keep people from just going in there and change data in the tables manually.

Wanted to get some view from the friendly people here.


I also have a form that automatically opens to ask the user to check if the front and back end are linked and if they aren't linked correctly to ask the user to find the back end. Will that pose any problems?

 

[mission2java_78]

Why should your end users go looking for your backend? Why would you lose the links? I think people make too many assumptions on databases when they are split. I dont think its a good idea to have the end user re-link the tables. I think you should store the path of a back end in a table...when you move it just modify the record. Then in the open event or whatever event you use simply use this record to re-attach the tables.

As for passwords..doesnt your fe already have a password / user name login form? If so why are you double securing this?

Your BE can be safe...talk to your admins regarding NT security.

Jon

 

[Pat Hartman]

To absolutely secure the db, you need passwords on both and you need to remove all table access from the user accounts and use WITH OWNERACCESS in your queries. That way they won't be able to futz with the tables at all and including even opening them to view data. They need only Run permissions for queries created this way. Your access as the admin who created the querydef objects is transferred to the user with run permissions and that allows the user to view or update as you see fit.

 

[mission2java_78]

To absolutely secure the db, you need passwords on both and you need to remove all table access from the user accounts and use WITH OWNERACCESS in your queries. That way they won't be able to futz with the tables at all and including even opening them to view data. They need only Run permissions for queries created this way. Your access as the admin who created the querydef objects is transferred to the user with run permissions and that allows the user to view or update as you see fit.

I truly dont understand how end users are sitting there and poking at the back end??? Dont your end users have other things they could be working on. It seems to me too many people are concerned with the BE. I dont see a big problem with this. If you implement windows security on the path of this BE no one can get to it. Don't you people have admins that monitor what your end users are doing? If you have end users sitting there trying to break your BE..do you really think they are worth keeping in the company?

jon

 

[Travis]

Jon,

First off I want to say that I agree with what you say, but the truth is (to borrow a phrase) "We don't all live in a vaccum".

Not all shops have a good relationship between Network Admins/Hardware Techs/Programming. (fortunatly the one I'm in does have this). Another issue could be that the job is contract or the creation of an Off-The-Shelf application. In each case if the programmer owns the Source Code/DB structure they don't want it comprimised.

Security is also multi-level.

1. Application Security (Application Passwords and Rights)
2. Network Security (Network rights and authentication)
3. Physical Security (Can someone walk in and carry it out)

All three of these need to be addressed or you don't have security.

 

[Cosmos75]

I am not using the system.mdw for security, just a password. I don't know how Access is being used on the clients end and am not real comfortable with the security aspect of Access, which Pat has pointed out that I should sooner or later attempt to become so.

"Why should your end users go looking for your backend? Why would you lose the links?"
It's not that I think someone will go looking for it, just want to prevent the possiblity that if it is out on a network and someone just accidentally opens it and fiddles with it.

I am linking the Front End and Back end using the method OldSoftBoss uses in this link.
http://www.access-programmers.co.uk/forums/showthread.php?s=&threadid=41086

I won't automatically open the Link form on every open. I just want to have a simple way for the user to relink the front and back end should they ever decide to move it to a different drive.

"Another issue could be that the job is contract or the creation of an Off-The-Shelf application. In each case if the programmer owns the Source Code/DB structure they don't want it comprimised."
That is the case. Although by no means do I consider myself a programmer!

 

[Pat Hartman]

I am not using the system.mdw for security, just a password.

- But you ARE! EVERY Access database is secured by system.mdw unless a specific workgroup was created for the db. Access databases are ALWAYS secured. You just don't see it because in the absence of any specifically defined security, Access logs you in to a db as "admin" and gives you all rights. Read some of the posts by people who think they have locked themselves out of every db because they secured a single db.

jon, I don't recommend using Access security and in fact, I avoid it whenever possible. I was simply commenting on what you would have to do to really secure the db. The only place I've had to deal with security issues is when doing work for government contractors or manufacturers in highly competative industries.. They are very security consious and always want their db's locked up tighter than a drumb. Sometimes I feel like they're going to have to shoot me when I leave because I know too much.

 

[Autoeng]

Cosmos:

I've worked with Access security for about 3 years now and since I got the Security Manager Add-in which makes changes to permissions / additions of users a lot easier I prefer it. I only secure my FE's as many times I link to the BE from other db's and don't want the hassel of getting through the security via a link. What I do is I make the tables in the BE hidden and minimize the db window on open. If someone stumbles onto the BE and opens it all they get is a blank screen. If they know enough to hit the F11 key then all they get, unless they have selected "Display hidden objects" in the Options menu is a blank db window. So far, so good.

What did take me a while to understand is that security is not something that you just start the wizard for and off you go. It is imperative to read the Microsoft Security Faq and not just scan through for stuff you think applies to you but read every bit of it. By doing so you will understand the full security schema and how it functions under different conditions.

 

[intrep11]

nice idea

thats a nice idea with the back end

but i still feel a simple form that opens and asks for a password is useful back that with a module that removes the f11 function and the shift function and your back end is only accessable to those you want.

as for why will people go looking the answer is simple ' because they can'

ask most support techs and they will i am sure say that a large number of support calls is from people who fiddle

i had one PC fall over recently because someone had swapped out the pc 133 ram for PC 66 and thought that no one would notice ....

eventually someone will go looking....

 

[mission2java_78]

Re: nice idea

There's a simple solution to those who fiddle around with what they should not be fiddling around with. Its called..loss of employment due to the lack of the employee not doing what he / she is supposed to be doing as well as damaging an application.

Seems simple enough to me.

Jon

 

[intrep11]

If only personnel managers saw it like that

Yes i couldnt agree more but unfortunatelly personnel managers dont see things quite so black and white as you and i do .....

 

[mission2java_78]

Re: If only personnel managers saw it like that

Yes i couldnt agree more but unfortunatelly personnel managers dont see things quite so black and white as you and i do .....

Im not sure where you're going with this. Your structure should record any time a user logs in and any modification to any records, including time and date.

As for passwords...I do agree that this may be a bit more difficult. It troubles me to imagine that people have nothing better to do!

Jon

 

[Cosmos75]

To absolutely secure the db, you need passwords on both and you need to remove all table access from the user accounts and use WITH OWNERACCESS in your queries. That way they won't be able to futz with the tables at all and including even opening them to view data. They need only Run permissions for queries created this way. Your access as the admin who created the querydef objects is transferred to the user with run permissions and that allows the user to view or update as you see fit.

I tried to add a password to the back end but when I did I wasn't able to access it from the frotn end. The front end opened fine but it kept giving me an error message when I tried to open anything that used the tables from the back end.


The way I added a password to the front end was to just open the back end (exclusive) and add a password to it. Is that the way to do it?

 

[TastyWheat]

Short Answer: Protect the backend. The frontend is optional.

Long Answer: The tables are the most important part of any database. It's the foundation, and if someone screws it up then the whole thing crumbles. Intentional and unintentional malicious acts can ruin your day so make sure it's locked down. It's good practice to secure the frontend as well, but it's not necessary to keep things secure. There's nothing a user can do to the frontend that will screw up the backend. Furthermore, the user should have a copy of the frontend so who cares if they screw up their own copy. As always, keep periodic backups of both ends.

 

[boblarson]

And we're posting an answer to an over 4 year old post, WHY?

 

[Banana]

Holy bump, batman!

 

[Muuip]

boblarson: "And we're posting an answer to an over 4 year old post, WHY? "

Because I just happen to read it 7 years later and it is still useful!!!

 

[Frothingslosh]

Klaatu Barada Neck*cough*mumble*

 

[823]

To absolutely secure the db, you need passwords on both and you need to remove all table access from the user accounts and use WITH OWNERACCESS in your queries. That way they won't be able to futz with the tables at all and including even opening them to view data. They need only Run permissions for queries created this way. Your access as the admin who created the querydef objects is transferred to the user with run permissions and that allows the user to view or update as you see fit.

Hi

I resume this old thread because I would need to set a password at my BE.
How can I do?
(The FE already has a login form that works with password)

thanks

 

[theDBguy]

Hi

I resume this old thread because I would need to set a password at my BE.
How can I do?
(The FE already has a login form that works with password)

thanks

May I suggest you start a new thread rather than resurrecting this old one?