LDAP group membership lists parse DN and assume login username is in DN

Use Case: Administration : Manage Groups : View Members of Group : Browse Pagination
Issue: UUIDs display instead of username
Impact: Display of UUIDs in the Confluence UI is a bug that will prevent us from launching Confluence into production.
Analysis:
Review of the LDAP logs reveals the cause of this bug to be an assumption within the Confluence code that the logged in username can be parsed out of the DN. After retrieving all groups, then retrieving the DNs of all members of a selected group, Confluence then assumes that the value of the first component of the DN is equal to the username attribute defined in the atlassian-user.xml file. While this may be how AD tends to form DNs, it is not how every institution forms DNs in their LDAP servers. Furtermore, to parse information out of a DN is a fundamental violation of LDAP best practices; a DN is an opaque identifier that is not to be parsed. This is probably an attempt to avoid additional LDAP queries to display the names, uids, & email addresses of users, but that is the right way to populate the page as designed.

filter="(&(objectClass=brownGroup)(objectClass=brownGroup))" attrs="brownGroupRDN"
filter="(&(objectClass=brownGroup)(&(brownGroupRDN=COMMUNITY:ALL)(objectClass=brownGroup)))" attrs="hasMember"
filter="(&(objectClass=inetorgperson)(uid=56816df7-3d63-04f9-091a-7a931d7ca2f0))" attrs="uid givenName sn mail"

uids are formed as you would expect: "jcramton". Our DN contains a UUID, in the format "brownUUID=56816df7-3d63-04f9-091a-7a931d7ca2f0,ou=People,dc=brown,dc=edu"

Suggested solutions:

• A preferred solution is to not permit display of LDAP group membership. Try separating LDAP group management from local group management in the administrative interface, so we can disable management of LDAP groups from a config file setting

• Query LDAP for the uid, name, and email attributes for each group member identified by the 2nd filter shown above; that is the proper way to return this data. I understand that the current implementation is a shortcut to save excessive queries against LDAP, but it means you only support DNs formed a particular way.

• Consider the use case of thousands of group members. Many of Brown's groups have 18,000 members. We have no need to review group membership from Confluence, even in the admin interface. When group membership is presented to the end user, it is in fact a violation of our information security policy.