Troubleshooting
Problem
After providing credentials for login or during a log on by Single Sign-On (SSO) an error occurs rather than the user being authenticated. This can happen in Cognos Connection, through a 3[rd party Portal, Framework Manager or any other Cognos platform integrated product like Cognos NOW! (IBM Cognos Real-time Monitoring) or Planning. The authentication provider is LDAP either pointing to an LDAP server or an Active Directory. It can affect all users or only a subset of them. It's independent of entry point (accessing a gateway or dispatcher directly) and is agnostic of OS or application server. Network connectivity to the authentication source is fine and works outside of Cognos.]
Symptom
CAM-AAA-0134 Unable to retrieve information for the user.
or
CAM-AAA-0134 Unable to retrieve information for the user <some-user-entry>
Cause
Authentication in IBM
Cognos is handled by a subcomponent of the Content Manager install component called Cognos Access Manager (CAM), not to be mixed up with Series7 Access Manager.
During the authentication process
Once the bind succeeded an LDAP search for the user entry is sent. If no entry is found the authentication will fail with CAM-AAA-0036 Invalid credentials. This concludes phase 1.
Depending on the authentication method a second bind may occur for phase two now.
If authentication to Cognos is by SSO (use external identity mapping is set to true) the authenticating user didn't provide any credentials to Cognos which
If the user tries to login manually (Basic Signon) he will get prompted to provide username and password. These user credentials will be used by
In Phase 2 the LDAP provider will try to read the user entry, in particular the attribute mapped for 'user name' and all groups the user is a member of. Then the names of all the LDAP entries which make up the absolute DN of the users entry (the parent entries up to schema root, not just BaseDN!) get looked up.
If any of the searches in phase2 fails the CAM-AAA-0134 error will be thrown.
Resolving The Problem
(whenever LDAP server is mentioned, this applies to AD accessed through LDAP as well)
The possible reasons for the error are
1. the credentials used for the search lack privileges to read a required entry or attributes
The search is run in the context of BCs (SSO) or the authenticating user's credentials (Basic Sign-on). These LDAP credentials must be able to read all mapped attributes for the user's entry and all parent entries up to the BaseDN (including).There are 3 types of entries the LDAP provider knows: folders, groups and user entries. There is a mapping section in the configuration for each of them where the specific attributes of that type are listed and which objectclasses identify and entry of a certain type. All of the listed ones PLUS the attribute defined for unique identifier PLUS the objectclass attribute must be readable for the credentials running the search. Create an AAA trace (refer related documents) and provide it, along with an EXPORTED version of the configuration file, to Customer Support for troubleshooting. The AAA trace will show the LDAP searches issued and the results received. To verify yourself use a 3rd party LDAP browser to bind to the LDAP using the same credentials (either BCs or user?s credentials) and access the user entry.
2. the search request is malformed due to incorrect configuration of the namespace e.g. is looking for something which does not exist
The LDAP search which is sent is formed based on configured values for BaseDN, unique identifier and entry type mappings (for folder, groups and user entries). If the entries in the LDAP use other than the configured attributes the search may fail.Verify the mappings for groups, folder and user entries. In particular make sure all possible alternate objectclasses for one type are mapped. If in doubt, talk to your LDAP administrator.Create an AAA trace (refer related documents) and provide it, along with an EXPORTED version of the configuration file, to Customer Support for troubleshooting. The AAA trace will show the LDAP searches issued and the results received. To verify yourself use a 3rd party LDAP browser to bind to the LDAP using the same credentials (either BCs or user?s credentials) and look at any entry starting at the baseDN down to the user. Note all objectclasses for the entries in a list and make sure those are covered in the mappings. (E.g. a folder may be of objectclass organizationUnit OR organization)
3. the search for the user name attribute did not return one single result but either none or more than one
The search for the user entry is based off the results of the previous lookup search. The lookup search will be constructed from the user lookup or external identity mapping string and the objectclass mapped for user entries (Account Object class). The query to obtain the attribute mapped for user name in phase 2 of the authentication will attempt to read the entry identified by the lookup search and may run with different credentials. Create an AAA trace (refer related documents) and provide it, along with an EXPORTED version of the configuration file, to Customer Support for troubleshooting. The AAA trace will show the LDAP searches issued and the results received.To verify yourself use a 3rd party LDAP browser to bind to the LDAP using the same credentials (either BCs or user?s credentials) and issue the same search requests.You can grab them from an access log of the LDAP server or the AAA trace. Depending on scenario the error stack may or may not contain more detailed error codes like CAM-AAA-0172, CAM-AAA-0178 or CAM-AAA-0048 + CAM-AAA-0189 which will further narrow down the root cause of the issue. Please refer to related documents to learn about these.
Additional hints:
If in the LDAP namespace the BCs are empty, verify that the LDAP server does allow anymous access.If this occurs through Framework Manager (FM) verify that FM uses the same authentication method, either SSO or BASIC as Cognos Connection. Mind the possibly two different credentials used for searches in phase 1 and 2. Verify the user account LDAP permissions are sufficient. If BCs are used and the BCs entry is in a different branch of the LDAP than the users the lookups up to the schema root may go along a different path and hence require different LDAP permissions. Ensure that LDAP users have sufficient permissions!
Example:
Login user: uid=some_user, ou=people,ou=project, o=organisation Bind User : uid=crn_admin,ou=admins,o=organization
If 'some_user' user is not allowed to read the ou attribute of people, projects & organization the error will show up.
Related Information
Historical Number
1041719
Was this topic helpful?
Document Information
Modified date:
15 June 2018
UID
swg21343378