Cloud Control authorization with Active Directory

About 2 months ago I wrote an article about setting up user authentication in Cloud control, based on their account in the Active Directory. As promised, here is the second part describing Cloud Control authorization with Active Directory.

A small recap about why this could be useful:

If your company is preferring Microsoft Active Directory (further named AD) as a source of truth (or at least you´re trying to) you should be using the AD as source for the user accounts in Cloud Control. The advantages are obvious: Control the validity of accounts in one single place, no different login’s and passwords for the user etc.

Keep in mind that access control is made up of 2 parts:

• Authentication
  Validate if the person trying to login is who he claims to be (i.e. by password check, see previous post)
• Authorization
  Give access to whatever the authenticated user is allowed to (i.e. by roles)

In this article I will give a step-by-step to setup the authorization part, thus allowing the user to do what he/she has to do.

As a starting point for this I will take the endpoint situation of my previous post, which is: All users in the Active Directory can login in your Cloud Control, but have no rights automatically granted. This still is a manual job.

First point to attack is the fact that all user will be able to login into Cloud Control. Although they will not be able to break anything, it isn’t a very desirable situation.

Speak to your AD-administrator again and ask him/her to create a security group. Only members of this group will be able to login into Cloud Control. In this example we will use “AMIS_OEM_Login”. When the security group is created you’ll need the following:

• Exact name of the security group (i.e. AMIS_OEM_login)
• Group Base DN (i.e. OU=CloudControl,OU=Global,OU=Security Groups,OU=xxxxxxx,DC=xxxxxxx,DC=local)
• At least 1 testaccount which should be member of this group to be able to test

The steps to perform:

1. Perform a backup of your current setup to be able to go back to a stable situation if something fails
2. Login into the WebLogic console as administrator (weblogic)
3. Click the <Lock & Edit> button on the left to be able to make changes
4. In the “Domain Structure” click on “Security Realms”, click on “myrealm” and select the tab “Providers”
5. Click on “EM_AD_Provider”
6. Select the tab “Provider Specific”
7. Scroll down to the section “Groups”
8. Put the Group Base DN received from your AD-administrator in the field “Group Base DN:”
9. Keep “All Groups Filter:” empty
10. Scroll down and click save
11. Click on the <Activate Changes> button on the left of the screen. You should receive a message that the changes have been activated, but a restart is required to take effect
12. Restart your Cloud Control environment

13. Log into the host as user oracle and navigate to the ./em/oms/bin directory
14. Execute the following statement to achieve that only useraccounts who are member of this group will be auto-provided to OEM when a user logs in the first time.

./emctl set property -name "oracle.sysman.core.security.auth.autoprovisioning_minimum_role" -value "AMIS_OEM_Login"

Now you should be able to use your test account (which is member of the specified group) to login into Cloud Control. A valid AD account which is not member of the designated group will nog be able to login. Remember, no rights and permissions will be assigned to newly created account.. This should still be done manually by an administrator, or… keep reading…

When the setup above is working, we can bring it to a higher level by also putting the rights and permissions into AD-groups, bringing most of Cloud Control security into a single place (Active Directory).

Let’s state we want to differentiate access rights between 2 groups

• Read only users
• Administrators

First, go back to your AD-administrator and ask him for 2 more security groups. I will use AMIS_OEM_RO and AMIS_OEM_Admin for this example. Naming could be anything, as long you (and your admins) understand it. Please ensure these groups are created in the same DN as the previous (AMIS_OEM_Login) group. Also make sure you have 2 test accounts, each member of 1 of these groups

The steps to perform:

1. Log in into Cloud Control as user sysman
2. Navigate to <Setup>, <Security>, <Roles>
3. Click on <Create>
4. The group name should be exactly the same as the security group in your AD. Add a proper description and make sure the box “External Role” is ticked.
5. Click <Next>
6. On the next screens you can grant any right and permission you want to this role.
7. Do not grant the role to any administrator.
8. On the last screen review the settings and click <Finish>
9. Perform step 3-7 again for the second role.

Next step is to provide WebLogic with the appropriate security group filter so the security groups can be found.

