PSPNG membership add to group lowercases memberOf attribute in openldap

We are using OpenLdap in our environment, and are using the memberOf overlay to handle adding "memberOf" to the user record.

When OpenLdap updates the 'member' attribute on the group, using the memberOf overlay, it replicates the 'DN' provided in the mod LDIF, rather than how the DN is actually defined in OpenLDAP.

Example if the DN  of the group is defined as:

cn=TestCase,ou=Groups,dc=somewhere,dc=edu

and the modify LDIF contains the dn to be in all lowercase like

cn=testcase,ou=groups,dc=somewhere,dc=edu, then

the memberOf attribute on the user will look like

memberOf=cn=testcase,ou=groups,dc=somewhere,dc=edu instead of cn=TestCase,ou=Groups,dc=somewhere,dc=edu

Or in another absurd example for OpenLDAP , if the mod LDIF contains the dn to be modified like

cn=tEsTcAsE,oU=gRoUpS,dC=sOmEwHeRe,dC=eDu,

The memberOf attribute on the user will get replicated like

memberOf=cn=tEsTcAsE,oU=gRoUpS,dC=sOmEwHeRe,dC=eDu instead of cn=TestCase,ou=Groups,dc=somewhere,dc=edu

Technically, this isn't a problem, as ldap generally is case-insenstive.  However, we are making use of Grouper maintain ldap groups to control access to AWS roles via SAML auth via Shibboleth.  Unfortunately, AWS's implementation of 'Roles' is case sensitive, and if we had a role mapped to TestCase, and it came back as 'testcase' or 'tEsTcAsE',the authorization fails., and they don't get to log in.

The edu.internet2.middleware.grouper.pspng.LdapGroupProvisioner.scheduleGroupModification() method is currently lowercasing the DN in the creation of the ModifyRequest.

Its calling "ldapGroup.getLdapObject().getDn()" to set the DN in the ModifyRequest object.

The LdapObject.getDn() method currently lowercases the dn for ease of use, but is causing the openldap server to replicate the 'memberOf' group's dn value in lowercase instead of the case defined in Grouper.

The ModifyRequest object should probably use the original case of the DN when modifying the DN rather than change the case to prevent the issue I described.  Simply changing the call to "ldapGroup.getLdapObject().getStringAttribute("dn")" should remediate the issue.  I've extended the LdapGroupProvisioner class with a custom class in our environment with this change and it takes care of the problem.  It would be nice to push it out everyone else.