The reason why I ignored this was because the OIA 11.1.1.3 LDAP configuration files still reside within the vanilla package.

Firstly, I have OID and OIA residing on separate domains on the same localhost running on Oracle Database 11.2.x with Weblogic 10.3.6.

I also used ODSM to connect to OID with the admin credentials without an issue. As highlighted within the video, I created a username called JBlogs with the Person objectclass.

Initially, I noticed from the vanilla log setting a 'ERROR: Bad Credentials' error.

ERROR [MultipleChainablePasswordDaoAuthenticationProvider] ERROR: Bad Credentials org.springframework.security.BadCredentialsException: Invalid username, password or context

This statement, which I find out later in my research, is quite ambiguous and could be labelled as a red herring. If you look within the LdapPasswordAuthenticationDao.class, you will notice many catch exceptions that you're more interested in.

To see the logs that you're more interested in, turned up the logging from within OIA (log4j.logger.com.vaau.rbacx.security=DEBUG). Prior to the 'Bad Credentials error' you may see the following error:

DEBUG [LdapPasswordAuthenticationDao] Connecting to ldap://localhost:3061/DC=localdomain as Username1
DEBUG [LdapPasswordAuthenticationDao] Inside simple authentication to connect and search
DEBUG [LdapPasswordAuthenticationDao] Bind DN to search user : cn=orcladmin,cn=Users,dc=localdomain
DEBUG [LdapPasswordAuthenticationDao] User Search Filter : cn=Username1
DEBUG [LdapPasswordAuthenticationDao] Root Context : DC=localdomain
DEBUG [LdapPasswordAuthenticationDao] Full DN of the user : cn=Username1,cn=Users,DC=localdomain
INFO [LdapPasswordAuthenticationDao] Authentication exception for user.
javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid Credentials]

Providing the fact that I only binding at this stage, I immediately assume that the admin cn=orcladmin,cn=Users,dc=localdomain was the issue.
To ensure I had the correct credentials, I used the ldapbind to check if I could connect by using the credentials.

[oracle@localhost WEB-INF]$ ldapbind -h localhost -p 3061 -D cn=Username1,cn=Users,DC=localdomain -w Password1

I was greeted with the bind successful notification, which confirmed I had the correct configuration with the LDAP.properties file.

The ldapAuthentication.rootContext within OIA is more commonly know as the BASE DN (basically, all the DC= values), which in my demonstration, is the location of the users. Just to re-confirm the rootContext, I decided to change the case sensitivity.

From...

ldapAuthentication.rootContext=DC=localdomain

To...

ldapAuthentication.rootContext=dc=localdomain

Doing this caused the following issue:

Caused by: javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object]; remaining name 'dc=localdomain'

Changing this back to the case sensitive string value eradicated this error popping up. Still no closer though I was confident at this stage that I have the correct string value as the root context

Using this information, I questioned whether the OIA authentication was the issue. To understand this issue, I disabled all the #ldapAuthentication.securityPrincipal and #ldapAuthentication.securityCredential to enable anonymous bind authentication.

#ldapAuthentication.securityPrincipal=CN=User,DC=vaau,DC=corp,DC=net
#ldapAuthentication.securityPrincipal=cn=orcladmin,cn=Users,dc=localdomain
#ldapAuthentication.securityCredential=password
#ldapAuthentication.securityCredential=Password1
#ldapAuthentication.securityCredential.encrypted=d83970156ba26d00

I was presented with the following issue:

Caused by: javax.naming.AuthenticationNotSupportedException: [LDAP: error code 48 - Server is Configured to Deny Anonymous Binds]; remaining name 'DC=localdomain'

By default, OID does not accept Anonymous binds

I tried to follow the the post, 31.7 Managing Anonymous Binds from Oracle though it took me an hour to try and find the Administration tab though it turns out you right click on the server and then select Administration (Just one of those days!). Anyway, After I located the first tab, it's fairly simple to enable anonymous mode for the server.

After bouncing the WLS servers, I noticed new information within the logs: Using Anonymous Authentication while searching

