Re: Linked Table-Embed Password
From: '69 Camaro (ForwardZERO_SPAM.To.69Camaro_at_Spameater.orgZERO_SPAM)
Date: 02/21/05
- Next message: WWV: "Protect db"
- Previous message: Douglas J. Steele: "Re: Linked Table-Embed Password"
- In reply to: LindaD: "Re: Linked Table-Embed Password"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 20 Feb 2005 17:08:21 -0800
Hi, Linda.
> When everyone used their own login, it was
> then not secure at all, allowing write. The main reason
> for the one login was the security.
Don't confuse data security issues with data integrity issues. If a
legitimate user writes data or updates data in the table unintentionally,
this compromises the integrity of the data. The consequences of a loss of
data integrity are that reports may come up with incorrect or inconsistent
information.
This is negligence, but is rarely defined as a criminal act.
If an unauthorized user views or copies the data, this compromises the
security of the data. If an unauthorized user changes the data, this
compromises the security, as well the integrity, of the data. The
consequences of a loss of security are that industrial espionage, theft
(especially identity theft), fraud, or blackmail may occur.
These are considered a criminal acts.
Big difference.
> It is a common way to "secure" Access getting into
> main databases, something not to many people bother with,
> not understanding data can be written from Access to the
> other database if the login is not set up with proper
> security.
It may be common, but it's not secure. If you lock the door and put the key
under that doormat or otherwise leave the key in plain sight for everyone to
use, you cannot claim this door is "secure."
A better way to prevent legitimate users from accidently writing to remote
tables is to ensure that the recordset is non-updateable, something that not
too many people bother with because they don't understand that tables don't
have to be linked with the Linked Table Manager in order to view the data in
these remote tables.
HTH.
Gunny
See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.
(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)
"LindaD" <anonymous@discussions.microsoft.com> wrote in message
news:049001c5175e$338201d0$a601280a@phx.gbl...
> As to the security issue you bring up, the "common"
> login/password setup on the IBM400 secure, read-only.
> It's all in how the Administrator of the main system sets
> up the user. When everyone used their own login, it was
> then not secure at all, allowing write. The main reason
> for the one login was the security. The administrator of
> that system has setup view of only 6 table with this
> login. It is a common way to "secure" Access getting into
> main databases, something not to many people bother with,
> not understanding data can be written from Access to the
> other database if the login is not set up with proper
> security. Sorry, I disagree with you on this one.
>
>>-----Original Message-----
>>Hi, Linda.
>>
>>> now we have a secure common login/password.
>>
>>If everyone is sharing the same login ID and password,
> then it is not
>>secure. And if the login ID and password are stored in
> an Access database,
>>then anyone on your PC network can use them to log into
> the AS/400 computer,
>>including hackers.
>>
>>> How
>>> can I embed the login/password into the table links now
> that the links are
>>> already in place.
>>
>>You can't.
>>
>>> The only way I have found is to re-link the table,
>>
>>This is the correct procedure, since the new link will
> store information
>>about the table structure, connection information
> (including user ID and
>>password), and usage statistics for Jet to use the table
> in the most
>>efficient way when creating query plans.
>>
>>> a
>>> difficult and not happy chore when Access seems to lose
> every relationship
>>> in
>>> the process.
>>
>>Then you'll be happy to hear about this time saver:
> Don't bother assigning
>>relationships to remote tables from the front end. No
> relational database
>>can enforce relationships in remote tables, only in
> tables in the current
>>database. Those relationships _must_ be established in
> the back end, i.e.,
>>in the single database that contains the tables on the
> AS/400. If the
>>database on the AS/400 isn't a relational database or the
> tables are in
>>multiple files, then no enforceable relationship can be
> established on those
>>tables.
>>
>>HTH.
>>
>>Gunny
>>
>>See http://www.QBuilt.com for all your database needs.
>>See http://www.Access.QBuilt.com for Microsoft Access
> tips.
>>
>>(Please remove ZERO_SPAM from my reply E-mail address, so
> that a message
>>will be forwarded to me.)
>>
>>
>>"LindaD" <LindaD@discussions.microsoft.com> wrote in
> message
>>news:18D083CC-11AA-4623-B9F4-1914F64065AC@microsoft.com...
>>>I am linking tables in Access 2003 to AS400 via odbc
> setup. Originally
>>> everyone used their individual AS400 login/password
> when prompted on the
>>> Access database open, but now we have a secure common
> login/password. How
>>> can I embed the login/password into the table links now
> that the links are
>>> already in place. The only way I have found is to re-
> link the table, a
>>> difficult and not happy chore when Access seems to lose
> every relationship
>>> in
>>> the process. During the initial link wizard process is
> a box asking to
>>> "save
>>> password" but I can't find where to change it or add it
> except at the
>>> initial
>>> link table time. Help Appreciated. Linda
>>
>>
>>.
>>
- Next message: WWV: "Protect db"
- Previous message: Douglas J. Steele: "Re: Linked Table-Embed Password"
- In reply to: LindaD: "Re: Linked Table-Embed Password"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
