Authentication and Password Security - Implementing Database Security and Auditing - page 98

4.1.2 Implementation options: Understand what

authentication types are available and choose
strong authentication

Most databases have more than one authentication option that you can set
up and use. Some databases have a very large set from which you can
choose. Choice is generally a good thing, but it does put the burden on you
to choose wisely. What you should take away from the example in the previ-
ous subsection is that it is very important that you know what authentica-
tion options are available within your database environment and use one
that truly authenticates users trying to access the database.
Let's continue with the DB2 UDB example started in the previous sub-
section and see what a better authentication option might look like. But
first a quick word on the DB2 UDB authentication layer. DB2 UDB does
not have its own authentication implementation (as do Oracle, SQL Server,
and Sybase). DB2 UDB rely on an external authentication system,

most commonly the operating system. For example, when you install DB2
UDB on a Windows system, it automatically creates a new Windows user
for the database administrator, as shown in Figure 4.2. At first this may
seem limiting to you, especially if you're used to another database environ-
ment. As it turns out, most vendors (including Oracle and Microsoft) actu-
ally recommend operating system-based authentication because it is usually
a stronger authentication model and usually provides better overall security.
DB2 UDB CLIENT authentication should never be considered plausi-
ble—at least not with its related defaults. Two additional attributes can help
you refine CLIENT authentication. The first,

must

, can be set TRUST_ALLCLNTS

Figure 4.2

A Windows user is
created when
installing DB2 in
Windows, because
DB2 UDB uses the
operating system to
authenticate users.