`Group Name Attribute` should not be configurable for `memberOf` config. It is misleading, as it is used in a regex to match the returned memberOf attribute and not the actual group name.

You could argue that it is in fact the "Group name attribute", as it actually is the first RDN in the LDAP group's DN, but then, the regex in code is wrong, as currently (`CN=(?<groupname>[^,])`), it matches the string after the attribute name (CN=) until it finds a comma (`(?<groupname>[^,])`), but commas are allowed in Common Name. So if a user has a group with a comma in it, like "My, Group", for example, it will match only until the comma (`My`, in that case). Also, it is considering case, so specifying `cn` will fail, while leaving it empty, will pass, as regex will be constructed like `=(?<groupname>[^,]+)`.

I have three suggestions for resolving this:

1. Remove that field and use the DN as is, but match it case-insensitively.
2. Do another query to LDAP with the DN to get the attribute specified by the user and match against it.

Those two have drawbacks, but IMO, solution 1 is preferred, as it is less costly, because there is no need to query LDAP for every group the user is a member of. The drawback is that users must specify the entire DN of a group. But for that, you would just need to document that the actual memberOf value is expected (a DN) for the pattern. Users could still be able to specify wildcards, like "CN=My, Group*". 

Anyway, I'll be using the "groupOfNames" option, since that allows for more granularity and recursiveness. I'll propose a DOC change explaining how to match groups recursively with the lowest possible cost, using groupOfNames and LDAP_MATCHING_RULE_IN_CHAIN.