Maaz Anjum's Blog

EM12c, Weblogic, and Finding Your Way Through Active Directory

Introduction

As with any adventure, there are hurdles along the way. I started my previous post with the sections below but instead I ended up composing the linked article. What I had started with was how to query the Active Directory tree where groups with multiple subgroups from a Weblogic Server for Enterprise Manager User Authentication. In the past, I had only needed to configure Active Directory users with a simple users’ group membership. I’d like to note that I am a DBA by trade and make no claims of being either a Weblogic or LDAP whiz. This article is merely my experience written in hopes that it might help someone who is going through a similar situation.

The Goal

If you are savvy with LDAP queries, then after reading this post you could probably teach me a thing or two. However, I did want to share a unique example where the customer’s Active Directory Administrator created a security group called “IT OEM Users” which contained several users as well as sub-groups. From an organization standpoint, groups are ideal because they require less overhead of a user-to-many-groups mapping.

Organization is great, but my challenge was how do I query this information from Weblogic’s Provider setup? Since Oracle’s Documentation is quite thorough on the steps both for EM12c and Weblogic, I won’t need to go through the nitty gritty set up details. What I will discuss are the filters I used to retrieve the list of users.

Knowledge

One of my customers asked me how I knew which filters to apply and how I figured it out to begin with. The honest answer was and still is, that it was by trial and error and leveraging an Active Directory query tool. A quick search on Google provides several options. I ended up ADExplorer which is part of the SysInternals Suite - its lightweight, portable and has a GUI! Alternatively, you could also use a command line tool to find your data set. I was tempted to ask my customer to review this Knowledge Based article at Microsoft but they needed the right context. Additionally, there’s a Microsoft Exchange article on it as well. Another alternative is ldifede which is a command line utility for querying LDAP.

The Tools

To really grasp all the nonsense I’m about to explain below, I recommend that you know/have at the very least the things below

• Knowledge of LDAP: A clear understanding of the attributes, fields, filters etc that are related to this protocol. If you are interested, I have found a decent tutorial here.
• LDAP Query Tool: Key if you’re to test your LDAP filters before applying them.

Get Your Gear and Tools Ready

Before you can even begin this adventure, three things are required.

• LDAP Server Name
• LDAP Servers Port
• LDAP Principal Credentials

You would now need to find out which users should have access to EM12c. My preferred way to do this in Active Directory is by requesting the AD Admin to create a new Security Group and add these users to it. If, for some reason they wouldn’t, then the other option is to add filters for each specific group. I would advise to stay away from query individual users.

Next what you need are the

• User Base DN
• Group Base DN

DN means Distinguished Name which is an LDAP attribute. If you are interested in all (if not most) attributes in LDAP, check out this link. The Base DN simply denotes where in the Active Directory tree the search for Users and Groups will initiate. It equates to the FROM clause in SQL query. Come to think of it, you could just query the Base DN and call it a day — but that’s just as bad as SELECTing all rows from a table when you only need a handful. The adverse affect will be longer console login, and em12c restart times. Naughty naughty.

Apart from the Base DN fields, I usually edit the “All Users Filter” and “User From Name Filter”. “All Users Filter” is what you would equate to the WHERE clause. It will contain the actual filters that limits the resulting data set. According to Seth Miller (@Seth_M_Miller), you could pretty much query anything if you have the right filters enabled and I agree with him.  

“User from Name Filter” actually maps the credential set that are used for authentication to an LDAP attribute. For example, if my company uses the first initial of the first name and the last name (or part of it) format, then my username in AD that I would use for logging into a windows machine might be “manjum”. So, on an EM12c or Weblogic console I would enter the same username. In LDAP, this maps to the sAMAccountName attribute.

Understand the Required Data

Ok, so now that we have the information we need to connect, and query the Active Directory tree, lets get an understanding on the data that will be actually retrieved. For the providers, you need two sets of data which must intersect; Users and Groups. You could get quite dynamic with the filter for either and pretty much get any data set. As I mentioned earlier, the filters are akin to an SQL query wherein WHERE clauses have AND or OR operators. 

Default Provider Configuration in Weblogic

The provider configuration page in Weblogic is mostly empty except for a few default values which are pre-populated.

An Example

The steps outlined below only illustrate how to find the correct group memberships for a given user. I have had to blur out and domain specific information and replace it with my own examples.

Users

Let’s assume that I have the following User Base DN, OU=Users,DC=corp,DC=krypton,DC=planet,DC=com even though I have most of the DC and OU sections blurred.

Now that we have the basic required information, let’s start with a simple query. I want to find my user within AD. I start with a search within the User Base DN, it's a right click then “Search Container”.

The GUI is easy if you know what you are looking for, in my case I need use the sAMAccountName which is “manjum”. It actually builds the search string for me highlight in blue:

Once I find my user, I can look at its properties (I’m copying the image from earlier :)). I then look at the “memberOf” attribute, and can use it to search for all users within a Security Group.

I simply double click on the “memberOf” attribute to show all groups for the user.