10. Login into the WebLogic console as administrator (weblogic)
11. Click the <Lock & Edit> button on the left to be able to make changes
12. In the “Domain Structure” click on “Security Realms”, click on “myrealm” and select the tab “Providers”
13. Click on “EM_AD_Provider”
14. Select the tab “Provider Specific”
15. Scroll down to the section “Groups”
16. In the field “All Groups Filter” enter the filter expression which gives the appropriate groups as created in your Active directory. I use (cn=AMIS_OEM*). Note the asterisk at the end so it will give all AMIS_OEM_xxxxx groups.
17. Scroll down and click save
18. Click on the <Activate Changes> button on the left of the screen. You should receive a message that the changes have been activated, but a restart is required to take effect
19. Restart you Cloud control environment

In most companies the actual login is not equal to the display name of a user (i.e. jgouma vs. Jeroen Gouma). If this is the case we need to activate an extra setting in Cloud Control to proper deal with this situation.

20. Log into the host as user oracle and navigate to the ./em/oms/bin directory
21. Execute the following statement to enable username mapping:

./emctl set property -name "oracle.sysman.core.security.auth.enable_username_mapping" -value "true"

Another advantage of using the AD-data is that no data entry on user specific attributes has to be performed. Information regarding phone-number, email address etc. can be retrieved from the AD when the account is created (= first login). This can be achieved by mapping AD-fields to specific attributes of the user account. It is possible to use a single field, a concatenation of fields or combine with literal strings.

The following attributes can be used:

• USERNAME
• EMAIL
• CONTACT
• LOCATION
• DEPARTMENT
• COSTCENTER
• LINEOFBUSINESS
• DESCRIPTION

The steps to perform:

1. Log into the host as user oracle and navigate to the ./em/oms/bin directory
2. Execute the following statement to enable the ldap userattributes mapping:

Note: all needs to be on line 1, I only splitted the lines for readability…

./emctl set property 
 -name "oracle.sysman.core.security.auth.ldapuserattributes_emuserattributes_mappings" 
 -value "USERNAME={%displayname%},EMAIL={%mail%}"

This example puts the displayname from the active directory into the field username, and the email address will be filled with the mail address from the same source.

Some more examples:
To use a literal string in combination with AD-fields. The result of this would be “Jeroen Gouma AMIS consultant” as username.

./emctl set property 
 -name "oracle.sysman.core.security.auth.ldapuserattributes_emuserattributes_mappings" 
 -value “USERNAME={%firstname% %lastname% AMIS consultant}”

When you need to use a comma (which is field separator) it needs to be escaped with a \. The example below would result in having the text “Gouma, Jeroen , +31306016000” in the description attribute.

./emctl set property 
 -name "oracle.sysman.core.security.auth.ldapuserattributes_emuserattributes_mappings" 
 -value “DESCRIPTION={%lastname%\, %firstname% \, %phone%}”

Combining a few examples together could lead to the following statement:

./emctl set property 
 -name "oracle.sysman.core.security.auth.ldapuserattributes_emuserattributes_mappings" 
 -value “DESCRIPTION={%lastname%\, %firstname% \, %phone%}”,"USERNAME={%uid%},EMAIL={%mail%},
 CONTACT={%telephone%},DEPARTMENT={%department%},DESCRIPTION={%description%},LOCATION={%postalcode%}"

When all done, it’s time to verify the setup. Login into the Cloud Control console using your test accounts.

When login was successful, logout and login again using the sysman account. Navigate to <Setup>, <Security>,<Administrators>. You will see the new account has been created. Also notice the authentication type has been set to SSO (Single Sign On) indicating this is an external account.

Select the new account and click the <View> button. Verify that the properties have been filled as expected, i.e. email address, location. If fields are not filled properly, check the ldap userattributes mapping executed earlier. You can re-execute this statement at will. Setting will be effective immediately on all accounts created afterwards.

In the <Roles> section you should see the (applicable) Active Directory groups the user is a member of.

Sources:

1. Enterprise Manager Cloud Control Documentation
2. Cloud Control Security guide