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".

3 comments:

  1. This comment has been removed by a blog administrator.

    ReplyDelete
  2. Excellent Jack,
    Thank you so much.
    cheers
    Santiago

    ReplyDelete
  3. Thank you so much. You helped me

    ReplyDelete

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".

3 comments:

  1. This comment has been removed by a blog administrator.

    ReplyDelete
  2. Excellent Jack,
    Thank you so much.
    cheers
    Santiago

    ReplyDelete
  3. Thank you so much. You helped me

    ReplyDelete