plone/plone.app.ldap — pull request #21 by adaugherity (2014-09-12 22:18:31+00:00)
Title: AD & other misc. fixes

First of all, I apologize for the size and scope of this pull request -- I started off with what I thought was a simple fix for #7, then I discovered that my change only fixed it for import, not new configuration, and that new configuration was broken for non-AD also. As I learned my way around the code I fixed about half a dozen other bugs along the way. I can split this into multiple PRs if you would prefer.

Summary of fixes:
* Move the properties plugin to the top for AD also.
* On new configuration, store activated plugins in the config storage object, so they are moved to the top properly. (This finally fixes #7 completely.)
* Move the group management plugin to the top (for non-AD), so group memberships can be set via Plone.
* Fix binary flag for schema properties.
* Store blank property fields as "" rather than None, to avoid getting a literal `'None'` string in the LDAPUserFolder and exported XML.
* When adding mandatory schema items (currently only for AD), store them in the local config object also. Before they got added to the LDAPUserFolder but did *not* show up in Plone.
* Protect mandatory items from deletion.
* For the AD required schema items, mark objectGUID as binary and add sAMAccountName.
* Fix deprecation warning for the control panel icon.
* Misc. documentation fixes.

Regarding Active Directory, I tried to make my fixes match what I thought the intent was. I'm not sure if a separate AD plugin is still needed -- from what I can tell, the major differences are (a) read-only access, and (b) it enumerates group membership via the `memberOf` attribute on user objects, rather than the `member` attribute on group objects.

However, the standard LDAP plugin works fine with my AD server for authentication and user information, and RW access works for modifying group membership. (Group addition fails with “server unwilling to perform”, and we want to limit user addition/modification/password change to the AD side, so I haven’t tested those -- it's not 100%, but having some write access is better than none, and reading works fine. Also, nested groups do not appear to work with either plugin, but I don't normally use them.)

My AD groups are presented via LDAP as `group` class objects, with `member` attributes referring to a user’s full DN, much like standard LDAP. The ```memberOf``` user attribute is still present, but appears to be computed rather than stored in the user object. If the other method was once required, it no longer appears to be.