Re: Security Gotchas in IBM's UDB for Windows NT
[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Security Gotchas in IBM's UDB for Windows NT
- To: NTBUGTRAQ
LISTSERV.NTBUGTRAQ.COM
- Subject: Re: Security Gotchas in IBM's UDB for Windows NT
- From: "Colman, Clem" <Clem.ColmanDVA.GOV.AU>
- Date: Wed, 1 Jul 1998 11:01:17 +1000
- Reply-To: "Colman, Clem" <Clem.ColmanDVA.GOV.AU>
- Sender: Windows NT BugTraq Mailing List <NTBUGTRAQLISTSERV.NTBUGTRAQ.COM>
Folks, Dale Hagen from IBM responded to my message in NTBUGTRAQ and sent
me this information.
I would like to thank him for his quick response. I have only one
comment on his advice and that is that it seems that it is possible for
an unpriviledged user to create local groups in a domain. This behavior
is documented in NTBUGTRAQ. Does anyone know of a fix for this behavior
in general?
Dale does offer a configuration that should enhance security for UDB and
overcome this problem through the use of the DB2_GRP_LOOKUP flag.
Regards,
Clem.
>----------
>From: Dale Hagen[SMTP:hagenca.ibm.com]
>Sent: Tuesday, 30 June 1998 1:02
>To: Colman, Clem
>Cc: Tim Vincent; ichd1us.ibm.com; Jan Hedges; Ed Bradford
>Subject: Security Gotchas in IBM's UDB for Windows NT
>
>I am the development manager for UDB on Intel platforms and I'd like to
>discuss
>your concerns with you. Let me first begin by discussing the way DB2
>works with NT security.
>
>
>If you choose to use client authentication (its also a good practice even if
>you use server authenticaiton) then we recommend that you do the following:
>
>Enforce Domain Logon. That is, require that each user log on to the Domain.
>EITHER (only create groups at the Domain Controller) OR (on each Database
>Server create groups that contain Domain Accounts AND set the registry option
>on the database server to only use local group lookup (db2set
>DB2_GRP_LOOKUP=local))
>Only trust Windows NT clients, ie force windows 95 and windows 3.1 clients
>to
>provide a userid/password on the connect statement. Do this by updating the
>DBM
>config file with "db2 update dbm cfg using trust_allclnts no" and "db2 uddate
>dbm cfg using trust_clntauth server". This will force those clients to
>explicitly provide a userid/password and that userid/password will be
>authenticated at the server ONLY.
>
>When db2 receives an implicit connection request with a userid extracted from
>the operating system, it uses LookupAccountName to find out where this
>userid is defined. LookupAccountName provides us the name of the domain where
>the userid is found. We determine the machine that the account is defined in
>and if DB2_GRP_LOOKUP is NOT defined as local, we will go to that machine to
>enumerate groups. If it is defined, then we will enumerate groups locally.
>
>In your scenario, I assume that X was defining groups on the domain
>controller,
>since we would never go to the client machine to enumerate groups. I don't
>want
>to minimize this point, your X is not only sinister but he/she is a sinister
>Domain Administrator.
>
>However the db2 administrator on the db2 server machine can protect himself
>by
>setting DB2_GRP_LOOKUP to local.
>
>Then when x connects to machine "db2server" with his domain account
>"domain\x"
>db2 will enuermate groups for the fully qualified name "doman\x" on the LOCAL
>machine ONLY. Since x is NOT a member of UDB_Admin on the LOCAL machine, he
>will not be sinister w.r.t DB2.
>
>Do you still have concerns?
>
>... Dale
>---------------------- Forwarded by Dale Hagen/Toronto/IBM on 29/06/98 09:45
>AM
>---------------------------
>
