LDAP groupOfNames and groupOfUniqueNames SearchCount 0 entries
search cancel

LDAP groupOfNames and groupOfUniqueNames SearchCount 0 entries

book

Article ID: 275392

calendar_today

Updated On:

Products

SITEMINDER

Issue/Introduction

 

When running a Policy Server, this one isn't able to authorize users.

The Policy Server finds the group:

[09/11/2023][16:55:06.086][16:55:06][2139565][140124306269952][SmDsLdapProvider.cpp:2405][CSmDsLdapProvider::Search][][][][][][][][][][][][][][][][][][][(Search) Base: 'dc=example,dc=com', Filter: '(&(|(objectclass=groupOfNames)(objectclass=groupOfUniqueNames)(objectclass=group)(objectclass=top)(objectclass=exampleGroupOfNames))(cn=<the_group_cn>))'. Status: 1 entries.][][Ldap Search callout succeeds.][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]

But the Policy Server doesn't find the user as this group member:

[09/11/2023][16:55:06.247][16:55:06][2139565][140124306269952][SmDsLdapProvider.cpp:2685][CSmDsLdapProvider::SearchCount][][][][][][][][][][][][][][][][][][][(SearchCount) Base: 'exampleguid=<xxxx>,o=groups,dc=example,dc=com', Filter: 'member=exampleguid=<name2>,o=<specific_group>,dc=example,dc=com'. Status: 0 entries][][Ldap SearchCount callout succeeds.][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]

The issue can be worked around by removing groupOfNames object classes from the LDAP group.

  1. Why does the groupOfNames object class take precedence over the groupOfUniqueNames? Has the Policy Server any registry entry which defines the precedence of object classes?
  2. Even if the search filter with member attribute failed with groupOfNames, why doesn't the Policy Server search further with uniqueMember attribute with the groupOfUniqueNames object class?

 

Environment

 

  Policy Server 12.8SP7 on RedHat 7;
  User Store on LDAP Oracle Unified Directory 12.2.1.4.221009;

 

Cause

 

Looking the LDAP configuration, the group

  exampleguid=<xxxx>,o=groups,dc=example,dc=com

has 2 objectclasses:

  groupOfNames
  groupOfUniqueNames

Each of them should have its attribute:

  | ObjectClass        | Attribute    |
  |--------------------+--------------|
  | groupOfNames       | member       |
  | groupOfUniqueNames | uniqueMember |

When looking at the group config, only the attribute "uniqueMember" for groupOfUniqueNames is configured:

  # <xxxx>, groups, example.com
  dn: exampleguid=<xxxx>,o=groups,dc=example,dc=com
  uniqueMember: exampleguid=<name2>,o=<specific_group>,dc=example,dc=com
  cn: <the_group_cn>
  description: The group
  objectClass: groupOfUniqueNames
  objectClass: groupOfNames
  objectClass: top
  objectClass: exampleGroupOfNames
  exampleguid: <xxxx>

Both attributes are mandatory should be set as per RFC 4519 (1).

  1. The groupOfNames object class doesn't take precedence over the groupOfUniqueNames. As the ObjectClass is not set in the LDAP Group, so the member attribute isn't checked to determine if the user is part of the group or not.
  2. The Policy Server doesn't check further because as groupOfNames is set as ObjectClass, member attribute is expected, and if the member attribute is not present, then it's considered as not part of the group.

 

Resolution

 

In the LDAP group:

   exampleguid=<xxxx>,o=groups,dc=example,dc=com

add the attribute

   member=exampleguid=<name2>,o=<specific_group>,dc=example,dc=com

to solve this issue.

 

Additional Information


(1)

    Defining Groups