oracle database enterprise user security - a practical example

Database Administration

OORACLERACLE D DATABASEATABASE E ENTERPRISENTERPRISE U USERSER SSECURITYECURITY – –

A A PRACTICALPRACTICAL EXAMPLEEXAMPLE

Gary Gordhamer, GE HealthcareJanet Wakeley, GE Healthcare

ABSTRACT This presentation will go over what is Oracle Database Enterprise User Security (EUS) and using it with Oracle Internet Directory (OID). Included is an overview of the architecture, an example design, and details of a real world installation. EUS is an Oracle Database Enterprise Edition feature that enables centralized control of database users. This requires many underlying technologies including LDAP, shared schema security, OID, and enterprise roles.

TABLE OF CONTENTS Abstract................................................................................................1Table of Contents.................................................................................1Introduction.........................................................................................2What is EUS?........................................................................................2

What is Database Security?..........................................................................2Users, Rights, Passwords.............................................................................2OID / OVD / LDAP.........................................................................................3Licensing requirements for EUS..................................................................4Other Security options (OS User, AD, NDS, etc…)......................................4

A world without EUS............................................................................5Benefits of EUS............................................................................................5A note about schemas...................................................................................6

What do you need to implement EUS?.................................................6Technical Components to make EUS work..................................................6Database Configuration................................................................................7Process Changes..........................................................................................8How does it work? / Troubleshooting EUS...................................................9Troubleshooting solutions quick list...........................................................11

What’s in the logs / Audits?................................................................12What does EUS not do?......................................................................12

SYSDBA......................................................................................................12ASM............................................................................................................13OS (orace:dba)............................................................................................13Other Shared Accounts..............................................................................13

1 Paper # 281


Real World experiences......................................................................13Next steps...........................................................................................15References.....................................................................................................15

INTRODUCTION Oracle Enterprise User Security or EUS is a feature of the Oracle database that goes back to at least Oracle 8i. In both Oracle 8i and 9i, EUS was documented in the advanced security guide. As of 10g and 11g it is now elevated to, it’s own documentation set and is moving towards being the primary security method for centralized access. The primary usage for EUS is to centralize privileged users that have backend database access. This is generally IT support staff, such as application developers, and database administrators.

EUS alone lacks the features needed to work effectively with multi-tier applications and web based interfaces for end user application access. However, since it is based on directory services, you can easily use EUS in conjunction with other security features and your directory to provide seamless access across multiple technologies.

WHAT IS EUS? EUS allows you to have a central directory of database user accounts. Multiple databases can authenticate users based on information in the directory. Database privileges or authorizations can also be centrally controlled in the directory. For EUS to work you need to be using an Oracle supported directory, as of 11g that means using Oracle Internet Directory (OID) or Oracle Virtual Directory (OVD). Either way you will need a directory that contains the Oracle Context, a specialized section of the directory to store Oracle database information.

WHAT IS DATABASE SECURITY?Lets cover a little bit about Oracle database security. Database security design has evolved from two concepts, the schema and the user. The schema is a collection of structures such as tables, indexes, data, and has properties like quota or table space. Users are the access into the database that could represent people, servers, or applications; and have properties such as passwords, rights and roles. By default in Oracle, every user is a schema and every schema is a user, which is occasionally confusing.

In a traditional model, every user that can login to the database is stored in the data dictionary along with their passwords. If you have multiple databases, each database has it’s own data dictionary, and therefore it’s own set of users and related passwords used to authenticate the users. Each database has it’s own rules on password complexity, expiration, and locking.

2 Paper # 281


Oracle also offers an add on package for the database called Advanced Security Option that can be used to provide stronger authentication using external or 3rd party adapters to authenticate user passwords or tokens. This is not specifically a centralization of authentication but is a much more secure method of authentication than traditional passwords in the database or OS authentication. Advanced security can be used in conjunction with EUS.

USERS, RIGHTS, PASSWORDS

Historically it was common to have a shared account and password that was used by many people to access the database. Generally, this level of access was limited to application developers, support teams and DBA’s. Although this was not the most secure, it was generally accepted due to the limited scope of people and the responsibilities of each person. Shared accounts were then given out to users based on the rights they needed.