I can then use the value in the groups to perform another search. This time I will use the “memberOf” attribute. I selected the attribute from the “Attribute” drop-down list, pasted the CN=Home_Standard,CN=Users,DC=corp,DC=krypton,DC=planet,DC=com string in the “value” section and hit “Add”, and then “Search”.

Presto, I found my users! If you should see this pop up below, then go ahead and click “Cancel” — you really shouldn’t need to retrieve more than a 1000 users anyway :)

So, my “All Users Filter” after a slight group name change, my filter looks like (&(sAMAccountName=%u)(objectClass=user)(memberOf=CN=IT OEM Users,CN=Users,DC=corp,DC=krypton,DC=planet,DC=com)).

Back to Weblogic Provider Configuration

Plug the above string in the provider configuration “User From Name Filter”. If you noticed, I also updated the “User From Name Filter” with (&(sAMAccountName=%u)(objectClass=user)) and “User Name Attribute” with “sAMAccountName”. The latter is because I want the authentication to happen with the sAMAccountName (recall the username manjum from earlier?) attribute.

Groups

I search for groups in a similar way, you will likely have the same Group Base DN as the User Base DN, or it might just be OU=Groups,DC=corp,DC=krypton,DC=planet,DC=com.

I don’t know the odds, but you will have far less groups than users. I chose to retrieve all groups within an OU to ensure my membership criteria intersects with the Users. You can apply the same filters, i.e. memberOf, member, etc to a group as well.

The string itself is (&(sAMAccountName=*)(objectclass=group)).

When the configuration for the providers is complete, the information is saved in the $DOMAIN_HOME/config/config.xml file. You could configure the AD Providers within the configuration file but according to Oracle Support, that should be your last resort.

<sec:authentication-provider xsi:type="wls:active-directory-authenticatorType">
<sec:name>ADAuthenticator</sec:name>
<sec:control-flag>SUFFICIENT</sec:control-flag>
<wls:propagate-cause-for-login-exception>true</wls:propagate-cause-for-login-exception>
<wls:host>corp.krypton.planet.com</wls:host>
<wls:port>389</wls:port>
<wls:user-name-attribute>sAMAccountName</wls:user-name-attribute>
<wls:principal>orasvc@corp.krypton.planet.com</wls:principal>
<wls:user-base-dn>OU=IT,DC=corp,DC=krypton,DC=planet,DC=com</wls:user-base-dn>
<wls:credential-encrypted>abcdefghijklmnopqrstuvwxyz</wls:credential-encrypted>
<wls:user-from-name-filter>(&(sAMAccountName=%u)(objectClass=user))</wls:user-from-name-filter>
<wls:all-users-filter>(&(sAMAccountName=%u)(objectClass=user)(memberOf=CN=IT OEM Users,CN=Users,DC=corp,DC=krypton,DC=planet,DC=com))</wls:all-users-filter>
<wls:group-base-dn>OU=IT,DC=corp,DC=krypton,DC=planet,DC=com</wls:group-base-dn>
<wls:group-from-name-filter>(&amp;(sAMAccountName=*)(objectclass=group))</wls:group-from-name-filter>
<wls:all-groups-filter>(&amp;(sAMAccountName=*)(objectclass=group))</wls:all-groups-filter>
<wls:static-group-name-attribute>sAMAccountName</wls:static-group-name-attribute>
<wls:dynamic-group-name-attribute>sAMAccountName</wls:dynamic-group-name-attribute>
</sec:authentication-provider> 

Back to “The Goal”

If you’re still with me, and recall that I stated a goal up at the top, it was that I want all users within a Security Group, even those within a Sub-Group.

The “User From Name Filter” or “All Users Filter” as I described above will not retrieve the Sub-Groups users. To retrieve them, I had to tweak both filters values to the following:

From

“User From Name Filter”=(&(sAMAccountName=%u)(objectClass=user))

“All Users Filter”=(&(sAMAccountName=%u)(objectClass=user)(memberOf=CN=IT OEM Users,CN=Users,DC=corp,DC=krypton,DC=planet,DC=com))

To

“User From Name Filter”=(&(sAMAccountName=%u)(objectCategory=*)(memberOf:1.2.840.113556.1.4.1941:=CN=IT OEM Users,CN=Users,DC=corp,DC=krypton,DC=planet,DC=com))

“All Users Filter”=(&(sAMAccountName=*)(objectClass=*))

The Matching Rule OID “1.2.840.113556.1.4.1941” recursively retrieves the data from within a section of the LDAP tree. In this case, it will traverse the tree and query the subgroups as well until it finds all objects.

Summary 

I walked through the LDAP tree, the tools I used to find the information (users and groups) I needed to build my search string for LDAP, explained the bits and pieces (LDAP server, port, principal account, user base dn, group base dn) you require for as a base for your provider, and as an added bonus explain how to executed a recursive LDAP query.

I hope this has proven to be a helpful post. Please feel free to send me a tweet (@maaz_anjum) or email with any questions. 

Cheers.