LDAP Authorization: Rework Strategy 3: groups as entries to meet more use cases

Using the current ldap_authorization code, mapping rules like the following can't possibly work:

CN=administrators,OU=Groups,DC=example,DC=com|administrator
CN=underlings,OU=Groups,DC=example,DC=com|underling

I can't see how line 401 of the following code (ldap_authorization.inc lines 388-405) could be reached in the most common (where cn is a required attribute for group object):

$derive_from_entry_authorizations = array();
388:  if ($consumer_conf->deriveFromEntry) {
389:    foreach ($consumer_conf->deriveFromEntryEntries as $branch) {
390:      $filter = '(' . $consumer_conf->deriveFromEntryAttr . '=' . $user_ldap_entry['dn'] . ')';
391:      $entries = $ldap_server->search($branch, $filter, array('cn'));
392:      if (empty($entries) || $entries['count'] == 0) {
393:        $filter = '(' . $consumer_conf->deriveFromEntryAttr . '=' . $user->name . ')';
394:        $entries = $ldap_server->search($branch, $filter, array('cn'));
395:      }
396:      foreach ($entries as $entry) {
397:        if (isset($entry['cn'])) {
398:          $derive_from_entry_authorizations[$entry['cn'][0]] = $entry['cn'][0];
399:        }
400:        elseif (isset($entry['dn'])) {
401:          $derive_from_entry_authorizations[$entry['dn']] = (string)$entry['dn'];
402:        }
403:      }
404:    }
405:  }

Line 401 won't ever be reached because:
1. Lines 391 and 394 explicitly ask for cn attribute.
2. The cn attribute is a manditory naming attribute for group objects in most schemas, so (because of #1 above) will be returned in results.
3. cn being return in results (always) will cause excution of line 398 -- which causes the group cn to be compared against the mapping

Conclusion: Bug. I can't think of a scenario where (for "Strategy 3: groups as entries.") a user would want to use the group CN in the mapping rules. The MUCH more common approach would be to use the group's distinguished name in the mapping rules.

Suggestion: Consider explicitly requesting "dn" (not "cn" in searches) and eliminate the conditional at line 397-399. The only other way to preserve evaluation by either DN or CN would be to add a configuration setting -- which would just confuse the user since what they really want to do is use group DNs in the mapping. There's no advantage (only ambiguity in using group CNs in rules).