As the regulatory environment has matured, it is now required more often than not, that everyone has their own user ID to access individual systems. This enables finer grain audit trails, and accountability for access to personally identifiable or sensitive information stored in the systems. In large Oracle database environments, this quickly becomes impossible to manage using traditional methods.

One early option to overcome the islands of security was OS authentication. Although this was usable, it suffered from large security holes and was relatively easy to circumvent on some platforms.

OID / OVD / LDAPWhat sets EUS apart from the previous security technologies from Oracle? Its primary difference is the usage of an external directory. In this case, the directory is a LDAP compliant system and is required to be Oracle based with either OID or OVD products. Each of these products has their own benefits and issues.

So, what is LDAP? LDAP or Lightweight Directory Access Protocol is an industry standard for storing information in a central directory and rules on how to access that data. The term standard here is loose. The standard is focused mainly around how to query and update the directory and some specific standards on some things in the directory. Outside of that, each vendor (or open source project) is free to implement the details of their directory in any manner they see fit. It allows for extensive customization and extending of what is stored in the directory. Although this has allowed for beneficial additions, it also creates an environment of compatibility issues and confuses users of the technology.

However, we are not here to explain LDAP, just describe its role in EUS. Therefore, for EUS it is required that we use an Oracle branded LDAP. Lets

3 Paper # 281


start with Oracle Internet Directory. This is a full feature stand-alone LDAP implementation from Oracle. OID provides all the features of an LDAP directory and can be used to centralize almost everything that most other LDAP directories can. It does have some compatibility issues, and not every LDAP compatible application will work with it. In general, most things will. OID’s high availability, scalability, and security features make it ideal for complex Oracle environments requiring adherence to the ever increasing global regulator mandates.

Some of the down sides to OID are that it is a separate application that requires configuration, setup, disaster recovery, management, etc…. It may also interfere with your company’s standard if there is already a different LDAP implementation in house. Included features of OID are its ability to be a Directory Integration Platform, allowing it to synchronize with SunONE iPlanet, Microsoft Active Directory, Novell eDirecotry and OpenLDAP. Another integration solution is to use one of the many identity management products on the market that will help synchronize across multiple directories. These features may work as a benefit or a determent depending on your environment.

Therefore, if OID does all this then what is Oracle Virtual Directory (OVD)? As the name implies, OVD is a lightweight virtual directory service that accesses identity information directly from the source and in real-time. It provides a single, consolidated directory interface to identity data regardless of the type of repository it exists in and without needing to synchronize the information into a central repository. Most companies cannot centralize all of their data into a single directory due to various reasons such as internal data ownership or system attribute requirements.

It can front-end either a Microsoft Active Directory or SUN iPlanet LDAP and allow them to act as an OID implementation for other Oracle products. Benefits of this is not having to setup another directory service in your environment and OVD can link multiple directories together and allow them to appear as one to Oracle products. Down sides of OVD include the requirement to extend the back end directory with the Oracle Context, and the requirement to run another application tier. In addition, some legacy Oracle products such as E-Business Suite are not yet certified to work with OVD.

4 Paper # 281


Table 1- Compatibility Matrix

Directory EUS in 9i EUS in 10g EUS in 11g

Oracle Internet Directory 10g (9.0.4 or later)

Supported Supported Supported

Oracle Internet Directory9i (9.2)

Supported Not Supported Not Supported

Oracle Virtual Directory(10.1.4.2.0)

Not Supported Supported N/A

Microsoft Active Directory

Support for Oracle8i functionality only

Supported by integrating with OID or with OVD

Supported by integrating with OID

LICENSING REQUIREMENTS FOR EUSStandard Enterprise User Security that is password based is included with your enterprise edition license for the database. Password based means that passwords are used to authenticate databases to the directory and users to the database using the directory. There are additional features for authentication that include encryption, external tokens and biometrics. These features of EUS are part of the advanced security option for the database and require additional licensing.

In addition, you will need to license the directory product that you choose. OID is included in the Oracle Internet Application Server Enterprise Edition. OVD is part of Oracle’s Identity Management product line.

