To complement my earlier postings, Cannot change WebCenter Spaces role memberships, we finally came to the conclusion.
Bug 20662946 : IF UNIQUEMEMBER OF A USER IN A ROLE IS DELETE ERRORS OCCUR IN WCP is applicable for the Oracle OPSS, on which WebCenter relies. However, this was fixed in
Patch 18559164 MERGE REQUEST ON TOP OF 11.1.1.7.0 FOR BUGS 18428053 14598730 17566136 17838292.
Meaning, this Problem doesn't occur once Patch 18559164 has been installed (on top of 11.1.1.7), or when running a higher version (11.1.1.8).
The problem was hit due to the long overdue patching on the WebCenter environment. Being patched to 11.1.1.8.6, the issue is confirmed no longer reproducible.
Wednesday, 22 April 2015
Tuesday, 31 March 2015
Enterprise Manager Cloud Control (OEM) ldap service test
An ldap service test in OEM
Strange, a straightforward ldap service test fails consistently with a "LDAP Address Search Failed. invalid attribute description" as result of the test.
Enabling tracing on the OID reveals something strange: it doesn't actually honor the ldap search filter, or so it seems with the default test. I see always:
INFO :gslfseADoSearch BASE = cn=Users,dc=svb,dc=org FILTER = (objectclass=*) #REQDATTR = 0 SCOPE = 0 REQDATTRS = TIMELIMIT = 0 SIZELIMIT = 0 DEREF = 3
Even though we entered a completely different search filter, e.g. "(&(cn=orcladmin))"
Problem
What the test performs is not an ldapsearch followed by an ldapcompare. If that is the case, perhaps we should not have it search. If we modify the search to be the object itself. We are not starting a search at base "cn=Users, dc=example, dc=com" for object "cn=orcladmin", we start the search at base "cn=orcladmin, cn=Users, dc=example, dc=com". Then the filter doesn't matter as it will never return more then one entry - no filtering required.Solution
LDAP Search Filter => mail=orcladmin LDAP Search Base => cn=orcladmin, cn=Users, dc=example, dc=com LDAP Compare Attribute Name => uid LDAP Compare Attribute Value => orcladmin
And then if we verify the service test, we get a "success".
Subscribe to:
Comments (Atom)
Wednesday, 22 April 2015
Cannot change WebCenter Spaces role memberships #3
To complement my earlier postings, Cannot change WebCenter Spaces role memberships, we finally came to the conclusion.
Bug 20662946 : IF UNIQUEMEMBER OF A USER IN A ROLE IS DELETE ERRORS OCCUR IN WCP is applicable for the Oracle OPSS, on which WebCenter relies. However, this was fixed in
Patch 18559164 MERGE REQUEST ON TOP OF 11.1.1.7.0 FOR BUGS 18428053 14598730 17566136 17838292.
Meaning, this Problem doesn't occur once Patch 18559164 has been installed (on top of 11.1.1.7), or when running a higher version (11.1.1.8).
The problem was hit due to the long overdue patching on the WebCenter environment. Being patched to 11.1.1.8.6, the issue is confirmed no longer reproducible.
Bug 20662946 : IF UNIQUEMEMBER OF A USER IN A ROLE IS DELETE ERRORS OCCUR IN WCP is applicable for the Oracle OPSS, on which WebCenter relies. However, this was fixed in
Patch 18559164 MERGE REQUEST ON TOP OF 11.1.1.7.0 FOR BUGS 18428053 14598730 17566136 17838292.
Meaning, this Problem doesn't occur once Patch 18559164 has been installed (on top of 11.1.1.7), or when running a higher version (11.1.1.8).
The problem was hit due to the long overdue patching on the WebCenter environment. Being patched to 11.1.1.8.6, the issue is confirmed no longer reproducible.
Tuesday, 31 March 2015
Enterprise Manager Cloud Control (OEM) ldap service test
An ldap service test in OEM
Strange, a straightforward ldap service test fails consistently with a "LDAP Address Search Failed. invalid attribute description" as result of the test.
Enabling tracing on the OID reveals something strange: it doesn't actually honor the ldap search filter, or so it seems with the default test. I see always:
INFO :gslfseADoSearch BASE = cn=Users,dc=svb,dc=org FILTER = (objectclass=*) #REQDATTR = 0 SCOPE = 0 REQDATTRS = TIMELIMIT = 0 SIZELIMIT = 0 DEREF = 3
Even though we entered a completely different search filter, e.g. "(&(cn=orcladmin))"
Problem
What the test performs is not an ldapsearch followed by an ldapcompare. If that is the case, perhaps we should not have it search. If we modify the search to be the object itself. We are not starting a search at base "cn=Users, dc=example, dc=com" for object "cn=orcladmin", we start the search at base "cn=orcladmin, cn=Users, dc=example, dc=com". Then the filter doesn't matter as it will never return more then one entry - no filtering required.Solution
LDAP Search Filter => mail=orcladmin LDAP Search Base => cn=orcladmin, cn=Users, dc=example, dc=com LDAP Compare Attribute Name => uid LDAP Compare Attribute Value => orcladmin
And then if we verify the service test, we get a "success".
Subscribe to:
Comments (Atom)