Managing OEM13c Roles and AD Groups. In my last post, we explored how to enable LDAP (using Windows Active Directory) authentication within OEM 13c. Now that we can centrally manage basic user access to OEM, we need to apply some security constraints around these users.

 

If you are familiar with Active Directory (AD), then Organizational Units (OU) and Groups will be also be familiar terms. In essence, these are the containers that Windows Server uses to organize users and establish permissions and access to enterprise resources and applications.

Within our OEM environment, a component of this control structure is managed using Roles. OEM has a number of built in roles that allow an administrator to grant certain privileges to users allowing them to perform functions within OEM. These roles however are designed to work with native OEM user accounts and roles. Once we implement user management via AD LDAP, there are some additional considerations. Let’s take a look at how we set this up.

If you want to follow along please take a look at my previous post on Managing OEM uses via AD to get and idea of configuration I’ll be working from.

Jumping right in, I have created two additional accounts (Daniel & Danny) in the DOT Users OU.

Since we turned on Auto-provisioning in OEM, we can log in with the credential used from AD. A quick check from Weblogic shows that the user accounts are recognized:

and we can see that the accounts have been created in OEM. *Note: I previously logged in with the accounts to allow the auto-provisioning to create the OEM accounts:

Now that we are confident the user accounts are there, we can implement some initial access controls to these users. At first login, neither account has access to any information from OEM:

   

Our first step is to create or add users to the Windows AD Groups located in the OU we defined as Group Base DN. In this case, “OU=Security,OU=Groups,DC=beta,dc=dbaontap,DC=com” means we need these groups here in AD:

As you can see I have created the AD Group “OEM_HOST_VIEW” and have added the user DANNY to this group:

In order for this to work, we must also create a ROLE in OEM. The name of the AD Group(s) and OEM Role(s) must match exactly.

Once we have create this OEM Role and assigned some privileges we can log into OEM with the Danny user account and lets see what we get.

As you can see, this account can view all hosts, in this case both the Windows 10 box and the Linux Server. Shameless plug, but if you want to figure out how to monitor your Windows boxes in OEM, check back a little later. This is due to the Role’s inherited privileges.

What if you don’t want generic Role inheritance? OEM has a way to handle this as well. In the next example, we will create a new Windows AD Group, add the Daniel user to it and build a different access model in OEM.

In this case, we will not select predefined Role privileges to inherit.

Let’s explicitly define View privileges on a specific Target. In this case the Windows 10 box (Delta)

A quick review of what we have configured now shows two External Roles.

and when we log in with the Daniel user credentials, we only see the Host explicitly configured from above.

This is a simple example of how you can integrate OEM13c with Windows AD and implement some access controls around your users. While the initial set up takes some time, once your Groups and Roles are created and synchronized as it relates to your organization’s control and access structure, the management is generally centralized to your Windows AD environment.

As with anything, your security policies can become quite complex. Take your time to architect it appropriately to prevent massive amounts of redo.

Enjoy,