OTHER SECURITY OPTIONS (OS USER, AD, NDS, ETC…)Outside of EUS, there are other security options for database level users. The earliest and still most common is some form of OS integration for security. There are two main options here. The first is using an OS level group to control access to the database with SYSDBA or SYSOPER rights. This is helpful for administrators, but does little for developers or application support people. In addition, all of this is only logged in OS level files, and is not available in the AUD$ table.

Secondly, you can use OS authentication by creating database users and schemas that match OS users. This generally requires usage of a special prefix in Oracle or the use of specific networking and client requirements (such as NTS or NDS).

Both of these options may require direct host access for the database server, or at least specific client and database server OS requirements. For

5 Paper # 281


example, NTS authentication requires that the database server is a Windows system and the clients using NTS authentication are Windows based systems. On many platforms, OS authentication can also be considered insecure due to the ability to easily spoof it. For the purposes of EUS, these technologies are other options that have different requirements, different benefits, and different limitations.

A WORLD WITHOUT EUS So lets just give a basic scenario where you have nine databases and four database administrators (DBA’s). From a business process standpoint, three groups want to approve access to those systems; Security; the DBA’s managers; and the application Center of Excellence (COE). If we do not use some form of central security that means that each DBA would have an account in each of the nine databases. Each account would have to link to the approvals for each group somehow. Each database also has to have profiles (rules) setup for password complexity, expiration, etc… To verify compliance of these items, make any changes, or remove an account all nine databases would have to be visited. Visually it might look something like this:

PRD

DEV

STG

Oracle Databases

DBA_USER1

Mangers

COE’s

Security

PasswordhistoryPasswordhistory

Account lockingAccount locking

Password expiration and aging


Password verificationPassword verification

Features

PRD

DEV

STG

PRD

DEV

STG

DBA_USER4

DBA_USER3

DBA_USER2

Figure 1 – Example of not using centralized security

Admittedly, this is a little over simplified, but it at least gives an idea of what this process might look like. If you were to multiple this by 10 fold (40 DBA’s, and 90 databases) it gets even more complex.

BENEFITS OF EUSSo here is where the benefits of using EUS come in. EUS allows you to centralize Management of accounts Single locking and termination of accounts Single or few locations to view granted roles (not necessarily rights) Central control of password and simplified password synchronization if

needed

6 Paper # 281


Extensive options for password management such as complexity, reuse, expiration etc…

Abstraction of security functions from physical databases (i.e. security administrators need access to the directory not to the databases)

7 Paper # 281


This is achieved by moving the passwords, accounts and even roles to the LDAP directory. In LDAP terms the database roles are represented as groups. Users in LDAP that are members of these groups then get the rights from the roles in the database mapped to this group. This mapping can be done on a one by one basis, or for entire groups of databases.

A NOTE ABOUT SCHEMAS

EUS provides the ability to use either a shared or a private (exclusive) schema. You will need to consider the pros and cons of each option, and you can actually do some of both. But there is definitely a trade off. For shared schema, all users are mapped to a single schema in the database. This allows users to be added or removed from LDAP simply, with no setup on each database (beyond the initial setup). This also means that user share the same basic things like tablesapces, quota, etc.. They do not however share rights. Rights come from group membership that can be mapped through EUS, unless of course that right is granted directly to the schema.

In a private or exclusive schema, each user in the LDAP has their own schema in the database or databases. This means that when a user is added to the LDAP, the same user needs to be added to every database they need to access. This requires a lot more work, but allows you to control things like tablesapces, quota, etc… and provides a little better visibility based on what view you see their session in.

From a EUS standpoint, this can be done on a per user basis. From an overall identity configuration, it is recommended to have policies around this and follow them strictly.

8 Paper # 281

Oracle Role

PasswordhistoryPasswordhistory

Account lockingAccount locking



Password verificationPassword verification

Oracle Database

uid = Gary G

group = dba_coe

ge.com

Oracle User

Oracle Internet Directory (LDAP)

Features

DBA

GLOBAL_IDENT_SCHEMA

Mapped in Enterprise User Security

members = Gary G

Database

User Password

Logi

n

Effective user / group

Figure 2 – Benefits of EUS (centralized security)


WHAT DO YOU NEED TO IMPLEMENT EUS? As you may have figured out by now EUS is not a one-click install. To use EUS you will need to have many things setup and in order. This includes technical items, and business processes.

TECHNICAL COMPONENTS TO MAKE EUS WORK

The basic technical requirements are: Supported external directory (OID, OVD) Database has been configured and has a working account in the directory Database instance has a valid wallet, and it is set to open automatically Global users and roles have been configured in the database Global users and roles have been mapped to directory objects Proper rights are available to global user and role in the database Directory based user is in the proper directory group or groupsLDAP connectivity for the Oracle products is done through the networking configuration. You can adjust this manually by editing your ldap.ora file or you can use the Net Configuration Assistant (netca) to do this. Be aware that there are two locations for the ldap.ora. The first is the location of the TNS_ADMIN or by default the ORACLE_HOME/network/admin directory. The second location is the LDAP_ADMIN that defaults to the ORACLE_HOME/ldap/admin directory. The netca will modify your TNS_ADMIN location by default, the LDAP_ADMIN can be left without an ldap.ora, but if you are troubleshooting, you may want to check for a second configuration file there.

DATABASE CONFIGURATION

The database has to be registered in the LDAP directory. This is done using the Database Configuration Assistant (dbca). The registration process will do two basic things. First it will create a new user in the LDAP directory in the Oracle Context for the database that will include special database properties. Second, it will assign a unique password to this user and store that password in a wallet on the database server. The entry created in the LDAP can also be used for TNS resolution purposes if your client is configured to resolve TNS through LDAP.

Once you have the database registered with the LDAP directory, you will need to have accounts and groups setup in the database that are “GLOBAL” for use with EUS. These accounts and roles are then authenticated using the external directory.

9 Paper # 281


Figure 3 – User creation through Enterprise Manager (note Global Authentication)

Figure 4 – Role creation through Enterprise Manager (note Global Authentication)

After you have the users and roles setup in the database, you will need to map them to users and roles in the directory. This is done using the Enterprise Security Manager tool, installed with the 10g client, but in 11g it is part of Database Console. To use this tool, you will need to login to the directory using a privileged account, and login to the database using an existing database privileged account (such as SYSTEM).

Once in the tool you will map database users and roles to directory users, groups and even contexts. One of the nice features is the ability to map a single database user (such as GLOBAL_IDENT_SCHEMA) to an entire section of the directory tree. This means that any user logging into the database with an account in that context will use the shared schema as mapped. This greatly reduces the amount of work needing to be done.

10 Paper # 281

Figure 5 - Enterprise Security Manager


All the data / updates you do in this tool are stored in the Oracle Context of the directory. The tool has a number of areas in it, but the areas we are concerned about are the “OracleDefaultDomain”, and the “Enterprise Roles” sections. The first section, “OracleDefaultDomain” has a tab called “Database Schema Mapping”. From this tab, you can map individual schemas in the database to individual accounts in the directory. Alternatively, if you are using shared schema, you can map a

database schema to every user in a given sub-tree of the directory. These mappings are in effect for all databases in this Oracle Domain (think Oracle Context in the directory).

PROCESS CHANGES

Now you have tackled all the technical challenges to integrate the directory into your database environment; what more would you need? Well to start with there is the realization that your database security is now entrusted to anyone with the proper security in the directory. Anyone with the proper rights can add or remove users from groups in the directory. So understanding who has rights, and why is critical.

However, there is hope. The best way to check for abuse to usage is to setup proper audit settings in your database, and then to review the logs on a regular basis. This is a best practice if you are centralizing your security or not. This is also the only reliable way to tell if an account was used to gain improper access. Again, this is yet another topic not directly related to this paper. But I would recommend looking into best practices for audit logs, including settings, security, centralizing, and reviewing them.

OK, so now you have complete agreement and cooperative harmony from all the organizational and technical groups. You have an extensive set of auditing configured, collected, secured, reviewed and archived. What more could you need? Well the final step is to setup a periodic review of accounts and group membership in the directory; as well as reviews of the roles, and rights granted at the database level. Although audit logs will show the evidence after the fact, only by reviewing what is setup can you help prevent improper use. This also is a critical step to help make sure that accounts that should have been locked or removed are, and that organizational or role changes in the business are accurately reflected in the directory. Lastly, it is a good time to review your policies on segregation of duties to make sure any conflicts of interest can be avoided, such as allowing or requiring your

11 Paper # 281


highly privileged users (DBAs) to have full read/write access to the OS, database, and OID audit files.

HOW DOES IT WORK? / TROUBLESHOOTING EUSFor most issues you will receive a generic error message:ORA-28030: Server encountered problems accessing LDAP directory serviceThough this is not much help, giving more detail could provide information that you would not want public. To truly troubleshoot these issues you will need to have access to the server and databases using another account. Either a different named DBA that is working, or one of the built in accounts.

These types of errors will not show up in the alert log, since they are a session error not a database error. Therefore, the only real option is to start troubleshooting steps for the issue.

Note that for all these instructions you should use the server settings that are listed in your ldap.ora. When every OID host is listed, an OVD host could be substituted.

1. Verify that OID or OVD up, available and that your database server can communicate to it.Set your environment for your database home (oraenv, or your

preferred method). Then execute the following two commands to verify LDAP connectivity:You should receive the following message for both commands: bind successfulNote: that I prefixed the commands with the ORACLE_HOME information to make sure that we get the Oracle version of these utilities. On many platforms you will find multiple versions of these same commands included with the OS and those versions have different syntax and features than the Oracle versions.

2. Next it would be good to test if the database has access to the LDAP, this will test that the database is registered with the directory and that the wallet for the database is correct and able to be used to login to the directory. For this you will need to know where the wallet is

located for your database instance. The default location is one of:or as specified in your SQLNET.ORA fileYou should find two files in this location, the wallet (ewallet.p12) and

12 Paper # 281

$ORACLE_HOME/bin/mkstore -wrl <wallet_location> -viewEntry ORACLE.SECURITY.DN -viewEntry ORACLE.SECURITY.PASSWORD

$ORACLE_HOME/bin/ldapbind -h <oid host> -p 389 $ORACLE_HOME/bin/ldapbind -h <oid host> -p 636 -U 1

$ORACLE_BASE/admin/<db_unique_name>/wallet$ORACLE_HOME/admin/<db_unique_name>/wallet/etc/oracle/walletsC:\Documents and Settings\<username>\ORACLE\WALLETS


the auto open file (cwallet.sso). You can verify the data in the wallet using the following:Note: you will need to know the password used to create the wallet to view this information

3. You can now verify that the database can login to the directory with the following command:

Where <DN> is the ORACLE.SECURITY.DN returned from step 2 and <PW> is the ORACLE.SECURITY.PASSWORD returned from step 2. Be sure to enclose these two parameters in double quotes.

If it is working you should receive the message “bind successful”.

Note: to verify you are not hitting any specific bugs you may want to try the following variations of the command:

4. Verify that the database has the LDAP_DIRECTORY_ACCESS parameter set correctly. For basic EUS it should be set to PASSWORD, all other settings are part of the Advanced Security Options.

5. Verify that the proper mappings have been created between the database user and role to the directory user and group. This is done in the Enterprise Security Manager. You should also verify that the REALM (Oracle Context) is set to the proper “Directory Authentication”, again for basic EUS this should be PASSWORD.

6. Verify that the user in question exists in the directory. You can do this with your favorite LDAP browser, or Oracle Directory Manager. Also, verify that the account is a member of the groups that you expect in the directory. Also, using the account that is failing you should log into the directory and verify that there is no issue with the account logging into the directory directly.

7. Finally, if you are still having problems, you can trace the connection request from the database in question. On the database you are trying to login with EUS, login with a different account with SYSDBA rights:

alter system set events '28033 trace name context forever, level 9';

Then attempt to login from a different session using the EUS user. After that turn the tracing back off:

13 Paper # 281

$ORACLE_HOME/bin/ldapbind -h <oid host> -p 636 -D <DN> -w -<PW> -U 1

