FYI: Identity found in Weblogic but could not be authenticated (OBI-SEC-00022, OVD-40066)

During most 11g implementations, a practitioner will be required to implement a security policy that allows OBIEE 11g Answers to authenticate against an external data source (such as OID , ADUC, or even an external database). Infact, I've even posted a how-to on integrating Oracle Internet Directory as an authentication source with 11g Answers .

During the security integration process, Oracle's technical documentation recommends that the practitioner should verify that the Users and Groups are visible in Weblogic Admin Console before completing the implementation process.   See the screen below for an example of a fairly common Users and Groups section:

Nothing too spectacular. You'll see that the user i've filtered on has 'myOIDDirectory' (the name of my OID authentication provider) listed as its source.

Per Oracle's technical documentation, we would mark this as a success and move on.

Now you attempt to log into Answers 11g and the authentication fails:

Your real time log now says the following: 

SecurityService::authenticateUserWithLanguage [OBI-SEC-00022] Identity found but could not be authenticated

and your bi_server1-diagnostic.log confirms:

Relax, you're not alone, and the fix is quick : If you've configured an external authentication provider using Oracle Internet Directory or Active Directory , OBI-SEC-00022 most likely means you've provided the correct User Base DN but at the wrong level.

For example (using OID):

If your OID tree is : cn=team,cn=users,cn=company,dc=trusted,dc=oracle,dc=dev - meaning that your user list is under the cn=team branch (reading left to right, cn=company being the root), then you need to specify your User Base DN one level above that branch. In this case, your User Base DN would be

cn=users,cn=company,dc=trusted,dc=oracle,dc=dev

Although not specifically stated in the Fusion Middleware Security Guide , your User Base DN should be one level above the branch that contains your users.

Also, make sure your Principal DN specifies the full path. 

For example:

If you're authenticating with cn=orcladmin, your Principal DN cannot be cn=orcladmin. It should be:

cn=orcladmin,cn=team,cn=users,cn=company,dc=trusted,dc=oracle,dc=dev  - assuming that the orcladmin account is under the cn=team directory.

keywords: obiee 11g security, obiee ldap authentication, OBIEE-SEC-00022, OVD-40066, OBIEE OID authentication, weblogic authentication provider