Re: Microsoft Access Security Best Practices when linking to a SQL back end

From: Lynn Trapp (ltrappNoSpam_at_ltcomputerdesigns.com)
Date: 02/09/05

  • Next message: tdmailbox_at_yahoo.com: "Re: Microsoft Access Security Best Practices when linking to a SQL back end"
    Date: Wed, 9 Feb 2005 14:22:57 -0600
    
    

    I'm assuming that you will keep the Access frontend. Is that a correct
    assumption? If it is, then your IT personnel are making an erroneous
    assumption. Before Access can verify the username and password in the SQL
    Server table, it will have to actually be opened and have some query run
    from a startup form. If the authentication fails, then you could force
    Access to close. On the other hand, the built in user level security in
    Access authenticates the user before the database actually opens.

    Furthermore, it will be significantly easier for users to mine passwords
    from the SQL table than from the .mdw file. Also, attempting to create your
    own security algorithm is not going to be an easy task.

    -- 
    Lynn Trapp
    MS Access MVP
    www.ltcomputerdesigns.com
    Access Security: www.ltcomputerdesigns.com/Security.htm
    <tdmailbox@yahoo.com> wrote in message 
    news:1107979803.145244.185650@g14g2000cwa.googlegroups.com...
    > Does anyone know where I can find a best practices type document on
    > access security?  Basicly I have a access database application I am
    > writing with a SQL server back end for a bank client.  The application
    > was originally written to use access's own .mdw file for security.
    >
    > However there is a push by the internal IT staff for me to move the
    > security into a table inside the SQL database.  I am not really sure
    > what advantages this would provide and I am trying to make sure I am
    > not missing something.  They are not looking to premission each user on
    > the SQL database, they are looking for me to create a user table inside
    > the SQL backend for the database that I built and have the access
    > databse call that table to verify permissions before granting access to
    > the application.
    >
    > I am trying to determine if there is any advantage to configuring
    > security that way rather then using a .mdw file.
    >
    > Can anyone shead some light on why using an internal(or in this case
    > linked) table would be better to store user ids and password?
    > 
    

  • Next message: tdmailbox_at_yahoo.com: "Re: Microsoft Access Security Best Practices when linking to a SQL back end"

    Relevant Pages

    • Re: MDE
      ... - You are using the incorrect MDW file used to secure the database. ... MDE open or not) select teh menu option Tools> Security> User and Group ... if you don't see the other User Accounts you created when the ...
      (microsoft.public.access.security)
    • Re: access 2003
      ... security in access 2003. ... The data will go on the server and the program database ... than the alternative of creating an mde file. ... MDW file from the written record. ...
      (microsoft.public.access.conversion)
    • Re: Whos in the .ldb first?
      ... If the .mdw file you secured the database with isn't there, ... good indication that your security wasn't set up correctly. ... >>have full permissions on the FOLDER that the database is ...
      (microsoft.public.access.security)
    • Re: Which database should I use?
      ... > and alter the database. ... That is exactly what is possible with SQL server and for a fact with all ... other RDBMS systems but not with Access in combination with a Workgroup ... >only weak point is on security. ...
      (microsoft.public.dotnet.languages.vb)
    • Re: security not requesting log in
      ... If you had done this, then no matter what mdw file she used, ... Another step you should have performed is to secure the database file. ... and delete all the security files and create a new file. ... opens immediately to the main screen and shows her as Admin. ...
      (microsoft.public.access.security)