$ORACLE_HOME/bin/ldapbind -h <oid host> -p 636 -D <DN> -w <PW> -U 1 -O auth -Y DIGEST-MD5

$ORACLE_HOME/bin/ldapbind -h <oid host> -p 389 -D -<DN> -w <PW>


alter system set events '28033 trace name context off';

You can then view the trace file in the USER_DUMP_DEST.

Table 2 - Example Trace Messages

Message Things to look for

Failed to bind to LDAP server. Err=#####

What is the error, is OID / OVD up? Password valid for database, etc…

failed to get cred from wallet Wallet file was not found by database instance

kzld_search -s sub –b <DN> Verify the DN search path, are we looking in the right location of the directory.

kzld found userschema <SCHEMA> Is the mapped schema correct?

search filter: (&(objectclass=orcldbenterpriserole)

Did it find directory groups that are mapped through EUS to the given user.

TROUBLESHOOTING SOLUTIONS QUICK LIST

Table 3 - Troubleshooting Quick List

Problem Location of Tool Tool to use To Do / Check

Directory not responding

OID or OVD Server

opmnctl Startup or restart the directory server / gateway

DB cannot bind to directory

Database Server dbca, owm, mkstore

Recreate wallet / password for database

DB not looking in right location of directory

Database Server netca, netmgr, notepad, vi

Verify context and server settings in ldap.ora file

User not mapped to directory

Database Server, Desktop

dbconsle, SQL*plus, EM

Verify Global users / roles

User not mapped to directory


Enterprise Security manger, dbconsole 11g

Verify EUS mapping, or create mappings

User can not login, or perform desired action


DBconsle, sqlplus, EM

Verify user rights (create session)

14 Paper # 281


User can not login, or perform desired action

Desktop Oracle Directory Manager, LDAP browser of choice

Verify user directory (LDAP)

Notes: EM = Enterprise Manager Grid Control or legacy two tier Enterprise Manager

dbca = Database Configuration Assistantowm = Oracle Wallet Managerdbconsole = Database Control netca = Net Configuration Assistantnetmgr = Net Manager

WHAT’S IN THE LOGS / AUDITS? As mentioned, the ability for granular audit is one of the main reasons to implement named user accounts in a centralized directory. If you don’t ever take the time to see what specific users are doing, this benefit is lost. The ability to lock accounts and secure passwords is beneficial, but named accounts will never represent all privileged database accounts.

Reviewing audit logs also provides visibility to the usage of shared accounts that will not go away. Usage patterns can help identify abnormal activity, operations performed outside of normal hours, hacking attempts, etc…. These can only be achieved if audit history is used to define a normal usage pattern.

To start with, you will need to enable some level of auditing for databases prior to 11g. In 11g Oracle has enabled a lot of auditing by default. For EUS users the following columns in the AUD$ table are of general interest:

USERID – the database schema that is mapped to the EUS user USERHOST – the hostname of the system initiating the connection COMMENT$TEXT – the actual EUS details on the connection for a

create session audit

Of these fields the COMMENT$TEXT is probably the most useful when using EUS. If you have implemented shared schema security, then the USERID field will show the same name for multiple users, the shared schema name. If you have implemented private schema security, this field will be unique.

Date in the COMMENT$TEXT is a concatenated set of fields separated by a semicolon (;):

Authenticated by: DIRECTORY PASSWORD;Method of authentication

EXTERNAL NAME: uid=GaryG,cn=Users, dc=ge,dc=com; Name of user from directory

15 Paper # 281


Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.0.68.7)(PORT=2224))Address / protocol used to connect to database

This data will need to be parsed and summarized for good audit trail usage.

WHAT DOES EUS NOT DO? Although EUS brings large-scale database security to a higher standard, it won’t do everything. From a holistic standpoint EUS is just one of the tools you will need for a fully secured database environment. As described earlier, EUS is really an extension of users in the DBA_USERS view. Let's review some other ways to get into the database.

