Page 1 of 2 12 LastLast
Results 1 to 15 of 20
  1. #1
    Join Date
    Mar 2007
    Location
    Bedfordshire, UK
    Posts
    64

    Unanswered: Hidden objects and database security

    Is there any way of requiring users to input a password before viewing hidden objects? I have written a database for staff at a local school, and was assured it would be secure because "no-one on the staff knows anything about Access". I was led to believe that it would be sufficient to set the startup to display the Switchboard and not the database objects window. However, within a week or so, odd things began to happen to the data and it was obvious that someone had been opening the database window by holding shift when launching the database. They had been making changes to tables directly and this had been screwing up the data. OK - so I next tried hiding every object by right-clicking and setting the property to "hidden". Now I'm worried that someone will discover that they can click Tools - Options - view tab - check "view hidden objects".
    Is there any way of securing these, or am I going to have to go down the route of setting up permissions and access rights etc just for the odd person for whom "a little knowledge is a dangerous thing"?

  2. #2
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    first off deploy your model as an MDE
    split the data from the front end (but you may already have done that)

    consider assigning system objects to a specific user other than admin
    make sure each person connecting to the app uses a specified workgroup (not the default workgroup). this can be done via a shortcut which uses the command line switch to specify the workgroup... do a google on access command line switches. make sure your app boots any user out of th eapp if they are not in your workgroup with appropriate permissions. having doen that make sure that the ungodly cannot chaneg the settings in that workgroup (keep the number of adminstrators down to the absolute barest minimum and the people you cna trust (for preference that'd be 1 in my case and I have doubts about me)
    consider binning the access user id and instead use the network logon... PKStormy has some good stuff here (look at the code bank or do a search here), personally I use Dev Ashish's API calls
    assign appropriate network permissions on the data back end so that the ungodly cannot access the data from any other application

    read the Access security FAQ on the microsoft website



    never ever trust the user, they are almost as disingenuous and dishonest as the boss \and marginally more trustworthy than your local politician
    Last edited by healdem; 06-11-07 at 12:06.
    I'd rather be riding on the Tiger 800 or the Norton

  3. #3
    Join Date
    Mar 2007
    Location
    Bedfordshire, UK
    Posts
    64
    Thanks - sounds a bit complicated but I'll give it a go. You're right - I have already split the database into a FE and BE.

    Quote Originally Posted by healdem
    never ever trust the user, they are almost as disingenuous and dishonest as the boss \and marginally more trustworthy than your local politician
    LOL! And I thought I could trust teachers (pillars of society etc etc)

  4. #4
    Join Date
    Jun 2005
    Location
    Richmond, Virginia USA
    Posts
    2,763
    Provided Answers: 19
    "no-one on the staff knows anything about Access" is probably true; they didn't, however, say anything about the students, did they?
    Hope this helps!

    The problem with making anything foolproof...is that fools are so darn ingenious!

    All posts/responses based on Access 2003/2007

  5. #5
    Join Date
    Mar 2007
    Location
    Bedfordshire, UK
    Posts
    64
    You're right, Missinglinq, but in this case none of the students are over 7 years old and the database sits on the Admin network to which students have no access! Mind you - hackers and crackers are reportedly getting younger and younger these days aren't they.

  6. #6
    Join Date
    Jun 2005
    Location
    Richmond, Virginia USA
    Posts
    2,763
    Provided Answers: 19
    You got that right!
    Hope this helps!

    The problem with making anything foolproof...is that fools are so darn ingenious!

    All posts/responses based on Access 2003/2007

  7. #7
    Join Date
    Mar 2007
    Location
    Bedfordshire, UK
    Posts
    64
    I'm still having some problems with this. I worked through the User-Level security wizard and created a secured database. During this process I added a new user called "staff". However, whenever I try to run the database I get the message "You do not have the necessary permissions to use the <database> object. Have your system administrator or the person who created this object establish the appropriate permissions for you."
    This is irritating because I AM the person who created the object! As well as help from this forum I've also been relying on the book "Microsoft Access Inside Out", and it describes that at this point a Logon dialog is supposed to open to give the user the opportunity to input a username and password.

  8. #8
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    did we read and follow all the step required in Access security FAQ?
    have you joined an access workgroup, and have all the other instances of this application joined the same workgroup

    have you set a password on the staff user account.

    personally I think you are missing a trick by creating a single userid 'staff'.. but then again you can always find who is the network user id when you write your audit log, so you know who (or at least what network user id & computer) did waht. that way round when something goes wrong with your data you don't need to spend 2..3 hours playing cluedo you know immediately who murdered the data using what computer. leaves a lot more free time for the post investigation necklace party when the guilty get their just deserts
    I'd rather be riding on the Tiger 800 or the Norton

  9. #9
    Join Date
    Mar 2007
    Location
    Bedfordshire, UK
    Posts
    64
    I don't know what I did wrong the first time I ran the wizard, but I just tried again from scratch and it worked fine. I've set it up so that although the user can still see the database window by holding shift when opening the database, they can't delete anything I don't want them to delete. This covers deliberate or accidental deletion of data (which is what I wanted to achieve).
    I've found that I can further deter any shenanigans by setting the database to run in "runtime mode" by setting up an appropriate shortcut with a runtime switch, then setting the target database properties to "hidden". I hope these two measures together will prevent any further users from ferretting around under the lid. I suppose the only foolproof method would be to write the whole thing in C# or VB and creating an exe file but I don't think my programming skills would be up to the task (presumably though this would only result in a front end which accessed the back end tables which would still be vulnerable).

  10. #10
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    its very difficult to stop a determined miscreant when using access data. the best you can do is deter them, Standard access security is fine for people who dabble, but if they have access to the Access there is little that you can genuinely do stop the knowledgeable ABuser.

    The most effective way to deter is to deploy the db as an MDE (encrypt the db).. that way round the users cannot access any of the guts of the application they cannot make any design changes, they can only see what you allow them to see. by carefull use of the user logons and workgroups security the same access model can support a security policy that only lets each user see what each user is supposed to see, they can only change what they are allowed to.

    If security is a problem then you also need to make sure you back end is also protected, its very easy for someone to create a new access front end app connecting to your data.
    I'd rather be riding on the Tiger 800 or the Norton

  11. #11
    Join Date
    Mar 2007
    Location
    Bedfordshire, UK
    Posts
    64
    As I said earlier, in this case it's one or two teachers who deny knowing anything about Access, but who have discovered how to get at the database window by holding shift. (Actually, I'm 90% sure I know who it is, but "workplace politics" is, I am told by the school's head teacher, a factor here). They believe they're being clever and "helping", but all that's happening is that data is getting deleted, unwanted data is being added and it's corrupting stuff and confusing other users. Specific example is a combo box which lists the names of classes in the school - suddenly several class names disappear and have to be re-input, also other class names appear in the list more than once - that sort of thing.

  12. #12
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    so
    track the network logon, use PKstormy's or Dev Ashish's functions
    tack everything that ech user does update an audit file showing who did what using what computer. dont allow users to delete records, flag them as no longer valid

    make sure that users logon on in their own name, and always logoff when they are not using the computer. make sure that no one 'borrows' someone else's userid/logon

    that way round you have the evidence you need to do what ever is required to stop this happening.

    restrict system configuration / masterfiles to a limited number of users

    fundamentally if you leave your applciation open then when it comes to the blamestorming you have left yourself wideopen

    deploying as an MDE means that users cannot change the app, they cannot circumvent the app by pressing the shift key. if you value your time and reputation then do it urgently. letting your users look at data in datasheet form, or allowing the to see the raw tables is asking, if not demanding trouble for you as the developer
    I'd rather be riding on the Tiger 800 or the Norton

  13. #13
    Join Date
    Mar 2007
    Location
    Bedfordshire, UK
    Posts
    64
    Quote Originally Posted by healdem
    track the network logon, use PKstormy's or Dev Ashish's functions

    that way round you have the evidence you need to do what ever is required to stop this happening.
    Healdem, thanks for your advice. Please could you point me towards PKstormy or Dev Ashish's functions? (Presumably they are freely available to copy/adapt).

    Cheers.

  14. #14
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    Quote Originally Posted by kabuki
    Healdem, thanks for your advice. Please could you point me towards PKstormy or Dev Ashish's functions? (Presumably they are freely available to copy/adapt).

    Cheers.
    dev Ashish's api's can be found on google doing a google using say 'dev ashish api' came up with 26,000 hits on google UK, and the userid api call was number 2 on the list.

    PJStormy's are going to be in either the code bank here, or do a search on this site for say.

    have you actually bothered to look. Ill give you a hint PKStormy's stuff is in the Access Code Bank.
    I'd rather be riding on the Tiger 800 or the Norton

  15. #15
    Join Date
    Mar 2007
    Location
    Bedfordshire, UK
    Posts
    64
    Quote Originally Posted by healdem
    have you actually bothered to look. .
    What a rude person you are, healdem. I asked politely for advice and said thank you when you gave it. Yes, I DID bother to look in the code bank, but your command of English grammar, punctuation and spelling is so wobbly it wasn't clear from your post what exactly I should be looking for. I don't need to get involved in a slanging match, but please don't bother to offer answers to any future questions I might post in good faith - there are plenty of people on here who are more expert, more helpful and more polite than you!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •