Simplified Enterprise User Security

How EUS Can Help Simplify And Secure Your User Management Processes 

Enterprise User Security (EUS) has been around for over a decade, but has recently begun to see an uptake in interest. This is in part due to growing security concerns around managing and protecting Enterprise User accounts. As organizations grow in personnel and infrastructure, it becomes increasingly difficult to organize and govern enterprise user accounts. This is where EUS comes in. EUS is a one stop shop for administering user identity, credentials and password policies. It has the ability to enable separation of duties, manage privileges across multiple databases (DBs, and by leveraging LDAP structure, it can be used to utilize group membership - an extremely powerful for enterprise organizations.

So how does EUS work?

The following two diagrams briefly explain the difference between provisioning users in an environment with EUS versus an environment without EUS. 

Before EUS:

In this first diagram, let us imagine that there is a LDAP Directory in use and that it is Active Directory (AD) as seen on the right side. This company has a large employee base and uses AD to manage their Microsoft window accounts. You will notice that there is no connection between the Database and Directory environments. In many cases, companies will have a need to create a user account for certain employees in both locations. Prior to EUS being implemented, a Database Administrator (DBA) would have to create a separate account for that user in every single database they need access to and grant each account the required privileges. In addition to the DB accounts, an Identity admin would have to create a account for that user in AD.

After EUS:

In this case, provisioning a user in AD and granting him access to the appropriate databases becomes much simpler. After configuring EUS, all an Identity Admin would have to do is create that user in AD, then add him to the appropriate groups within AD. 

EUS works by utilizing an additional LDAP directory schema to manage mappings between AD User, Groups, Database Users and Roles. This schema is called the “Oracle Context” and is managed by a Oracle Directory. In the example above we are showing the Oracle Directory to be Oracle Unified Directory (OUD), but it can be any of the Directories included in the Directory Suite Plus collection. The diagram below will provide a better understanding of how these mappings work. 

In this diagram you will see two sides, Grantees and DB Global Roles. The HR_DEVELOPER Enterprise Role is mapping these two sides together, created in the EUS console on Enterprise Manager and stored in the Oracle Context on OUD. This Role has the capability of Mapping existing users and groups in AD to DB Global Roles on Oracle Databases. In addition, the AD Group HR_DEV and the user Judy Dinch are mapped to four different databases and their corresponding global roles. If a user is added to the HR_DEV Group in AD, then they will automatically be granted access to the four DB Global Roles listed under DB Global Roles. 

Not only does this make provisioning a breeze, but it also simplifies all other account management processes. In our experience, many clients have both strict deprovisioning and password policy rules. If an employee leaves a company, all that needs to happen with EUS is that the user account get disabled in AD. That one act will disable the user’s access across all databases which they had access to. Same thing goes for password changes. In addition to the user only having to remember one password now, users will only need to change their password in one location for that change to be reflected across the board. It is a solution that adds security through simplicity, a combination that could greatly benefit all enterprise organizations. 

In addition to simplifying and securing enterprise user account management, organizations can see huge productivity gains for DBAs. With EUS, clients are able to delegate tasks such as provisioning user accounts and granting user access to less skilled individuals instead of the DBA team. Day to day DBA tasks such as access issues, password resets and job changes can be delegated to an EUS Administrator. In addition to account management, the LDAP directory schema used to manage EUS has the capability of enabling database names services in the directory. This will make it possible to eliminate the DBA’s job of managing TNSNAMES files across all clients and servers. 

Since this is the case, teams will find that DBA’s will now have some time freed up to work on higher-value database activities such as design, implementation and performance tuning. You may be thinking that there is will be an extensive ramp-up process for someone to learn how to execute the processes that DBA’s had to handle in the past but that is not the case. Because EUS utilizes Enterprise Manager console as its administrative interface, an Administrator will be able to easily manage all tasks from a single familiar interface. 

By consolidating enterprise user management to a single source of truth, EUS has the capability to greatly simplify and secure current processes as well as provide major productivity gains. Many clients benefit from using EUS in their custom environments.

If you have any questions about how EUS could help your organization, please feel free to contact us.

Avoid Disaster with a Multi-Data Center System

Is Your Company Prepared For A Data Disaster? 

Disaster Recovery (DR) is a term that all heavily computer-dependent companies should be familiar with. It involves policies and procedures put in place to recover vital technology systems from natural or human-induced disasters. 

In the event a company’s system goes down, a Disaster Recovery plan should be in place to ensure productivity isn’t heavily impacted. Such recovery strategies can include clustering, using load balancers and utilizing Multi-Data Center (MDC) Architecture. 

Imagine a system with:

• only one data center containing many application servers in a cluster

• multiple database instances in a Real Application Cluster (RAC)

• many web servers behind a load balancer

If the entire database goes down, that single point of failure will render all of those components useless. This is where DR planning pays off. Having well-implemented MDC Architecture ensures a company will have a DR plan for this instance, and productivity will not go down with the database. 

The MDC approach can be used to distribute load between multiple data centers, as well as prevent an outage if an entire data center goes down. A data center acts as a single system with its own policies, data stores, applications, clusters and load balancers. There are three MDC topologies that can be utilized: Active-Active, Active Standby-Passive and Active-Hot Standby. 

In the Active-Active topology, each data center would be in a different location while a global load balancer in front of the MDC system would send users to one data center. The global load balancer can determine which data center to send users to by using either geolocation or the application they are trying to access. The data centers can be configured to allow data to be transferred among them. Applications can make use of data centers with this configuration because data will be the same. If a data center goes down or traffic spikes, a user can be seamlessly transferred to the next available data center by the global load balancer. 

In the Active Standby-Passive topology, one of the data centers remains passive or shutdown while the primary data center is up and active. If there is a problem with the primary data center, the passive data center will be brought up to replace it until the problem is resolved. 

The Active-Hot Standby topology is similar, with the difference being that all data centers remain up; however, only the primary data center will be used until it fails. While the primary data center is catering to users, the standby data centers will still be reading data from the primary to properly fill in should it become unavailable. 

To keep data centers identical, manual replication would have to be performed, which can be a time-consuming task. It can consist of manually exporting policies from one data center and manually importing them to another. Oracle Access Manager (OAM) has a feature for MDC called Automated Policy Synchronization (APS) that makes maintaining those data centers less intimidating. In an OAM MDC system, a single data center will be configured as the “master,” while others will be configured as “clones.” APS is an automated replication mechanism that pulls changes from the master and replicates them to each of the clones. For a clone to be involved in APS, a replication agreement must be created between it and the master. This functionality was added in OAM 11.1.2.2 and reduces the time needed to update all of the clone data centers by removing the need for administrators to update them manually.                 

For large enterprises that rely on their OAM systems in order to complete their work, the MDC approach will be the way to go when thinking about disaster recovery. With it, there will always be a backup data center available should one of them go down. 
            

---

PROFESSIONAL SERVICES - SENIOR SYSTEMS ENGINEER