DEBUG [MultipleChainablePasswordDaoAuthenticationProvider] ----> using authentication dao [com.vaau.commons.springframework.security.dao.ldap.LdapPasswordAuthenticationDao@245215e7]
DEBUG [PasswordDaoAuthenticationProvider] ---> attempting authentication for user 'Username1'
DEBUG [PasswordDaoAuthenticationProvider] ------> looking for user 'Username1' in cache
DEBUG [EhCacheBasedUserCache] Cache hit: false; username: Username1
DEBUG [PasswordDaoAuthenticationProvider] ------> loading user 'Username1' from backend
DEBUG [LdapPasswordAuthenticationDao] Connecting to ldap://localhost:3061/DC=localdomain as Username1
DEBUG [LdapPasswordAuthenticationDao] Using Anonymous Authentication while searching
DEBUG [LdapPasswordAuthenticationDao] User Search Filter : sn=Username1
DEBUG [LdapPasswordAuthenticationDao] Root Context : DC=localdomain
INFO [LdapPasswordAuthenticationDao] Authentication exception for user.
javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid Credentials]
 at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3067)

To confirm that the anonymous binding was in effect, I opened up a web browser and executed the following command

ldap://localhost:3601/DC=localdomain

If anonymous works, you should be able to see the directory files within OID through the gui

JUST before I was giving up on the issue, I managed to get LDAP working for OIA 11.1.1.5.4. This came around by collecting the information regarding the log4j.properties and ldap.properties though for some reason, OIA failed to execute new logs when I make changes to the log4j.properties file (probably because I had been playing around with the values within the file.

Whilst troubleshooting, I also populated the 11.1.1.3 class files within the dao directory. That said, I decided to revert back to the 11.1.1.5 vanilla installation to ensure no changes were permanent.

To ensure I had 11.1.1.5 configuration installed, I completely deleted the deployed OIA version from the WLS stage directory. On my environment the deployed directory in question was:

/home/oracle/Oracle/Middleware/user_projects/domains/base_domain/servers/oia_server1/stage/rbacx

I decided to redeploy as I would normally do in the OIA installation, as mentioned in the blog, HOW TO: Install OIA 11.1.5.4 on linux 64bit. When I restarted the OS and redeployed OIA. I was able to authenticate via OIA/OID. I apologise that I cannot be too precise and deliver a step-to-step guide on how to create the LDAP authentication. There's little/no documentation for OIA 11.1.1.5.x 11g regarding LDAP though I hope this at least helps.

Here are the variable used within the LDAP.properties file

#ldapAuthentication.securityCredential.encrypted=d83970156ba26d00

# Properties file with ldap authenticaton related settings
ldapAuthentication.defaultRole=ROLE_AUTHENTICATED_PRINCIPAL

ldapAuthentication.enabled=true
ldapAuthentication.tryNextProviderIfNoAuthenticated=false
ldapAuthentication.stopIfCommunicationError=true

#Multiple urls can be specified using ; as delimeter
#ldapAuthentication.url=ldap\://localhost:389/DC=vaau,DC=corp,DC=net

#ldapAuthentication.url=ldap\://localhost:389/
ldapAuthentication.url=ldap\://localhost:3061/

#ldapAuthentication.rootContext=DC=vaau,DC=corp,DC=net
ldapAuthentication.rootContext=DC=localdomain

# Uncomment the following if ldap does not allow anonymous reads to do searches
#ldapAuthentication.securityPrincipal=CN=User,DC=vaau,DC=corp,DC=net
#ldapAuthentication.securityPrincipal=cn=orcladmin,cn=Users,dc=localdomain
#ldapAuthentication.securityCredential=password
#ldapAuthentication.securityCredential=Password1
#ldapAuthentication.securityCredential.encrypted=d83970156ba26d00

#SSL
#optional config params
#ldapAuthentication.keystore=/Users/gustavofaerman/cacert/love.ks
#ldapAuthentication.trustStorePassword=secret

#SSL URL
#ldapAuthentication.url=ldaps\://localhost:636/DC=vaau,DC=corp,DC=net

About the author