Index of IDM Directory Services articles

Identity Management

As members of the IDM and Security A-Team, we get exposed to a wide range of challenging technical issues around security and Oracle Fusion Middleware. We’re using this site to answer common questions and provide interesting solutions to the real-world scenarios that our customers encounter every day. Products and Technologies Access Management > Discussions on […]

Fast Group Membership Lookups in OID with the orclMemberOf Attribute

If you utilize nested and dynamic groups (and especially nested dynamic groups), then it can take a lot of effort and time to calculate all of a user’s group memberships in an LDAP directory.

First you have to search for the user and find the user’s DN. Then you have to search all your groups to figure out which groups your user is directly a member of. Then for each of those groups you have to search all your groups again to see which of those groups your user is a member of.

You have continue to search your groups with the results of each subsequent search until you reach the maximum desired level of nested memberships that you want to pursue or all the searches come back empty. All the while you have to keep yourself out of infinite loops created by repeating memberships such as when two groups are members of each other.

Many LDAP directories simplify things through a virtual “member of” attribute which is a virtual multi valued attribute containing all of the groups a user is a member of through both direct and indirect means.

It may have escaped your notice, but OID joined the party fairly recently (in 11.1.1.4 I believe) and now supports such an attribute. The attribute’s name is orclMemberOf. You can read all about the attribute here; but suffice it to say it is a dynamic multi valued attribute containing the groups to which a member belongs.

The membership includes both direct membership and indirect membership from nested groups. It also includes membership from dynamic groups and dynamic nested groups based on labeleduri.

The attribute value is computed during a search and is not stored. This means you will not see orclMemberOf populated in an LDAP data browser including ODSM. Further, the value is not returned by default in searches. You have to explicitly request it. Lastly, orclMemberOf cannot be used in a search filter.

One nice little additional feature thrown in is that the aliases of memberof and ismemberof are supported for compatibility with code written for compatibility with Active Directory and Oracle Directory Server Enterprise Edition (DSEE) / SunOne / IPlanet.

Below is a sample search with results for a specific user where I request and receive the value(s) of orclMemberOf.  You will also notice that nested memberships are returned multiple times, once for each group that the user belongs to that is a member of another given group.  So, watch out for that.

In a future post, I’ll discuss how you can use the orclMemberOf attribute to greatly speed up authentication into WebLogic and Fusion Middleware Products such as SOA Suite and WebCenter which utilize WebLogic’s security framework.

[oracle@oam1 bin]$ ./ldapsearch -h oam1.example.com -p 3060 -D cn=orcladmin -w Oracle1_g -b “cn=Users,dc=example,dc=com” -L -s sub -v “uid=tim.doyle” memberOf

ldap_open( oam1.example.com, 3060 )

filter pattern: uid=tim.doyle

returning: memberOf

filter is: (uid=tim.doyle)

dn: uid=tim.doyle,cn=users,dc=example,dc=com

memberof: cn=administrators,cn=groups,dc=example,dc=com

memberof: cn=groupofgroups,cn=groups,dc=example,dc=com

memberof: cn=nyusers,cn=groups,dc=example,dc=com

memberof: cn=groupofgroups,cn=groups,dc=example,dc=com

memberof: cn=nestgrp1,cn=groups,dc=example,dc=com

memberof: cn=groupofgroups,cn=groups,dc=example,dc=com

memberof: cn=oaamcsrmanagergroup,cn=groups,dc=example,dc=com

memberof: cn=groupofgroups,cn=groups,dc=example,dc=com

memberof: cn=oaamenvadmingroup,cn=groups,dc=example,dc=com

memberof: cn=groupofgroups,cn=groups,dc=example,dc=com

memberof: cn=oaamruleadministratorgroup,cn=groups,dc=example,dc=com

memberof: cn=groupofgroups,cn=groups,dc=example,dc=com

memberof: cn=product support group,cn=groups,dc=example,dc=com

memberof: cn=groupofgroups,cn=groups,dc=example,dc=com

1 matches

OIM 11g & LDAP Synchronization

Since the first OIM 11g release, one of the frequently asked questions about OIM 11g is:

  • Should I configure OIM with LDAP synchronization or should I deploy a LDAP connector?

Since earlier versions, OIM provides connectors for the most popular LDAP systems: Oracle Internet Directory (OID), Oracle Directory Server EE (formerly Sun Java Directory/iPlanet), Novell eDirectory and Microsoft Active Directory (AD).

With OIM 11g, a new feature called LDAP synchronization was introduced. OIM uses this feature to synchronize its users and roles base to a LDAP system. This synchronization is bidirectional and it uses scheduled jobs/reconciliation engine to pull changes from LDAP and event handlers to push data to LDAP.
But if OIM already provides a connector for most of the industry LDAP servers, why provide a feature like LDAP Synch? Different customer’s business requirements, customer feedbacks and also some technical reasons led Oracle to develop this feature and make it available out-of-the-box in the product.


Going back to the fundamental question of this post: which one should I use? And the answer is, as usual, IT DEPENDS. It really depends upon the project requirements and their alignment with the different approaches functionalities and technical details.

But before you start saying “I do have my requirements, but I still don’t know which one to use”, let’s review the main differences between these two implementation approaches. With some knowledge about the main differences and the project requirements in hands, certainly it will be easier to make a decision.

  • LDAP Synchronization is a mandatory piece for the OIM-OAM integration (in the current 11.1.1.x releases). So if you are planning to integrate these products and make full use of the password lifecycle management features provided by the integration, LDAP Synch is a MUST. 
  • LDAP Synchronization is data oriented approach. Although it is possible to configure attribute mapping, basic synchronization rules and some other minor things, in the end, it is all about data: users and roles being synched behind the scenes from/to the LDAP server. The synchronized LDAP account is NOT in the users’ accounts list in OIM.
  • Connector is a process oriented approach. In this approach, one can make full use of OIM features like request/approvals based provisioning, access policy based provisioning, modification requests. A user will see, among his/her accounts, the LDAP account and he/she can take actions from there.
  • Reporting and auditing will contain information about the LDAP account only if a LDAP connector is implemented.

There are other technical details and functionalities that may be considered, but the topics above are the basics and first ones that you can use to help on the decision.