TAGS

Recent Posts

Archives

Limitations of Using Microsoft Active Directory as an Authentication Provider for OBIEE
Posted on July 1, 2013
Author: Kirby Lunger, Performance Architects

Microsoft Active Directory (MSAD) is a popular choice as an Authentication Provider for the entire Oracle BI Foundation Suite (OBIEE) for a variety of reasons, including the fact that many companies use it for their network authentication system.

For those of you who are not familiar with how an authenticator is set up within BI Foundation Suite (BIF), here is a very brief summary. As you may already know, authentication is now brokered by WebLogic since the advent of OBIEE 11g (back in the old days, authentication was set up and brokered by the BI Server by doing what was call “Init Block Authentication”).

In OBIEE 11g, you log into the WebLogic administration console and set up a new “Provider,” specifically an Authentication provider, and then choose MSAD as the specific provider. Once this is done, you will need to enter all your specific Active Directory information such as the host name, the service account you’re using to access MSAD, and other specific parameters for filtering.
People often don’t understand that as OBIEE adds more and more capabilities, we OBIEE professionals have to become near-experts in these other tools as well such as WebLogic, Mapviewer, Essbase, etc. Therefore, I highly recommend that you buy an online book on MSAD and become especially familiar with writing queries in MSAD.

Just recently I was asked to troubleshoot a major production issue at a client site. Some of the major symptoms were stuck threads, slow login, and hung sessions. What was more interesting was that some users were perfectly fine, and others were in tough shape. Having gone through the MSAD configuration so many times, I knew right away the problem was with the MSAD Authentication Provider in WebLogic.

As it turned out, the culprit was a couple of MSAD servers in the cluster that were decommissioned over a maintenance weekend. It took a lot of work to trace this back, but the important lesson here was that the problem was 100% Active Directory. There were some good lessons learned that I would like to share:

First, ask your MSAD administrator what the “Size Limit” and “Page Size” is. Even up to OBIEE Version 11.1.1.7.1, there is a bug where OBIEE can only read users and groups from MSAD up to the Page Size limit. I raised this issue in an Oracle SR ticket with one particular client, and Oracle Support’s recommendation was to remove the limit from Active Directory. I’m not kidding!

The only way to work around this is to specifically set a filter in the User Filter field on the Provider Specific tab in the MSAD Weblogic Authenticator. Have your MSAD administrator write you something that only returns real OBIEE users. Also do the same thing for group filtering. More information is available here: http://msdn.microsoft.com/en-us/library/ms180880(v=vs.80).aspx.

Next, ask your MSAD administrator how many levels deep your OBIEE groups are nested. You will need this to set a proper search depth in the MSAD WebLogic provider settings. Again, look on the Provider tab and you will see the search depth setting there. If you do not set the appropriate depth, there will be some users and groups that will never be found.

Finally, ask your MSAD administrator if you should use sAMAccountName. In many cases, this is the safest bet, but you should always check. Important note: sAMAccountName happens to hold not only user names, but also rooms, printers, etc. Remember, not just users are setup in MSAD! If you use sAMAccountName, you should make sure you filter your data to get humans!

Author: John McGale, Performance Architects

Share
© Performance Architects, Inc. and Performance Architects Blog, 2006 - present. Unauthorized use and/or duplication of this material without express and written permission from this blog's author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Performance Architects, Inc. and Performance Architects Blog with appropriate and specific direction to the original content.

Leave a Reply

Your email address will not be published. Required fields are marked *