SYSDBAOver the years, there has been some confusion over the difference between the SYS and SYSTEM users in the database. Since version 9 Oracle has attempted to make this more secure and more understandable by requiring the use of SYSDBA rights with the SYS user. This should help show that the SYS user's rights come from one of the password file or, OS authentication. As of this time, there is no way to grant SYSDBA rights through EUS.

This limits the ability to update initialization parameters, and control the running status of the database. For these rights you will need to currently use other methods of authentication.

ASMSince 10g Oracle has come out with a new storage enabling technology called Automatic Storage Management (ASM). ASM software is based on the same set of code as the database although limited. One of it's largest limitations is the security architecture. It only has SYSDBA users managed through the password file, or OS authentication.

As of 11g there is a new OSASM right and OS level ASM group. Although this does allow for security that is more granular and to separate database security from storage, it does not allow any integration with EUS. So just as in the last part, we will have to look else where for a centralized security.

OS (ORACE:DBA)OK, so the last place we have is OS security. Historically everything was focused around an OS group called dba on Unix and Linux or ORA_DBA on Windows. Since Oracle 8 there are additional groups to provide less rights. Nevertheless, the results are the same; any OS account that is a member of one of these groups automatically has rights. In fact, OS authorization takes precedent over password authentication.

Although there are down sides to OS authentication, the plus is that there are robust options for the enterprise. The benefits of having a directory

16 Paper # 281


system like LDAP or AD is the ability to authenticate to multiple technologies at once. As this paper is on EUS, I won't go into much detail however; OID can be used for Unix, Linux and even Windows authentication. These configurations are just as complex as EUS, and as such require a great degree of effort to design, and implement.

OTHER SHARED ACCOUNTS

At this point the realization hits you that named user accounts are not as easy as it would first appear. There are many pitfalls, and there are things that are not covered with the existing technology. Therefore, lets mention one more thing that is not covered by EUS directly. As mentioned before schemas and users are the same thing in Oracle.

Almost every application that you will purchase from a third party vendor that requires an Oracle database will ask for at least one schema / user to be setup. The password for that user will then need to be passed to the appropriate people to configure application servers or even fat client applications on user desktops. There is almost no way around this from a technical standpoint. Currently the best answer for things like this is policies and processes that reduce the exposure of that shared password.

Unfortunately, this is true for applications and tools that come from Oracle directly. Access to things like RMAN, Enterprise Manager Grid Contorl, OID and eBusiness Suite are full of shared accounts / passwords that need to be known for day to day operational purposes. Even if that operation only has to take place weekly or a few times a year it still requires a known shared password to be made available.

REAL WORLD EXPERIENCES Therefore, what can one expect when trying to implement EUS? Lets discuss a few real world experiences and pitfalls. This is not a complete list, but at least a few things to consider.

First, there is the wallet. The wallet is used for each database, and in RAC, there has to be a unique location for each instance. For 9i, this is very difficult to manage due to limitations in how the wallet is located. For 10g this gets a little better, but with RAC you will have to make some low level architecture decisions on how to place wallets on file systems in the cluster. The Metalink notes in the references section provide detail on this. The short version is that just like TNS, ADMIN and other central parameter and configuration files on your database server, the wallet is another unique thing to manage.

Another issue with the wallet is that you have to provide a password to secure it, and you will most likely need to know that password for any type of troubleshooting. As mentioned above, there is no method to eliminate shared passwords. All we can really do is continue to reduce the number of

17 Paper # 281


people that have access to them. So even though you eliminate one shared password in the privileged account, you create another one in the wallet. In addition, you get to have one for every database; this can be to your advantage, or disadvantage depending on how you plan to manage it.

The second item will be access to the directory. Based on the technology and your company’s roles this can be difficult. At minimum, you will need access to the directory to perform the following items:

Add the OracleContext if needed. Add database entries, this will also need to be done for every new

creation or removal of a database. Manually update TNS entries for databases stored in the directory.

This will need to be done for RAC systems since the entry is not created properly by DBCA, and to account for any database moves.

To facilitate troubleshooting of anything that is not working. To use the Enterprise Security Manager tool to setup EUS mappings.

These rights can be granular in nature, but nonetheless a number of directory privileges need to be available to database administrators.

