Hi All;
On a DB2 v9.1 (DPF) - RH Linux server, we have a local userid EXECMSTR
that has dbadm privileges and executes all batch processing to load
and maintain a large data warehouse application. The database server
allows authentication client for some applications. It appears that
this configuration would allow a local (client) user to be defined as
EXECMSTR and come into the database server with dbadm priveleges!
Obviously, this fits into the category of "a bad thing"...

What am I missing? There must be some way to support authentication
client for certain users and not for others. Can someone point me to
what I need to look at? I have spent ALOT of time with several
different security-related config parms and can't get a good handle on
the solution to this. Thanks very much!

Pete H

On Nov 21, 8:10 pm, peteh <phazz...@intellicare.com> wrote:
[...]
> What am I missing? There must be some way to support authentication
> client for certain users and not for others.

I'm not sure I follow what you are saying. Would it be enough to know
the name of such a user to get access to the database?

>Can someone point me to
> what I need to look at? I have spent ALOT of time with several
> different security-related config parms and can't get a good handle on
> the solution to this. Thanks very much!
>

Would it be possible to solve at the OS level instead of at the DBMS
level? You could for example set up ssh-keys for the client on the
server, and then log in via ssh and do your stuff at the server. Such
solution would only allow access from certain machines, certain users.

/Lennart

Lennart wrote:
> On Nov 21, 8:10 pm, peteh <phazz...@intellicare.com> wrote:
> [...]
> > What am I missing? There must be some way to support authentication
> > client for certain users and not for others.
>
> I'm not sure I follow what you are saying. Would it be enough to know
> the name of such a user to get access to the database?
>
> >Can someone point me to
> > what I need to look at? I have spent ALOT of time with several
> > different security-related config parms and can't get a good handle on
> > the solution to this. Thanks very much!
> >
>
> Would it be possible to solve at the OS level instead of at the DBMS
> level? You could for example set up ssh-keys for the client on the
> server, and then log in via ssh and do your stuff at the server. Such
> solution would only allow access from certain machines, certain users.
>
> /Lennart

Thanks for your reply Lennart. The issue is that the userid has been
established on the server for production work (with dbadm auths) and
it appears that any old workstation client could set up a local user
with the same name. Once that user is authenticated on the client, it
can connect to the database (via database connect, not direct login/
ssh) and have VERY powerful priviledges.

Do you see the exposure here? It appears that once we allow
AUTHENTICATION CLIENT (which we have to do for some applications), we
cannot control access for client users who share id names with users
defined on the server. This is why I know I must be missing
something... Thanks again.

Pete H

On Nov 23, 3:31 pm, peteh <phazz...@intellicare.com> wrote:
[...]
> Do you see the exposure here? It appears that once we allow
> AUTHENTICATION CLIENT (which we have to do for some applications), we
> cannot control access for client users who share id names with users
> defined on the server. This is why I know I must be missing
> something... Thanks again.
>

I'm well aware of the security issues with AUTHENTICATION CLIENT. If I
understood you correctly, you would like to use AUTHENTICATION CLIENT
from some machines/some users, and AUTHENTICATION SERVER for the
rest . AFAIK that is not supported at the DBMS level. Would the
following be an option?

Use AUTHENTICATION CLIENT on your existing server, and restrict access
via firewall to your trusted clients. Add another server with
AUTHENTICATION SERVER and catalog all the databases from your current
server there. Just a thought, haven't tried it myself

/Lennart

Lennart wrote:

> On Nov 23, 3:31 pm, peteh <phazz...@intellicare.com> wrote:
> [...]
>> Do you see the exposure here? It appears that once we allow
>> AUTHENTICATION CLIENT (which we have to do for some applications), we
>> cannot control access for client users who share id names with users
>> defined on the server. This is why I know I must be missing
>> something... Thanks again.
>>
>
> I'm well aware of the security issues with AUTHENTICATION CLIENT. If I
> understood you correctly, you would like to use AUTHENTICATION CLIENT
> from some machines/some users, and AUTHENTICATION SERVER for the
> rest . AFAIK that is not supported at the DBMS level. Would the
> following be an option?
>
> Use AUTHENTICATION CLIENT on your existing server, and restrict access
> via firewall to your trusted clients. Add another server with
> AUTHENTICATION SERVER and catalog all the databases from your current
> server there. Just a thought, haven't tried it myself
>
> /Lennart

Authentication client requires that you can trust your clients. This means
that all clients must be locked down so that local security can't be
changed and no foriegn machines are permitted to access the network. If you
can't secure the attached workstations and servers to this level then do
not use client authentication for any database that requires even a minimal
amount of security.

Colin