OBIEE and OAS with Active Directory: When Only Some Users Can Log In

Table of Contents

This is a record of a customer environment where OBIEE 12c (12.2.1.1) was integrated with Active Directory (AD): some AD accounts could log in, and others failed with “Invalid User Name or Password.” When the password is right but only some users fail, the cause is usually the search scope or filter settings of the AD authentication provider (ActiveDirectoryAuthenticator).

I first wrote this up in Notion in September 2024 and re-checked it in October 2026 against the Oracle Analytics Server (OAS) security documentation and the WebLogic 12.2.1.4 MBean metadata. The customer’s domain, AD server IP address, service account, and encrypted password string from the original are all replaced with example values. The procedure is the same for OBIEE 12c and for OAS, which runs on the same WebLogic 12.2.1.4.

Symptoms

Users in the same AD domain: some can log in, the rest fail with “Invalid User Name or Password.”
The BI logs show [nQSError: 43126] Authentication failed: invalid user/password, and WebLogic records an authentication failure ([Security:090938], [Security:090302]).
In the WebLogic Administration Console, under Security Realms > myrealm > Users and Groups, some AD users or groups are missing.

The usual three causes

Setting	When it’s wrong
User Base DN	Users outside the specified OU can’t be found, so authentication fails. Check this first when only some departments can log in.
Group Base DN	If groups are outside the specified OU, the group list is empty and role mapping based on AD groups doesn’t work.
User and group name attributes and filters	If the login ID attribute (for example, `sAMAccountName`) and the filters don’t match, users can’t be found.

The default User Search Scope and Group Search Scope are subtree, so set each Base DN to a common parent OU that contains all the target users and groups.

Troubleshooting steps

1. Check whether users and groups appear in the console

Under Security Realms > myrealm > Users and Groups, look for a user who fails to log in and the groups that user belongs to. If the user is missing, look at the User Base DN or the user filters; if the groups are missing, look at the Group Base DN or the group filters.

2. Confirm the DNs with the AD administrator

Get the actual DNs of a failing user, a working user, and their groups from the AD administrator and compare them. To check from the server, run ldapsearch with the same Base DN and filter that WebLogic uses.

# Users: search with WebLogic's User Base DN and User From Name Filter
ldapsearch -H ldap://ad01.corp.example.com:389 \
  -D "CN=svc-obiee,OU=Service,OU=HQ,DC=corp,DC=example,DC=com" -W \
  -b "OU=HQ,DC=corp,DC=example,DC=com" \
  "(&(sAMAccountName=user01)(objectclass=user))" dn memberOf

# Groups: search with the Group Base DN and Group From Name Filter
ldapsearch -H ldap://ad01.corp.example.com:389 \
  -D "CN=svc-obiee,OU=Service,OU=HQ,DC=corp,DC=example,DC=com" -W \
  -b "OU=HQ,DC=corp,DC=example,DC=com" \
  "(&(sAMAccountName=BI_Users)(objectclass=group))" dn

No result means the target isn’t under that Base DN. -W prompts for the password, so it doesn’t end up in your command history.

3. Move the Base DN up to a common parent OU

In my case, groups couldn’t be found while the Group Base DN pointed at a department OU (OU=IT,OU=HQ,...), because the groups lived in a different OU. Widening it to the common parent, OU=HQ,..., fixed it. Along the way I also tried values such as OU=IT,DC=corp,... with the middle OU left out; a DN like that is not a real path in AD, so it doesn’t work. Use the DNs exactly as the AD administrator gives them to you.

How to configure it

These steps follow the Active Directory procedure in the OAS security documentation.

In the Administration Console, click Lock & Edit.
Under Security Realms > myrealm > Providers > Authentication, click New and add a provider of type ActiveDirectoryAuthenticator (for example, ADAuthenticator).
Set the Control Flag of both DefaultAuthenticator and ADAuthenticator to SUFFICIENT (the default is REQUIRED).
In ADAuthenticator > Provider Specific, enter the connection details and the values below, then click Save.
Under Providers > Authentication, click Reorder and move ADAuthenticator to the top.
Click Activate Changes, then restart WebLogic (the Administration Server and the BI Managed Server).