Database administrators will still need OS level access to the server hosting the database. Based on your organization you may be able to reduce the number of people by their job role. However, as noted above, to troubleshoot, setup and maintain EUS OS access is required. In addition, there are still database administration duties that require access outside of EUS such as backup, recovery, parameter changes, reorganization data, etc….

Make sure there is opportunity to do minimal or possible extensive testing of database tools used in your organization. EUS is only viable if the day-to-day tools used by developer, application support teams, and administrators support it. One area of concern is the general discrepancy between tools, the database, and the backend directory for things like password characters and user names (or ID’s). Most directories allow for very complex usernames and passwords that can contain not just alphanumeric but also special characters. Many tools and the Oracle database included have limitations on what characters can be used in user names and passwords. For example, a password with an embedded at sign (@) might be acceptable by the directory, but would not work on a SQL*Plus login.

Finally a note on Oracle’s Enterprise Manager Grid Control (OEM), one tool that is in the forefront of database administration. Out of the box OEM supports EUS from a basic standpoint, meaning that it has no issues with passing usernames / passwords through to the database and then the directory. But, for access to OEM you need a separate login account. As of the latest release (10gR5) the only way to integrate this with external security is as an Oracle SSO partner application. This means that users for OEM are still managed in OEM tables, but are authenticated by the SSO integration (to OID). Groups and access to objects in OEM are managed in

18 Paper # 281


OEM, and cannot be managed in the directory. Once you access a low level target, like a database, you are then asked to authorize to that target. At this level then, EUS can be used for database targets.

NEXT STEPS I hope that this paper has given you a good background on what EUS will provide and what it will not provide. Overall implementing a centralized security system is complex and requires various number of skill sets. In addition, there are numerous process and possibly business policy changes necessary.

This paper contains a number of topics that could not be covered in detail. If you believe Enterprise User Security is a technology that you would like to implement, I would recommend additional research and study. To start with, a good background in LDAP, and learning about OID or OVD based on your environment's needs. Second, a good understanding of your company’s policies and regulatory environment is required. Finally, start building a coalition or agreement across the different technical groups in your organization. The best way to ensure success will be to have a cohesive security framework for your database, it does no good to lock your front door, but leave your back door wide open.

REFERENCES Oracle Metalink Notes

166937.1 – “Enterprise User Security LDAP directory compatibility matrix”

438365.1 – “How To Perform Silent DB Configuration/Registration In OID Using DBCA”

405682.1 – “Configure Multiple DB Instances To Share SQLNET.ORA Without Giving WALLET_LOCATION For EUS”316360.1 – “How To Configure Enterprise User Security In An Oracle

10g RAC Environment”250675.1 – “OID Server Autodiscovery”135696.1 – “The Oracle Net - LDAP FAQ”453853.1 – “Step by Step Guide To Troubleshooting 10g Enterprise User Security (EUS) - Password Authentication”428270.1 – “EUS Connections Fail With ORA-28030 After Upgrade

OID To 10.1.4.0.1”“Oracle Identity Management – Governance, Risk, and Compliance Architecture” – third edition by Marlin B. PohlmanOracle® Database Enterprise User Security Administrator's Guide 11g Release 1 (11.1), Oracle corporation © 2000, 2007Oracle® Database Enterprise User Administrator's Guide 10g Release 2 (10.2), Oracle corporation © 2000, 2005Oracle Database Advanced Security Administrator's Guide, 10g Release 1 (10.1), Chapters 11-13, Copyright © 1996, 2003 Oracle Corporation

19 Paper # 281


Oracle Advanced Security Administrator's Guide, Release 2 (9.2), Chapters 15-19, Copyright © 1996, 2002 Oracle CorporationOracle Database Security – Enterprise User Security http://www.oracle.com/technology/deploy/security/database-security/enterprise-user-security/index.html “Manage Oracle Databases Users and Role Centrally in Active Directory or Sun Directory”, August 2008, Olaf Stullich, Oracle Corporation

20 Paper # 281

oracle database enterprise user security - a practical example

Documents

database security

eus work

benefits of eus

database configuration

backend database access

security options os

shared schema security

primary security method