Sorry, my original investigation into this was incorrect. I thought we weren't saving the originalDN, but it appears we are.

The bug I'm seeing:

(Wed Jul 13 09:52:55 2011) [sssd[be[sgallagh-test.bos.redhat.com]]] [hbac_service_attrs_to_rule] (1): [cn=sudo,cn=hbacservicegroups,cn=hbac,dc=sgallagh-test,dc=bos,dc=redhat,dc=com] does not map to either a service or service group. Skipping

From LDAP:

  dn: cn=sudo,cn=hbacservicegroups,cn=hbac,dc=sgallagh-test,dc=bos,dc=redhat,dc=com
  cn: Sudo
  description: Default group of Sudo related services
  member: cn=sudo,cn=hbacservices,cn=hbac,dc=sgallagh-test,dc=bos,dc=redhat,dc=com
  member: cn=sudo-i,cn=hbacservices,cn=hbac,dc=sgallagh-test,dc=bos,dc=redhat,dc=com
  member: cn=sss_test,cn=hbacservices,cn=hbac,dc=sgallagh-test,dc=bos,dc=redhat,dc=com
  ipauniqueid: 393f8a12-8c59-11e0-a598-00163e46ac56
  objectclass: ipaobject
  objectclass: ipahbacservicegroup
  objectclass: nestedGroup
  objectclass: groupOfNames
  objectclass: top

Specifically, note that the capitalization of the {{{cn}}} attribute differs between the attribute and the DN.

I think we need to change the DB so that originalDN is treated as case-insensitive for searches.

There are two possible solutions here:
1. Change the originalDN attribute in the sysdb to be case-insensitive. I don't like this as DNs in LDAP are case-sensitive.

Replying to [comment:1 sgallagh]:

I think we need to change the DB so that originalDN is treated as case-insensitive for searches.

There are two possible solutions here:
1. Change the originalDN attribute in the sysdb to be case-insensitive. I don't like this as DNs in LDAP are case-sensitive.

1. This is not technically true. In LDAP the case sensitivity of each RDN depends on the schema of the attribute. The attribute name is always case insensitive, the attribute value case sensitivity depends on how the attribute is defined in the schema.

In our case it is much easier to simply always treat a DN as case insensitive, it will not be perfect perhaps, but much better than the current status if originalDN is indeed case-sensitive.

1. What is option 2 ? :)

Do not forget to back port to 1.5, please.

milestone: NEEDS_TRIAGE => SSSD 1.6.0

Fields changed

owner: somebody => sgallagh

Sorry, option 2 was going to be
2. Make changes on the IPA side to guarantee that the DN matches the CN for case.

Fields changed

patch: 0 => 1
rhbz: =>
status: new => assigned

Fixed by 826937ebae068e2ebe59dd37c5f12331f09fe3b9

resolution: => fixed
status: assigned => closed

Backported to sssd-1-5

d086d5d0e65ef3f01e8be20897b095d0e7e2067f

milestone: SSSD 1.6.0 => SSSD 1.5.12

Fields changed

rhbz: => 0

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1965

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.