Setting	Default	Example (login ID is sAMAccountName)
User Base DN	`ou=WLSMEMBERS,dc=example,dc=com`	`OU=HQ,DC=corp,DC=example,DC=com`
User Name Attribute	`cn`	`sAMAccountName`
User From Name Filter	`(&(cn=%u)(objectclass=user))`	`(&(sAMAccountName=%u)(objectclass=user))`
Group Base DN	`ou=WLSGROUPS,dc=example,dc=com`	`OU=HQ,DC=corp,DC=example,DC=com`
Static Group Name Attribute	`cn`	`sAMAccountName`
Group From Name Filter	`(&(cn=%g)(objectclass=group))`	`(&(sAMAccountName=%g)(objectclass=group))`

In AD, cn is usually the display name (first and last name) and sAMAccountName is the login ID. The default is cn, so to let users sign in with their login ID, change the name attribute and its filters together.
The OAS documentation says that when you change a name attribute away from cn, you must change the matching filters too: for users, User Name Attribute with All Users Filter and User From Name Filter; for groups, Static Group Name Attribute with All Groups Filter and Group From Name Filter, all using the same attribute.
According to the WebLogic metadata, these settings require a restart. Activating without restarting doesn’t apply them.

Once applied, the settings are written to the domain’s config/config.xml like this (example values). My original note had a step to stop the BI services, check config.xml, and edit it by hand if needed. config.xml is managed by the console, though, so it’s safer to only check it there and make changes in the console.

<sec:authentication-provider xsi:type="wls:active-directory-authenticator-type">
  <sec:name>ADAuthenticator</sec:name>
  <sec:control-flag>SUFFICIENT</sec:control-flag>
  <wls:host>ad01.corp.example.com</wls:host>
  <wls:user-name-attribute>sAMAccountName</wls:user-name-attribute>
  <wls:principal>CN=svc-obiee,OU=Service,OU=HQ,DC=corp,DC=example,DC=com</wls:principal>
  <wls:user-base-dn>OU=HQ,DC=corp,DC=example,DC=com</wls:user-base-dn>
  <wls:credential-encrypted>{AES}...</wls:credential-encrypted>
  <wls:user-from-name-filter>(&amp;(sAMAccountName=%u)(objectclass=user))</wls:user-from-name-filter>
  <wls:group-base-dn>OU=HQ,DC=corp,DC=example,DC=com</wls:group-base-dn>
  <wls:group-from-name-filter>(&amp;(sAMAccountName=%g)(objectclass=group))</wls:group-from-name-filter>
  <wls:static-group-name-attribute>sAMAccountName</wls:static-group-name-attribute>
  <wls:use-retrieved-user-name-as-principal>false</wls:use-retrieved-user-name-as-principal>
</sec:authentication-provider>

Inside the XML file, the & in a filter is stored as &.

Related settings

Cache: The LDAP cache (Cache Enabled) is on by default, with a size of 32 KB and a TTL of 60 seconds. The original environment had it turned off, which means more AD lookups on every login. Unless you have a reason not to, leave it on and consider a larger size if you have many users. My original note recommended “3200 or more”; I couldn’t find a source for that number, so I removed it.
Role mapping: A successful login still needs AD groups mapped to application roles (BIServiceAdministrator, BIContentAuthor, BIConsumer, and so on) to grant permissions. “BIAuthor” in my original note is the 11g-era name; in 12c and OAS the role is BIContentAuthor.
Service account: The Principal account only needs read access. If its password expires, every AD login fails, so confirm its expiry policy with the AD administrator.

Summary

When only some AD users fail to log in, first check whether those users and their groups appear under Users and Groups in the console. If they don’t, check that each Base DN contains them and that the name attributes and filters use the same attribute (such as sAMAccountName). Verify the values with ldapsearch, make the changes in the console, and restart.

To record the client IP and user ID of failed logins, see Tracking Failed OBIEE Logins. For the case where AD users sign in quickly but the weblogic account is slow, see OAS Sign-In Delays: When AD Users Are Fast but weblogic Is Slow.